Electronics > Microcontrollers

FTDI does not shutdown after power off

(1/4) > >>

fsonnichsen:
I have an FT232R on a 3.3V board shared with a PIC microcontroller and a MAX3232 to handle the RS232 function for the latter.
Since I don't have 5V on the board I use the USB/5V from the associated laptop to power the FT232R as in their datasheet.

All this works fine. Except---when I power down the 3.3V board/PIC/UART, the PIC remains in a sort of 2V "half state".
The FT232R is, or course, still connected to the 5V supply of the laptop. This 5V is confined only to the power pins of the FT232R and in no way ported, directly, to the board.
Subsequent investigation shows that the FT232R continues to send 16ms "wake up" pulses to the MAX3232. This is in turn carried to the PIC resulting in incomplete shutdown.

Apparently there is no 'DISABLE" or equivalent for the FT232R. Its #RESET and PWRDN pins are not for that purpose. Obviously I can complicate things, use a coveted PIC pin to control the FT232R, add FET circuits to disconnect the comms pins, and add source code to the PIC--all for lack of a DISABLE function.

But my question is-
1) Does anyone have a similar experience
2) Is there some work around I missed? Programming the FT232R (yuk!)---or some better part for this?

I thought this was a simple task!
thanks all
Fritz

drvtech:
I've just been dealing with a similar, but not identical issue with a FT230X. In my case, the chip was remaining slightly powered up when the 5V VUSB was removed due to current being supplied by a pull up resistor on an output (or input - can't be sure at the moment). This was sufficient to get the internal VccIO regulator to try to start up and an output pin that should have been tristate was actually going low. The current through the pullup resistor was coming from son 3v3 logic supplied from another source. The solution was to put a bleed resistor on VccIO. Might be related...
Dave

wraper:

--- Quote --- Its #RESET and PWRDN pins are not for that purpose
--- End quote ---
Do you want a separate pin named as "disable outputs only" or what? Pulling reset low will "disconnect" it as USB device and disable outputs, job done. Place a pull-down resistor on reset pin (internal 200k Pull-up) and enable it with MCU.

--- Quote ---PWRDN
--- End quote ---
There is no such pin.

--- Quote ---MAX3232 to handle the RS232 function for the latter
--- End quote ---
For what? FT232R logic (VCCIO) can operate from internal 3.3V vreg, there is no need for level shifter. Not to say MAX3232 outputs +/- 5V, there is not place for it between FT232R and MCU  :-//.

wraper:

--- Quote from: drvtech on February 03, 2021, 12:39:57 am ---I've just been dealing with a similar, but not identical issue with a FT230X. In my case, the chip was remaining slightly powered up when the 5V VUSB was removed due to current being supplied by a pull up resistor on an output (or input - can't be sure at the moment). This was sufficient to get the internal VccIO regulator to try to start up and an output pin that should have been tristate was actually going low. The current through the pullup resistor was coming from son 3v3 logic supplied from another source.
Dave

--- End quote ---
You cannot do that. You are not allowed to keep VCC powered and leave VCCIO unpowered or other way around, or supply current into inputs/outputs when not powered. Either 1) both need to be powered by device, 2) when powered from VUSB,  VCC from VUSB and VCCIO  connected to 3V3OUT pin. Any pull-ups should be powered from the same source, obviously, or disabled somehow.

--- Quote ---The solution was to put a bleed resistor on VccIO. Might be related...
--- End quote ---
The solution - potentially kill FT230X

fsonnichsen:
Sorry for the late response here--I wasn't' getting activity emails-

At any rate hare are a few facts.
1) Datasheet is attached.
2) Regarding drvtech--I do not have a pull up resistor as none is specified. In fact--I found that the 5V on VCCIO is indeed causing the problem. I desoldered the 5V pin and the voltage on the processor zeroed out. So I contacted the FTDI folks (they are always very responsive) and they indicated that I was correct-the FT232x has a bleed current past the 5V supply into the comms lines and this causes the problem. Further there is no way to prevent this as they don't have a disable line or similar for the chip. They agree that I need FETS on the lines to the PIC to insure shutdown.
 Good comments Wraper. Here are some replies
1) Yes--I simply need a disable--same as a lot of ICs that we use.
2) The #RESET Pin is vaguely documented and I didn't think that it was a shutdown. Turns out the FTDI folks agree on that. I think maybe it receives a signal but does not power down.
3) There IS a PWRDN pin and I can't blame you for not seeing it--if you check the attached doc it is obscurely mentions that this is programmed (default) via CBUS3.  But it does not power down the IC. It is for powerdown USB mode on the outboard connected device.
4) Sorry about the MAX3232-you are right -it is only connected via a jumper block which disconnects the FS232 so you can use either mode. (Been a while since I designed this and I forgot). SO---do ignore that. (funny emotocon BTW!)

Final analysis--
What is happening is that the FT232x is powering the PIC via its 5V bus and its connection to the PIC comms lines.  I think the fix is to disconnect the 5V via the power to the system using a FET. This insures the FT232 does not supply power to the PIC.

There is a question if this matters --and it does--My PIC system sends pulses to another board  via a transistor/FET etc which sends quick pulses to an LED array. Power the array too long and it becomes toast. So when I power down the system I want it to drop in a few us. The FT232 keeps the PIC pin high and the board to the LED array stays on for a bit while it bleeds down. Not a good thing.
   So I will look more at this when I get time but probably will ignore the FTDI problem and address cutting off current to the LED array in a reliable way. That is the safest thing to do.

I've used FTDI  ICs for a while and like them (and their support) but this nuance got past me. Probably not a show-stopper now that I know about it but a problem in many cases.

Thanks all
Fritz



Navigation

[0] Message Index

[#] Next page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod