PDA

View Full Version : Use FDTI chip's Reset/ input to prevent reset issue?



Rayman
11-14-2010, 08:21 PM
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?

DavidM
11-14-2010, 09:34 PM
Hi Rayman,

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 Pilgrim (PhiPi)
11-14-2010, 11:35 PM
See here (http://forums.parallax.com/showthread.php?p=847328). The 74LVC2G07 buffer in this circuit prevents the FTDI chip from being powered parasitically, so no /RST gating is required.

-Phil

David B
11-15-2010, 06:55 PM
I've got a propeller protoboard with a USB prop plug connected to a PC.

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?

DavidM
11-15-2010, 09:47 PM
Hi Dave B


My design will do that for you.

regards

Dave M

Rayman
11-15-2010, 11:04 PM
David, Phil,

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)

David B
11-15-2010, 11:35 PM
Is there any reason not to simply break the RESn trace on the propeller protoboard and add a simple series switch?

Open the switch to disable external resets, close the switch for conventional program development?

Rayman
11-16-2010, 12:01 AM
Might be easier to make a 4 to 3-pin adapter to go between the PropPlug and the Protoboard with no connection for the reset line...

DavidM
11-16-2010, 01:27 AM
Is there any reason not to simply break the RESn trace on the propeller protoboard and add a simple series switch?

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 Pilgrim (PhiPi)
11-16-2010, 02:07 AM
I'm not too keen on letting the Prop block its own /RST input. If the output that does the blocking gets stuck in disable, how would one reprogram the chip, barring some tricky timing tricks with power-up or a reset button? Also, the LVC buffer is still necessary. It's never a good policy to let a chip's port pins provide parasitic power, as the protection diodes' current limits could easily be exceeded. The optimum solution, IMO, is a 74LVC2G07 buffer with a jumper that can be removed to disable the /RST.

-Phil

DavidM
11-16-2010, 02:37 AM
HI 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

Phil Pilgrim (PhiPi)
11-16-2010, 03:14 PM
Dave,

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

DavidM
11-16-2010, 09:31 PM
Dave,that might lead to the Prop pulling a HAL: "I'm sorry, Dave, but I'm afraid I can't do that." :)

-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