auto-reset circuit vs continuously running application

[danielm]

I built custom board with ESP32-WROVER, FTDI231X and auto-reset circuit which can be found in the reference schematic. Flash erasing and programming works with esptool without any issues.

However, in my application I need to have the ESP32 running continuously (powered from different power source than USB). When necessary I want to be able to connect to serial port of ESP32 via USB connection. The problem is that when USB is connected FTDI chip resets ESP32 via auto-reset circuit. This is obviously not an issue for single power supply development boards but it is an issue for my application.

How would you solve this problem?

[ESP_Angus]

Hi daniel,

Does the automatic reset happen at the moment the USB host is connected, or later on when you open the serial port? If the latter, what host OS do you have and what program are you using to access the serial port?

The exact details of the problem will depend on the host OS and the FT231X chip behaviour.

The best solution might actually be the same in all cases, though - provide a way to disable auto-reset. Either you could remove the circuit entirely and use buttons to trigger reset, or add a jumper to your board that can be placed when you want auto-reset behaviour and removed when it's not wanted.

Angus

[danielm]

Hi Angus,

it happens at the moment of plugging of USB cable from host. I think it might be related to power-up state (or sequence) of DTR and RTS pins of FT231X - it is powered from bus (host). Obviously at some point there is situation when DTR is high and RTS is low. I was thinking to slow down one of the signals so this situation is avoided (e.g. via capacitor). However this approach could affect timing requirements for EN and IO0 state transitions.

The auto-reset circuit was used so that physical buttons do not have to be exposed on the housing of the product. Firmware upgrade process is easier for the end-customer as well.

Daniel

[danielm]

Here are screens from my oscilloscope:
DTR - yellow
RTS - cyan
EN - pink
IO0 - blue

FT231X DTR/RTS power-up sequence

DS1Z_QuickPrint3.png (35.46 KiB) Viewed 9436 times

Reset No.1

DS1Z_QuickPrint2.png (36.39 KiB) Viewed 9436 times

Reset No.2

DS1Z_QuickPrint1.png (37.66 KiB) Viewed 9436 times

It seems EN is pulled low two times during power-up sequence of FT231X.

Would it help to slow down ramp-up of RTS using capacitor?

[ESP_Angus]

Hi Daniel,

Thanks for the scope traces, that is very illustrative.

Would it help to slow down ramp-up of RTS using capacitor?

Maybe but I think probably not, the auto-reset circuit is still going to generate a hard falling edge on the EN pin for the ~2.5ms period where RTS# is pulled low and DTR# is still high, so you'd need to slow the DTR# rising edge. It's unclear if the host computer is initializing this sequence, or if it's something in the FTDI chip startup itself (suspect the latter), but it's hard to avoid.

If you have the power budget, you might consider switching the FT231X VCC to be powered from the same 3.3V source as the ESP32 instead of USB. This way the FT231X should start up at the same time the ESP32 starts up, and it might go into some low power state where DTR# and RTS# are held high (I think, I haven't checked the datasheet for this chip). Then if you're lucky it will not toggle DTR# or RTS# when the USB host connects (this is also based on the assumption all of the unwanted signal transitions are due to startup and not due to the USB host or driver).

It's also possible there's a USB to serial chip where the power-on sequence isn't like this. If DTR & RTS transition low->high at the same time during startup then the auto-reset circuit approach will work and the device shouldn't reset. It just seems this is not happening with the FT231X.

Otherwise if the USB cable is only for firmware update then you can possibly design some other custom circuitry to replace the auto-reset circuit, so EN & GPIO0 are triggered based on a combination of RTS#, DTR#, and the time that USB VCC has been high. (Note that the auto-reset logic in the circuit only exists to accommodate "default" serial pin configurations, if your customers are only doing esptool flashing then this can possibly be removed.)

[danielm]

Hi Angus,

I tried to slow down rising edge of DTR# but it only generated more resets. So I focused on slowing down EN signal directly:
- 1uF capacitance connected to EN line
- EN pull-up switched from 10k to 50k (2x100k in parallel)
- 10k resistor added between EN line and collector of transistor from auto-reset circuit which pulls down EN line - it basically forms resistor divider with EN pull-up resistor but the line still can be pulled low enough

On the scope I still see EN pulled low but probably not for long enough (not sure) because there are no more resets after USB is plugged in.

DS1Z_QuickPrint5.png (35.81 KiB) Viewed 9394 times

I tried esptool with flash_erase command 10 times and auto-reset worked well each time. Will do more testing in the future.

Do you see any risk in this approach?

Best regards,

Daniel