Why UART2 read do not work after hard reset?

All ESP32 boards running MicroPython.
Target audience: MicroPython users with an ESP32 board.
Online
Divergentti
Posts: 67
Joined: Fri Sep 04, 2020 9:27 am
Location: Hanko, Finland
Contact:

Re: Why UART2 read do not work after hard reset?

Post by Divergentti » Wed Jan 20, 2021 8:16 am

Divergentti wrote:
Tue Jan 19, 2021 9:38 pm
marcidy wrote:
Tue Jan 19, 2021 7:15 pm
Divergentti wrote:
Sun Jan 17, 2021 1:20 pm
for some reason after power on boot returned bytearray is like bytearray(b'\x00\x00\xa2\xff\x86\x01\x9a=\x00') but when UART works it is like bytearray(b'\xff\x86\x01\xfd=\x00\x00\x00?') where first FF is the key for proper reading.

Code: Select all

b'\x00\x00\xa2\xff\x86\x01\x9a=\x00'
b'\xff\x86\x01\xfd=\x00\x00\x00
That looks like noise, \xff\x86\x01 is there in both cases. Leading \x00 can be that the connected device isn't powered up yet, pulling down the lines and triggering a phantom transfer.

Do you have external pull-ups? Can you (electrically) enable the sensors after initializing the UART? This probably not a code / micropython issue but an electrical issue. If you can't do anything else, you can read bytes in a loop till you get \xff on initialization.

It's good to have sensible hardware defaults via pull-ups, and control the start-up and initialization of connected devices whenever possible. If you have access to the pins, you might want to add some external pull-ups to RX and TX.
Thank you for heads up.

It indeed looks like a noise and perhaps I shall add error frame counter to the MHZ19_AS.py class. If checksum from UART bytearray is wrong, counter increases. Noise is possible, because chip is SMD chip in the programming board and I use dupont connectors, which are bad. I am not using pullups, because I understood ESP32 has pullups as default and if I would like to use open drain GPIO, I have to turn them off? At least I have done so for circuits which are "grounding" through GPIO pin.

But then the but: this problem can be repeated without any changes to the hardware (= noise theory do not apply). With deletion of the sensor object everything works robust without errors (tested over night), but if I do not delete the sensor object as in the code I do, nothing works after power on boot, but works fine with soft boot.
UPDATE 20.01.2020: I added crc_errors and range_errors to the MHZ19_AS.py class and in this video https://youtu.be/wdhZWGnmWlU I demonstrate the problem:
- UART2 re-creation is disabled in the main.py code
- first boot is soft boot and as you see, everything works fine
- second boot is power on boot and you see that UART2 (= MHZ19_AS.py) related crc_errors start increasing each reading cycle and no CO2 values are read.

I hope this helps to find root cause for this problem.

Post Reply