libretiny: UART0 freezing RTL8710 + flash layout talks

I’m trying to replace the stock (AliOs) firmware of a Ginlong Solis Solar Inverter. The device is based on the EMW3080 MCU, which is an (identical?) clone of the RTL8710BN (my project page with datasheet, more info on the MCU, link to AliOs EMW3080).

libretuya is booting (fantastic work, thanks!), WiFi and GPIOs for reset pin and status LEDs seem to work fine (basic tests done: WiFi connect/DHCP, button press, blinking LEDs, …).

If I try to use hardware serial port 0 (for interfacing modbus later), the system freezes, e.g. with plain libretuya:

void setup() {
  Serial.begin(115200);
  Serial.println("Started log serial (uart2)");

  Serial0.begin(9600);
  Serial.println("Started modbus serial (uart0)");

The MCU freezes at Serial0.begin, the ‘Started modbus serial’ is never reached (and main loop is not started as well).

Same test with libretuya-esphome

libretuya:
  board: generic-rtl8710bn-2mb-788k
  framework:
    version: latest

[... WiFI setup ...]

binary_sensor:
  - platform: gpio
    pin: PA08
    name: "Reset button"

#uart:
#  id: uart_0
#  tx_pin: PA23
#  rx_pin: PA18
#  baud_rate: 9600

If I remove the comments for ‘uart’ the MCU freezes at ‘Setting up UART…’ log output.

Any help on how to fix or debug this is welcome!

About this issue

Original URL
State: closed
Created a year ago
Comments: 50 (47 by maintainers)

Most upvoted comments

A lot of topics have been discussed in this issue and it may be too long overall. In particular, the original problem has been solved, so I am closing the issue.

I’ve opened a new issue to track the ModBus desync problem.

hn on May 7, 2023

Sorry to disturb you again. Things are generally working very well. But after a few hours, sometimes the ModBus/UART traffic gets out of sync and cannot be resynchronised except by rebooting the stick.

More detail: The correct ModBus response string is 01 04 02 00 01 78 f0 (last two bytes are CRC). The problem is, that the very last byte (0xf0) comes ‘late’ and gets ‘mixed’ into the next ModBus response (t=millis() extra debug added by me):

[modbus_controller:035]: t=57137 Sending next modbus command to device 1 register 0xBFF count 1
[modbus:199]: Modbus write: 01.04.0B.FF.00.01.03.DE (8)
[modbus_controller:486]: Command sent 4 0xBFF 
[modbus:042]: t=57228 Modbus received Byte  240 (0xF0)   <----- this is from the previous response
[modbus:042]: t=57234 Modbus received Byte  1 (0x 1)
[modbus:042]: t=57239 Modbus received Byte  4 (0x 4)
[modbus:042]: t=57245 Modbus received Byte  2 (0x 2)
[modbus:042]: t=57251 Modbus received Byte  0 (0x 0)
[modbus:042]: t=57257 Modbus received Byte  1 (0x 1)
[modbus:042]: t=57263 Modbus received Byte  120 (0x78)
[modbus_controller:035]: t=57456 Sending next modbus command to device 1 register 0xBFF count 1
[modbus:199]: Modbus write: 01.04.0B.FF.00.01.03.DE (8)
[modbus_controller:486]: Command sent 4 0xBFF 
[modbus:042]: t=57535 Modbus received Byte  240 (0xF0)  <----- this is from the previous response
[modbus:042]: t=57541 Modbus received Byte  1 (0x 1)
[modbus:042]: t=57546 Modbus received Byte  4 (0x 4)
[modbus:042]: t=57552 Modbus received Byte  2 (0x 2)
[modbus:042]: t=57558 Modbus received Byte  0 (0x 0)
[modbus:042]: t=57564 Modbus received Byte  1 (0x 1)
[modbus:042]: t=57570 Modbus received Byte  120 (0x78)
[modbus_controller:029]: t=57775 Modbus command to device=1 register=0xBFF countdown=0 no response received - removed from send queue

I wonder if this is a problem of LibreTuya or the ModBus component. It’s somewhat hard to debug because you have to wait more or less half a day until it appears.

The ModBus component just checks if bytes are available() (esphome/components/modbus/modbus.cpp Modbus::loop), so for me it’s unclear where the time lag / desync comes from.

I have a very vague suspicion that the serial.available()=false status may be wrong (and thus the last byte remains in the buffer) and is only set to true again by the arrival of the next real ModBus response. Hmmm.

hn on Mar 31, 2023