DSPI Strange Behavior with USB - or is it ?

Created Sun, 28 Feb 2016 03:43:55 +0000 by FredCailloux

FredCailloux

Sun, 28 Feb 2016 03:43:55 +0000

I have been experimenting on my very simple DSPI sketch to communicate with an LS7366 Quadrature counter. Everything is running well and smooth except that, to my surprise, when I disconnect the USB wire from my computer or if I turn OFF my computer, the LS7366 suddenly stop responding. I could understand if I was getting my proMX7 board powered from USB, but it's not. The board is getting power from an external power supply 5V, 2 amps, that's plenty of power. I have JA Pmod jack used for my LKM1638 8 digits display to show the LS7366 counter reading every 1/3 second. JA is set for 5V output to power the LED display. My LS7366 chip is using JE set at 5V as well. This means that both external devices are getting their supply from the VCC5V0 MX7 line. They are not getting power from the USB port. Furthermore, I have my scope monitoring MISO, MOSI, SCK and SS. The 3 outputs from the MX7, MOSI, SCK and SS are still presents and do not change when I disconnect the USB cable, yet, the LS7366 MISO stop sending bits to the MX7 SDI3 pin 3 on JE. I also monitored power on LS7366 VCC pin, 5Volts is not moving the slightest bit. I attached my sketch for inspection.

What is happening here ? Why is it that the LS7366 chip, which is working perfectly well when the USB cable is connected, suddenly stop sending data when I disconnect the USB cable from my MX7 board ? I thought maybe the DSPI1 object is getting mixed-up with the UART but that doesn't make sense either because all 3 input signals MOSI, clock and SS keep running smoothly. The LS7366 is getting the command signal from the MX7 micro-controller. Why does it stop sending the data when USB is disconnected ? :?

FredCailloux

Mon, 29 Feb 2016 19:13:07 +0000

Problem not quite completely understood but solved. μController PIC32MX795 spec VOH at 2.4V. The LS7366 VIH spec is 3.5 when operated at 5VSS. Although both units were running fine, they were utilized out of spec. I don't really know why when the USB cable is disconnected PIC32MX795 VOH would drop, but the fact remain that as connected, in either case, the circuit was operated out of spec. So the only solution is to either run the LS7366 at 3.3V, which I cannot do because the encoder cannot run at 3.3V and the LS7366 maximum clock frequency at 3.3V is only 20Mhz. I have a 40Mhz crystal and I need to run the encoder at 5Vdc. Implementing level shift from proMX7 to drive the LS7366 is another solution but inconvenient for it require an extra chip that I don't have in stock at the moment (but will get ASAP). So, the solution was one of compromise. I figured that if I can run the LS7366 not at 3.3V neither at 5V but why not at 4.3V, what would happen. I took a 1N4148 to drop down the LS7366 supply to 4.3V and everything started working at unison. LS7366 is still running fine at 40Mhz, the encoder keep outputting perfect digital signal and when I disconnect the USB from J2, even though the SS signal drop a hefty 0.6V the LS7366 is still accepting the lowered digital signal. Hurray :D Hope someone else can profit from this debugging escapade.

Cheers...

PS: if someone could educate me on why the JE-01 SS3 signal drop when the USB cable is disconnected it would make me a little more competent.

KeithV

Thu, 03 Mar 2016 19:08:36 +0000

The chipKIT MX7cK uses and FTDI chip for the USB connection for programming. I am assuming this is the USB you are talking about as there is a dedicated USB connector on the board that goes directly to the MCU.

As a by product of powering the FTDI/USB DTR is toggled and cause the MCU to be reset. This would cause the processor to completely reset and your sketch and to restart. Clearly SPI would stop as the controller will be reinitialized.

The is a jumper on the MX7cK that will disable the DTR to MCLR connection. If you remove JP1 (next to the FTDI/USB connector) you will break that auto reset connection and you will not reset the processor from the FDTI chip. However, by doing this, you will not be able to reprogram your sketch on the MX7cK until you replace the jumper; that is how MPIDE/Arduino IDE auto reset and gets into the bootloader.

The FTDI chip is powered directly from the FTDI/USB connector and NOT the external power. So the FTDI will both enumerate on the USB bus and be dropped depending on whether power is supplied to that USB connector from your computer, and DTR will be toggled, and the MCU will be reset.

