Closed rodja closed 4 months ago
@rodja I can't reproduce the problem. You seem to have used the Lizard configuration tool from RoSys, which might cause the issue. And your core output line is incomplete, so I changed it slightly. But then running ./configure.py startup.liz /dev/tty.SLAB_USBtoUART
works fine.
Oh, maybe I need a port expander attached... I'll look into it once again.
Maybe a reproduction:
b = b'p0: @5a\r\np0: @5a\r\np0: @5a\r\np0: @5a\r\np0: @5a\r\np0: @5a\r\np0: @5a\r\np0: @5a\r\np0: @5a\r\np0: @5a\r\np0: @5a\r\np0: @5a\r\np0: @5a\r\np0: @5a\r\np0: @5a\r\np0: @5a\r\np0: @5a\r\np0: @5a\r\np0: @5a\r\np0: @5a\r\np0: @5a\r\np0: @5a\r\np0: @5a\r\np0: @5a\r\np0: @5a\r\np0: @5a\r\np0: @5a\r\np0: @5a\r\np0: @5a\r\np0: @5a\r\np0: @5a\r\np0: @5a\r\np0: @5a\r\np0: @5a\r\np0: @5a\r\np0: @5a\r\np0: \x95\xedbumper_front_top.change=0;bumper_front_top.in\xf6I (12) boot: ESP-IDF v4.4 2nd stage bootloader@87\r\np0: I (13) boot: compile time 08:53:25@71\r\np0: I (13) boot: chip revision: 3@14\r\np0: I (13) boot_comm: chip revision: 3, min. bootloader chip revision: 0@03\r\np0: I (17) boot.esp32: SPI Speed : 40MHz@1d\r\np0: I (21) boot.esp32: SPI Mode : DIO@65\r\np0: I (25) boot.esp32: SPI Flash Size : 2MB@68\r\np0: I (28) boot: Enabling RNG early entropy source...@50\r\np0: I (33) boot: Partition Table:@18\r\np0: I (35) boot: ## Label Usage Type ST Offset Length@35\r\np0: I (42) boot: 0 nvs WiFi data 01 02 00009000 00006000@4e\r\np0: I (48) boot: 1 phy_init RF data 01 01 0000f000 00001000@74\r\np0: I (55) boot: 2 factory factory app 00 00 00010000 00177000@4d\r\np0: I (61) boot: End of partition table@63\r\np0: I (64) boot_comm: chip revision: 3, min. application chip revision: 0@7e\r\np0: I (71) esp_image: segment 0: paddr=00010020 vaddr=3f400020 size=49f58h (302936) map@29\r\n'
b.decode()
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x95 in position 328: invalid start byte
But why is \x95
an invalid "start byte"?
Possible solution:
b.decode(errors='replace')
Restarting the ESP via core.restart()
causes the same decode error, but only via RoSys' Lizard interface. Using Lizard's monitor.py doesn't cause an exception, because it is already using errors='replace'
.
I think what is happening is that when rebooting the port expander, there are still bytes in the serial transmission buffer. After booting they mix with the boot message and potentially form "invalid start bytes". According to ChatGPT, UTF-8 characters should start with one of those:
Single-byte characters (ASCII): Range: 0x00 to 0x7F These represent standard ASCII characters and use one byte.
Two-byte characters: Range: 0xC2 to 0xDF These represent the start of a two-byte sequence.
Three-byte characters: Range: 0xE0 to 0xEF These represent the start of a three-byte sequence.
Four-byte characters: Range: 0xF0 to 0xF4 These represent the start of a four-byte sequence.
But 0x95 doesn't fit.
The question is, should we simply replace these errors, or should we drop the line altogether? The latter sounds more reasonable to me.
We fixed this problem by reviewing and updating how the serial port is read in different Python scripts. In RoSys we decided to replace decode errors and skip corrupted lines based on checksums: https://github.com/zauberzeug/rosys/commit/d279b615ab28732487e7cf5362d65576214330ac
After running configure, Lizard always reports the error
Could not decode serial data
:The configure data is