1

Situation:

An ESP32C3 running the Bluedroid BLE stack is connected via UART to another MCU which expects to always receive constant length messages. The system seems to work perfectly fine during normal operation, but if I for whatever reason reset the ESP32, the ESP32 writes exactly one byte to UART, hence throwing off the receiver MCU by one byte!

What I tried so far:

I commented out any call to uart_write_bytes(), which in turn ensures that my program is not at fault. This change doesn't help though, as the ESP32 still keeps printing the byte upon reset.

What the ESP send onto UART:

  • Upon hitting the "RST" button on the dev. board or flashing new software, it prints 0xfc.
  • If I unplug and replug the power however, it prints 0xf8.

N.B.: I tried to reproduce such behavior on another microcontroller, specifically an STM32L552ZE. I was not able to, i.e. the STM32 didn't print anything to UART after resetting.

Configuration (sdkconfig.json): As the file was too long to paste it directly, you can find it on pastebin

Questions:

  1. Is there some configuration option that causes the ESP32 to print that initial byte?
  2. How can I fix that behavior, i.e. make the ESP32 not print anything after resetting/flashing/startup
iMrFelix
  • 335
  • 2
  • 18
  • 1
    I think you can’t avoid the initial junk byte after MCU reset/power-cycle. On reset or power cycle the UART Tx pin is configured (from default input with pull-up to UART Tx function) and the receiver might detect UART protocol START bits and receives a phantom byte. Your protocol has to deal with that and resync to a valid message frame. – HS2 Jun 06 '21 at 11:23
  • 1
    Use UART1 and leave UART0 for debugging purposes (bootloader and console interface). – rustyx Jun 06 '21 at 14:40
  • HS2 thanks, that's exactly what I dreaded :') rustyx I am already on UART1. – iMrFelix Jun 08 '21 at 13:29
  • 2
    UART is not by any means a reliable channel. There are occasionally bytes added (as you've seen), lost, garbled - like with any physical channel. You must take this into account. A protocol must exist which defines the start and end of your frame, a checksum, maybe a sequence number - the usual stuff. E.g. as a bare minimum I've used SLIP as the framing protocol, plus a very simple XOR-over-payload-bytes as the checksum. – Tarmo Jun 08 '21 at 13:58

0 Answers0