ESP32-EVB bootloader serial output garbled

[willcrozi]

Hi, I'm trying out an ESP32-EVB-EA board and am unable to fix an issue with the bootloader output over USB serial monitor.

The output I receive from the bootloader ranges from completely garbled to almost completely correct. It seems to depend on what 'mood' the board is in.

My setup is as follows:

system: Ubuntu Linux (20.04 x86_64)
serial port: 115200 baud 8N1

I'm able to flash Arduino sketches successfully and once the sketch is running I'm able to receive correct serial output over the serial->USB connection without an issue.

Is there anything I'm able to do to fix this problem with the bootloader's serial output?

Cheers, Will

[LubOlimex]

So sometimes the initial built-in bootloader spews garbage (after reset or power up)? Like this one but garbled:

Code Select Expand

10:00:01.125 -> ets Jul 29 2019 12:21:46
10:00:01.125 ->
10:00:01.125 -> rst:0x1 (POWERON_RESET),boot:0x1b (SPI_FAST_FLASH_BOOT)
10:00:01.125 -> configsip: 0, SPIWP:0xee
10:00:01.125 -> clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
10:00:01.125 -> mode:DIO, clock div:2
10:00:01.125 -> load:0x3fff0018,len:4
10:00:01.125 -> load:0x3fff001c,len:676
10:00:01.125 -> load:0x40078000,len:0
10:00:01.125 -> load:0x40078000,len:11240
10:00:01.125 -> entry 0x40078410

I meant like this:

Code Select Expand

