custom pcb, flashing works, but program's baud rate 1.5x slower than desired

[plusk01]

i am testing a custom pcb. I am using CH340C for USB<->UART. Flashing at 921600 baud consistently works. However, once the program is running (e.g., hello_world idf project or Arduino GetChipID) i have UART communication issues.

With CPU set to 240 MHz and serial set to 115200, the program prints a string which is only decipherable at 76800 (1.5x slower). With CPU set to 160 MHz or lower, baud rate comes through as expected (this test was with Arduino).

This initially made me think there was a power issue, but I bypassed my on-board AMS1117-3.3 regulator and issue remained.

Using idf hello_world (again with 240 MHz CPU), idf.py monitor seems to function as expected, seemingly because of the power on reset that happens each time the command is run.

If i use miniterm (without RTS POR) and I catch the serial message part way through, the baud rate is again messed up and not 115200 as expected. It doesn't seem to be CH340C issue because when I scope TX0 directly, I see the data is truly at the lower baud.

another data point: when i use miniterm (not idf.py monitor), occasionally this causes the esp32 to "hang" and no data is transmitted until a POR (not even boot mode / info which might give an indication of an errant POR or incorrect pin strapping).

Any thoughts about why the ESP32 UART0 would use a baud rate 1.5x lower than the requested? Do the CPUs automatically change CPU frequency if low power, and this is somehow messing up APB / UART clock?

I have read about the importance of capacitance on EN pin, but not sure that this is the issue here? (flashing has worked every time)

sch_esp32.png (151.17 KiB) Viewed 2444 times

sch_usbuart.png (94.68 KiB) Viewed 2444 times

[plusk01]

I managed to scope TX0 during an anomalous startup. The device was powered and running. As soon as i started miniterm.py (not idf-monitor, so without RTS POR) --- the ROM msg (nominally at the default 115200) came through at 76800. Then, the EARLY LOG and application serial came through at the desired 115200.

What would cause the CPU to not use the specified 115200 baud rate for the bootloader message, but then when the APP CPU starts, the baud rate is as desired?

Seems like power -- maybe i need more decoupling caps near CH340C?

(blue is 115200 decoded, red is 76800 decoded)

logic_uart.png (44.14 KiB) Viewed 2362 times

[ESP_Sprite]

I don't have the answer, but some points of interest:

You absolutely 100% do want to have a cap on EN - together with R2 it forms a RC network that does power-on-reset for the ESP32 (aside from forming a delay for signals when flashing). If you do not have that, there's no guarantee the ESP32 will start up correctly on power-on.

Also, there's absolutely no internal dependency between the CPU frequency and the UART speed - the UART derives its clock from either the crystal or the APB bus, and those are the same regardless of CPU frequency. Only thing that may affect the circuit is through something else - e.g. the ESP32 using more power and that messing with something.

Your module actually is an Espressif-made ESP32-Wroom, and not some clone, right? There used to be some boards that use a 26MHz crystal, leading to oddness.

[plusk01]

Thanks for the thoughts and explanations. Adding the 0.1 uF cap to EN solved the issue --- turns out i missed it in the datasheet's reference design.

(and yes - it is a proper Espressif device)

[rpiloverbd]

If you need any more pieces of advice regarding your PCB, you can post your design and questions to PCBway. The forum is open for all. Beginners and experts both hang around there. You'll find lots of esp32 based PCB designs such as this one:

https://www.pcbway.com/project/sharepro ... 6f10e.html

You can post your design to get more suggestions regarding its betterment.