Serial Quirk

lmclaren · 2011-10-10 15:37

Hi,

I have had an interesting problem with a project of mine, if I start the cog with the serial object my protousb would reset if I did not have the usb cable connected.

I traced the problem to the usb/serial converter, if it is not powered (eg usb cable plugged in) when you drive the serial pins from the prop, it creates a pulse on the DTR pin, only small but enough to reset the prop.

My fix was to cut the DTR track and put a jumper on it, I have a number of programs that scan for serial ports and they cause the prop to reset, this fixes both problems.

regards

Lee

Duane Degn · 2011-10-10 16:00

Lee,

This problem has bitten me many times (even after I knew about it).

The Demo Board also has this problem.

I'm pretty sure the QuickStart board doesn't have this problem.

I ought to use your jumper idea. I often use code like this:

debugState := _YesDebug '_NoDebug '
 
  Tbug(string(13, "Com driver started")) 
  Tbug(string(13, "Program Name = "))
  Tbug(@progamName)
 
 
PRI Tbug(localPtr)
 
  if debugState == _YesDebug
    Com.str(_DebugCom, localPtr)

But then I have recompile the code when I'm not using the USB connection for serial.

Duane

lmclaren · 2011-10-10 16:11

Thanks Duane, my project is a coffee roaster, sometimes I plug it into Artisan via serial and other times it is stand alone, I don't want to recompile between runs

I just though I would mention it as It can be a bit nasty if you leave the debugging on and wonder why your prop wont boot.

Duane Degn · 2011-10-10 16:22

Lee,

Yes, it is a good thing to remind forum members about.

This problem has been discussed several (probably many) times but it's good to bring it up every so often so newcomers can learn about it.

As I said, it's caused me problems many times.

I think I'm going to add that jumper to my board now.

Duane

Beau Schwabe · 2011-10-12 22:42

Duane,

The problem stems from parasitic power supplied to the FTDI chip through the TX pin when the USB isn't connected to the PC and the Propeller is sending something serially (or at least attempting to). There is enough voltage from the Propellers' TX pin (P30) entering the RXD pin of the FTDI that the FTDI has just enough to wiggle the DTR pin which causes the Propeller to reset. The trick used in the PSC (Parallax Servo Controller) ...first checks to see if the USB is connected to your PC. If it is, then the RX line will be HIGH, otherwise the RX line will be LOW. When the Propeller detects that the RX line is LOW, the Propeller forces the TX line LOW as well preventing any parasitic power from entering into the FTDI chip.

Reference Schematic:
http://www.parallax.com/Portals/0/Downloads/docs/prod/prop/PropellerDemoBd-RevG-Schem.pdf

     if ina[USB_Rx] == 0        '' Check to see if USB port is powered
        outa[USB_Tx] := 0       '' Force Propeller Tx line LOW if USB not connected
     else
                                '' Initialize normal serial communication to the PC here

Cluso99 · 2011-10-12 23:47

Beau: Since this comes up so often, I wonder if the FullDuplexSerial object should in fact be modified? If I recall, isn't FDX now a gold object???

There is another possible solution. By placing a 4K7 resistor from the USB 5V to the FTDI /Reset pin and a 10K resistor from the FTDI /Reset pin to ground. Then, when there is no power on the USB bus, the FTDI chip should be held in reset and DTR should be tri-stated. I have just received a pcb back with this design so I should know shortly if it works.

Peter Jakacki · 2011-10-12 23:53

This doesn't help very much if you disconnect or connect during operation. Since it's really a hardware problem then it should be tackled as such. If a series resistor is used in the transmit line then this will limit the available current for such things. There is no reason why this resistor could not even be 10K and this would limit the current so that the FTDI chip just cannot get any parasitic power (to operate).

BTW, it's best too that the receive line has a pull-up in the event that there isn't an input connected. Here's a diagram of how easy it is to fit and also there is a pullup on the txd to prevent line noise during reset etc. I would do this with one tiny smd resnet of course. Notice that the RXD line is also protected so it's possible to feed RS232 directly into this input if you wanted although the 10K would be too high for the transmit line in this case.

Duane Degn · 2011-10-13 07:49

Beau,

Thanks for the suggestion. I've changed my code to include this check. Now I wont have to recompile in order to use serial communication with the PC.

I agree with Cluso and Peter, it would be best to have a hardware solution to this problem. I only use serial communication when I'm modifying the program and testing new things so it's not a problem for me to restart the board whenever I need it to communicate with the PC.

Duane

Beau Schwabe · 2011-10-13 07:56

As mentioned, this is a hardware issue but it's also a software issue that should at least be understood from the designers perspective. A simple resistor fix for the hardware is not a fix at all, as you would still have the same problem when the Propeller tried to transmit.

The software solution requires the overhead responsibility from the programmer to manage during the design process. If "Plug and Play" is required, then periodically testing the TXD line to allow or disallow communication would be a solution.

Attached is a simplified schematic of the area of interest.