10:17:59.929 -> ⸮⸮⸮ets Jun  8 &⸮⸮00:22:57
10:17:59.929 ->
!⸮.⸮⸮⸮⸮ (POWERO⸮%UMQ⸮,boot:0⸮b (SPI_FAST_FLP*⸮%==Q⸮
10:17:59.929 -> confi֥⸮: 0, SPIWP:0⸮⸮
10:17:59.929 -> clk_drv:0x0b⸮}⸮⸮⸮⸮0x00,d_d.⸮⸮⸮⸮0,cs0_drv'⸮⸮0,hd_drv:0x0b⸮⸮_drv:0x00
10:17:59.929 -> m⸮⸮:DIO, clock dZ⸮⸮j
10:17:59.929 -> load:0x3ff⸮⸮⸮,len:1284
!⸮+⸮⸮0x40078000⸮⸮⸮:12836
10:17:59.929 -> load'⸮⸮0080400,len:&⸮⸮j
10:17:59.929 -> entry 0x40‚⸮*⸮

What exactly is that you see?

If that is the case (and if it bothers you) it can usually be improved by adding bigger capacitor between EN and GND (in the design it is C31 and it is 1uF). Maybe try with 10uF. It is easiest to connect 10uF capacitor at the EXT1 header - EN is lead out there at pin #33. Good news is that pin #34 is GND so you can place a PTH capacitor easily over the two pins even without wires, make sure long wire of the capacitor goes to EN and short one goes to GND. But personally I won't bother since I never needed the initial info printed by that bootloader anyway.

Also first try using different serial terminal software.

[willcrozi]

Thanks for the reply!

I meant like this:

Code Select Expand

10:17:59.929 -> ⸮⸮⸮ets Jun  8 &⸮⸮00:22:57
10:17:59.929 ->
!⸮.⸮⸮⸮⸮ (POWERO⸮%UMQ⸮,boot:0⸮b (SPI_FAST_FLP*⸮%==Q⸮
10:17:59.929 -> confi֥⸮: 0, SPIWP:0⸮⸮
10:17:59.929 -> clk_drv:0x0b⸮}⸮⸮⸮⸮0x00,d_d.⸮⸮⸮⸮0,cs0_drv'⸮⸮0,hd_drv:0x0b⸮⸮_drv:0x00
10:17:59.929 -> m⸮⸮:DIO, clock dZ⸮⸮j
10:17:59.929 -> load:0x3ff⸮⸮⸮,len:1284
!⸮+⸮⸮0x40078000⸮⸮⸮:12836
10:17:59.929 -> load'⸮⸮0080400,len:&⸮⸮j
10:17:59.929 -> entry 0x40‚⸮*⸮

What exactly is that you see?

If that is the case (and if it bothers you) it can usually be improved by adding bigger capacitor between EN and GND...

Yes that's roughly what I was seeing, the amount of garbled chars seemed to vary between runs. For the record I was seeing the same thing in various terminal apps (minicom, PuTTY, and Arduino-ESP IDE)

I've added the 10uF cap as you've described but in the meantime before your reply I appear to have made things worse!. I've been using the Espressif Rust tools in the esp-rs projects (https://github.com/esp-rs) to try out some serial port examples. It looks as though the flashing process of tool flashes a stage2 bootloader every time I reflash my application.

Code Select Expand

~/devel/esp/esp32/esp32-nostd-demo$ espflash /dev/ttyUSB0 target/xtensa-esp32-none-elf/debug/hello-world --monitor
Serial port: /dev/ttyUSB0
Connecting...

Unable to connect, retrying with extra delay...

Chip type:         ESP32 (revision 1)
Crystal frequency: 40MHz
Flash size:        4MB
Features:          WiFi, BT, Dual Core, 240MHz, Coding Scheme None
MAC address:       bc:dd:c2:f2:b3:d5
[00:00:01] ########################################      16/16      segment 0x1000 <<-- I think this indicates stage2 bootloader is flashed here
[00:00:00] ########################################       1/1       segment 0x8000
[00:00:02] ########################################      26/26      segment 0x10000

Flashing has completed!
Commands:
    CTRL+R    Reset chip
    CTRL+C    Exit

� ��ׁJ�
      ���0L�º�Ҫ�C�HH�t'�� ��]�Rʽ�ѪU� ��W¸
                                            ,�ӕ}�A*�e��*�%=��JH��K��.
��KպT�1�,�k�VKi�C!�+�:�m����b�n�L�H�����i                        a�����Ѱ�cSA��Hello world!��v'��0��%��'��0��E��'�A0)ͰE��:�A� ��d.����0�}��W¸�
Hello world!                             �����m�j��+�:�M����M�k��
Hello world!
Hello world!
Hello world!
Hello world!
...

The bootloader output is now completely garbled when trying to read from the PC's USB tty at 115200. Attaching an a logic analyzer to EXT1 pins 2 & 4 (UART0:TXD & UART0:RX) reveals its running at ~120000 baud during the bootloader stage (bit length measures ~8.32us) then switches to 115200 when my application starts.

Unfortunately it seems the tty<->USB chip used on the board (CH340T), or at least its Linux driver, is unable to operate at this custom baud rate. Also, (strangely) the initial output from my app is somehow interleaved with garbled chars (I'm not sure how this would even be possible?!).

My LA software is able to decode the bootloader output at 120k baud and interestingly the first line seems to match your garbled example:

Code Select Expand

ets Jun  8 Jun  2016 00:22:57
I'm wondering if I should try a newer (stage2) bootloader and see if it sets a sane baud rate for the output. Do Olimex recommend a particular stage2 bootloader version for this board?

[LubOlimex]

Yeah the initial bootloader might start at different baud, while your code starts at different baud. This might cause such glitches.

Some older kernels had some issues with the CH340T drivers. Did you try to use this driver: https://github.com/OLIMEX/ch340-dkms

[willcrozi]

Some older kernels had some issues with the CH340T drivers. Did you try to use this driver: https://github.com/OLIMEX/ch340-dkms

Thanks, I'll build and try out that driver when I get a chance.

After some more experience with the board, in particular trying out demos from ESP IDF, my best guess is that the garbled text is coming from the stage1/ROM bootloader and that the stage2 bootloader [1] I was using above is configured to only log on warning/error and thus silent. The other observation is that the garbled output occurs when performing one of the following: first power-on, pushing hardware reset button, or reflashing. The stage1 output immediately after restarting from software (e.g. IDF's esp_restart()) seems to be pristine, at least with the 10 uF cap attached.

It's reassuring to know that this doesn't seem to affect stage2 serial output. Thanks again for the help :-)

[1] https://github.com/arjanmels/esp32_bootloader_init_extram, used by the Rust tool 'espflash' at https://github.com/esp-rs/espflash