First Stage bootloader on RXD0 not responding to sync

[jrgrobinson]

We are testing our custom ESP32 board. It uses a WROOM-32U with an RS485 interface on UART0 (pins 34 and 35). I connect to the RS485 port with an FTDI USB adaptor. I also have a passive monitor on this link. The tools are configured to COM4 on my desktop. GPIO0 is 0 tied, as is GPIO2.

I have been attempting to load an application with both the ESP Flash Tools v3.6.5 and the esptoolpy both are unsuccessful. The application and load works fine on a WROVER board.

I have looked at the communications at the WROOM pins. When the board is reset the following appears:

ets Jun 8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
waiting for download

I then start the flash tool and see the sync message:

$ UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU

repeated until timeout. I have tested the message at the RXD0 pin of the WROOM module.The message looks complete.

There is no response to this message and the flash download tool times out.

I have read much documentation and check through the forums and can't see anything wrong. Would really appreciate some help on where to look next?

Thanks

[ESP_Angus]

So the sync message to the ESP32 is being received via an RS485 to TTL interface chip? And the sync message is being sent from an USB FTDI chip driving a TTL to RS485 interface chip?

I can't think of any reason this shouldn't work.

If you have some logic analyzer captures at the RX0D pin, can you compare the timing to an RX0D pin driven from a working UART interface? Is there any difference in the timing or polarity of the signals?

EDIT: It's not possible something is resetting the ESP32 at the time the sync is coming in? You can monitor the TX0D pin to be sure.

EDIT 2: If you're not already monitoring the TX0D pin directly, suggest doing this anyhow in case the problem is that the response is being lost between the ESP32 and the other end of the RS485 link.

EDIT 3: Ah, is the RS485 link half duplex only? This may cause some problems, as esptool sends a lot of sync messages and they may overlap with the response. This doesn't matter in full duplex TTL serial. If you're seeing some response on the TX0D pin of the ESP32, check if it's overlapping with some sync messages being received at the RX0D pin.

[jrgrobinson]

Hi,

Thanks for the quick response. It is appreciated.

I have checked our custom board against the WRover operating in the same mode (restart with the switch pressed) with a logic analyzer(Salae). Connected to the ESP32 WROOM TXD0 and RXD0 pins. The initial transmission after reset and the sync message from the PC running the flash downloader, give the same, correct interpretation of the Async serial on both boards. This would indicate the serial stream is correct, bothways.

The initial transmission from the WRover board (below) is slightly different from our custom board(previous message).
ets Jun 8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x26 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_FEO_V2))
waiting for download

The WRover responds 17usec after the second sync message from the flash downloader . From the ESP32 on our custom board there is no response.

I noticed some glitches on the RXD0 line while the initial transmission was occuring on our custom board. This is an issue with the 485 to TTL converter we use. It may be that this is causing problems for the baud rate scan in the ESP32 first stage bootloader. We are looking at removing this, if possible and then trying again.

Would glitches on the receive data be a problem while the ESP32 sign-on message is transmitted?

Would the difference between boot:0x26 on the WRover and boot:0x03 in the signon message indicate a configuration problem?

Again, thank you for your quick response. It is very helpful in directing our investigations.