If the FTDI has no power through the USB(aka PC) connection then most all of the peripheral connections to the FTDI have some path to ground. The ones that don't are the RXD and the TXD which connect directly into the Propeller. The TXD isn't a problem because it's an output. Under normal circumstances, the RXD pin could be left floating. Since that pin is connected to the Propeller and doesn't become a problem until you try to transmit, the HIGH (3.3V) from the transmit signal is enough to conduct through the ESD diode inside of the FTDI chip (or any chip for that matter) and supply power to the FTDIs' VCC at one ESD diode drop (typically about 400mv)... So the FTDI briefly sees about 2.9V ... The brevity of the 2.9 Volts is enough to wiggle the DTR and perhaps initiate a brownout within the FTDI ... regardless, it's most likely an unpredicted state.

By monitoring the TXD line of the FTDI, the 'normal' , idle state of this line when power is applied is for this line to be HIGH (During transmission from the FTDI, it will go LOW) ... By looking at the TXD line prior to sending data on the RXD line, we can prevent a reset to the Propeller by disallowing the data to be sent if the TXD line reads LOW prior to transmission.

BigFoot · 2011-10-13 08:08

We just have a dip switch in the DTR line to disable it. To update the EEprom the user must turn the switch on. We have
found that some of the older PC's out in the field generate DTR pulses for no apparent reason. This would randomly reset
our products and be really confusing to the user's.

Beau Schwabe · 2011-10-13 08:16

BigFoot,

"We have found that some of the older PC's out in the field generate DTR pulses for no apparent reason. This would randomly reset our products and be really confusing to the user's." - That would indicate that the USB is connected to the PC. The current problem persists when the USB is not connected to a PC.

In answer to your random resets, these are caused when the PC has plug-N-play enabled and the PC upon power up or software on the PC generates a request to poll the USB ports for any new devices.

Peter Jakacki · 2011-10-13 08:36

Simple maths here. The simple resistor fix prevents the FTDI from powering up through the ESD diode as the current available through the resistor is insufficient for the operation of the FTDI chip which requires around 15ma to operate. The current through the 10K resistor is no more than 330uA but that's with zero volts.

As an exercise I connected an FT232 up and tried to power it through the 10K resistor (into the FT232's RXD) and the most that the transmit pin back from the FT232 would rise to was around 500mv. The transmit pin is a good indicator of the functioning of the FT232. There will never be enough current or voltage for the chip to generate any reset pulse and at that voltage even the reset transistor doesn't have a hope of turning on either.

The other part of the problem is as mentioned that the Prop's receive line floats or is pulled down making it appear as if it's receiving data or a break condition. My receive routines check for stop bits and if they don't exist then it's a framing error and I don't buffer any data. No problem and it's transparent to the application, no need to "plug n pray". Perhaps old faithful FDX needs to be updated.

Cluso99 · 2011-10-13 19:44

Surely the simplest method in a real circuit with onboard FTDI chip is the one I mentioned (and is in the FTDI232R manual) is to power the FTDI chip from the prop side and use the resistor divider I mentioned above to keep the FTDI chip in reset. I have a pcb here now that uses this method and I will be testing it over the next few days.

However, IMHO the resistor divider on the FTDI reset pin will most likely work in all situations. If it works, a very simple solution.. 2 resistors or a 4pin resistor network.

Peter Jakacki · 2011-10-13 21:53

Cluso99 wrote: »

Surely the simplest method in a real circuit with onboard FTDI chip is the one I mentioned (and is in the FTDI232R manual) is to power the FTDI chip from the prop side and use the resistor divider I mentioned above to keep the FTDI chip in reset. I have a pcb here now that uses this method and I will be testing it over the next few days.

However, IMHO the resistor divider on the FTDI reset pin will most likely work in all situations. If it works, a very simple solution.. 2 resistors or a 4pin resistor network.

Simple solutions that just work and don't need any fiddling are the best. I didn't really read your post properly (you know you should have included a diagram for thread skimmers!). Have you tried it yet?

BTW, I normally just power the FTDI chip from the Prop or even have the bus power and VCC of my board joined anyway. Normally I have resistors on my serial lines anyway so it's nothing to have one in the transmit line then.

BigFoot · 2011-10-14 07:16

Beau,

I used to have a PC that would generate a DTR pulse train when you turned on the lights in the office.
It really went nuts when you turned on a shrink tube gun. Theoretically you are correct, but no amount
of propeller code will be more positive than my switch.

ksltd · 2014-04-13 14:07

Actually, Beau is wrong. This isn't a quirk, it's a design error. And there is no real software solution.

The actual problem is that the design of the Propeller Plug and the schematic on page 17 of the manual violate the specification of the FTDI chip, which like nearly any device, does not allow the voltages on its input pins to exceed their supply voltage. When the Plug is not connected to USB, it's got no power and so any inputs must also not be powered.

A correct Plug design would add another pin to the plug, bring 3.3V onto its PCB and use that as the FT232R's VccIO supply.

Serial Quirk

Comments