Use FDTI chip's Reset/ input to prevent reset issue?
Rayman
Posts: 14,889
I've heard of issues regarding the FTDI being powered up by parasitic feeds and causing the Prop to reset...
I'm doing a new circuit right now and looking through the FTDI FT232RL datasheet again, I see one example where the Reset/ pin is pulled down by a big resistor and pulled up by a smaller resistor to USB's +5V.
It appears to me that those resistors will prevent the reset issue... If the FTDI chip does power up by chance, the pulled down reset/ pin will keep it from doing anything unless USB power is present.
Anybody tried this before?
I'm doing a new circuit right now and looking through the FTDI FT232RL datasheet again, I see one example where the Reset/ pin is pulled down by a big resistor and pulled up by a smaller resistor to USB's +5V.
It appears to me that those resistors will prevent the reset issue... If the FTDI chip does power up by chance, the pulled down reset/ pin will keep it from doing anything unless USB power is present.
Anybody tried this before?
Comments
I have posted a solution to this problem some time ago, but not many people have seemed to bother with it.
I have attached a schematic of a circuit that I use all the time now.
By default you wont be able to program your device as the PROP RESET line is disabled, if all is connected as per schematic.
You need to pull the ENABLE line HIGH to ENABLE device programming, but you can do debugging and normal serial data transfers.
Yes, this approach does use an extra pin from the prop!
You will also need to "PROGRAM" the USB Chip itself with the MPROG utility, In this utility you need to SET the bus to be SELF POWERED, and INVERT the DTR Line.
I use a micro match header + ribbon cable to all my CPU boards, So When I am doing programming I have one wire "CUT" , thats the DISABLE LINE, so that I can easily program the prop chip, but in my code I have a "USER MODE" that allows for FIRMWARE UPDATING.
For my PRODUCTION products I have all the wires connected of the header.
Hope this helps, but all I can say is that IT WORKS!
Dave M
-Phil
I'd like to be able to start a propeller program to collect data from several sensors and accumulate data in memory for a period of several hours to several days while my PC is connected but will be powered off for most of that time.
Then I'd like to be able to turn on the PC, send the propeller a "download data" request, receive an upload of data and display it on a graphical plot.
But what happens now is that both the action of powering up the PC and the action of starting a PC program that opens the serial port to the propeller result in resetting the propeller.
So the way things are now, I'd need to store accumulated data in some sort of external persistant data storage in order to be able to do this.
Would these these hardware modifications prevent this unwanted resetting behavior?
My design will do that for you.
regards
Dave M
I do remember discussions about these solutions. This one has the advantage of only needing 2 resistors. But, I don't know if it will work or not yet...
David B, You probably do need DavidM's solution to solve those issues... (or install a jumper on the reset line)
Open the switch to disable external resets, close the switch for conventional program development?
Yes , You can do that as well,
My solution was for a PERMANENT design to be used in FINISHED PRODUCTS .
The idea being that this USB Interface board will prevent resets from pulling out the USB plug, and other PC/MAC system calls.
This allows on NORMAL SERIAL data coms to your device , as well as ( Via PROP software), allow the user in the field to UPDATE FIRMWARE.
regards
Dave M
-Phil
If I use the ANALOG SWITCH for disabling, then, is that "AS SAFE" for the prop as using the Buffer you suggest?
In my software that the "USER" sees, they have a "MENU" option on the DEVICE of "ENABLING a firmware UPGRADE", without accessing switches, this can also be accessed by software on the PC or MAC to ALLOW for an upgrade through an automatic and secure process.
So far I have had no problems with a "STUCK" reset line.
Dave M
The buffer that I've been advocating is not connected to the reset line, but to TX and RX. This is done to prevent these lines from powering the FTDI chip or Propeller board parasitically when one or the other is powered down. The problem with parasitic powering is that the protection diodes through which the power is leeched often have very low maximum current specs. In the Prop, for example, it's 500uA. So it would be very easy to exceed those ratings if the chip itself required more than that. So far, I'm not aware of any damage that's occurred to any Prop Plugs because of this, but it's also possible that any deleterious effects are cumulative.
By using the buffer, the possibility of errant resets due to unpowered FTDI chip wake-ups goes away. It does not solve the reset-on-connect and reset-on-port-open issues, though.
As to the Prop controlling access to its own /RST line, I'm glad your system works for you as well as it does, and it sounds like you've managed to overcome any reliability issues that might lead to the Prop pulling a HAL: "I'm sorry, Dave, but I'm afraid I can't do that."
I'm not so lucky when I program, though, and would be afraid of a bug during development that locked up the lockout mechanism. Maybe a combination of your method with a way to physically override the lockout would be the optimum solution.
-Phil
Thats Funny, I must get a SOUND CLIP of that and use it for my MAC ALERT Sound!
Anyhow,
So As you said,the buffer is for protection,not for ALL resetting issues, thanks for clearing that up, , as a note I do have a 150R resistor IN LINE on the RX & TX line, will that help with any current issues? That was suggested in the FTDI schematic.
As another note, during normal development I have my USB board, with the RESET ENABLE Line CUT, just for convenience. The Production units don't have the LINE Cut.
The lockout mechanism, is just a PIN HI/Lo call, so depending where you put it, should make a reliable mechanism.
thanks
Dave M