For fun, have your sketch up and running and on the same USB hub, connect another USB device (Memory stick or something), notice the MX7cK will get reset. That is because the USB bus was enumerated and that will cause the FTDI on the MX7cK to toggle DTR and cause the MX7cK to reset. This is why on most newer Digilent boards we always have a jumper to disconnect DTR from MCLR as almost any enumeration on the USB bus will cause a reset.

FredCailloux

Thu, 03 Mar 2016 20:13:17 +0000

Thank you KeithV for this technical capsule. Although quite relevant to the USB J2 and jumper JP11 (which I assume this is what you are referring to) it still does not explain why JE-01 SS3 signal drop from approx. 3.2V to 2.5VPEAK when the USB cable is disconnected. Or does it ? I think this auto reset is convenient. But my problem was not about the reset after upload, rather is was about losing signal strength on JE-01 when the USB cable was disconnected. My assumption is that it is probably an idiosyncrasy within the μController architecture and or physical circuitry. But my very limited knowledge in μController construction will limit my observation to nothing else then an assumption. It is pretty much out of curiosity and desire of knowledge that I was motivated to ask this question. The main thing is that I found the behavior, hence was able to correct the situation within my application by simply lowering the VCC on my LS7366 peripheral chip from 5V to 4.3V which resulted in the chip capable of reading the lowered SS signal strength and corrected the problem overall. Still, this behavior remain a potential source of electronic malfunction for other circuitry. We must not forget that in either case the peripheral chip LS7366 was and is still used out of spec. The chip should be powered with 5V for 40Mhz operation and should receive a minimum of 3.5V peak signal strength for proper operation. Both rules are presently violated. Something I should not forget when and if some other weird behavior should occur. :) Electronic is So Much Fun and Fascinating. :!:

majenko

Thu, 03 Mar 2016 22:09:16 +0000

For fun, have your sketch up and running and on the same USB hub, connect another USB device (Memory stick or something), notice the MX7cK will get reset. That is because the USB bus was enumerated and that will cause the FTDI on the MX7cK to toggle DTR and cause the MX7cK to reset. This is why on most newer Digilent boards we always have a jumper to disconnect DTR from MCLR as almost any enumeration on the USB bus will cause a reset.

That is behaviour I have never seen before. It must be a windows-ism.

FredCailloux

Fri, 04 Mar 2016 14:10:05 +0000

Can you pls elaborate on "must be a windows-ism". How, technically, a USB wire can influence the strength of as SPI SS signal is beyond me. But then again, I am not sure what you mean by "ism"? Is it Internet Service Manager ? Or perhap, Internal Signal Modificator ( that is a joke :lol: ).

Then I would be even more puzzled ? Please elaborate...

majenko

Fri, 04 Mar 2016 14:27:26 +0000

https://en.wiktionary.org/wiki/-ism

3. Used to form names of a tendency of behaviour, action, state, condition or opinion belonging to a class or group of persons, or the result of a doctrine, ideology or principle or lack thereof.

I.e., some strange quirk specific to Windows that isn't seen in any other operating system.

GrahamM242

Fri, 04 Mar 2016 15:49:45 +0000

That is behaviour I have never seen before. It must be a windows-ism.

It is an irritating windows-ism sadly, and it has annoyed me often enough. Still, not as irritating as Keysight's connection detection software that opens and closes every serial port every 10-15 seconds or so just to see if any Keysight tools are connected.

majenko

Fri, 04 Mar 2016 16:48:59 +0000

Damn, I am so glad I never use Windows :)

EmbeddedMan

Sat, 05 Mar 2016 00:18:25 +0000

That is behaviour I have never seen before. It must be a windows-ism.

I've used Windows a long time, and I've used chipKIT boards from Digilent a long time. I don't doubt that what Keith says is correct, in some cases, but I've never seen it myself. I've had many devices connected and disconnected from my USB hubs (with chipKIT boards from Digilent on them as well) and I don't believe I've ever seen a time when my chipKIT board was reset except when I wanted it to be (I.e. because I opened the port). I don't believe this is a common or wide-spread Windows-ism. If it were a common problem, I believe we would see many people complaining about it.

*Brian