custom pcb, flashing works, but program's baud rate 1.5x slower than desired
Posted: Thu Apr 21, 2022 3:04 am
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)
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)