Lately I had the VCU restart during charging but there was one important difference to a normal charging session: I had the dashboard running over the entire session. The dashboard polls settings and spot values in a 500ms interval, so two lengthy "get" command per 500ms.
So I conducted an experiment here on the desk: connected USB/TTL adapter, set baud to 921600 and then spammed it with the same get commands as the dashboard but at a much higher rate. And indeed the replies become more and more garbage and after less than 10 requests the watchdog resets. The longer the commands, the sooner
Then I had a first lucky shot, commented out the echo:
Code: Select all
while (lastIdx < currentIdx) //echo
usart_send_blocking(usart, inBuf[lastIdx++]);
SPOILER: this is not the root cause, read on
The strange thing is, even with the terminal task completely locked up (e.g. by running "stream 10000 something,something") the watchdog doesn't trigger because naturally the scheduler (or in fact any interrupt) has high priority than the terminal which runs in the main loop.
usart_send_blocking() calls usart_wait_send_ready() which contains
Code: Select all
while ((USART_SR(usart) & USART_SR_TXE) == 0);
Next challenge is to fix the issue in a backward compatible manner. Simply not echoing does not play well with the existing ESP8266 or ESP32 code that runs on 100s of devices by now. Also for most people it is not really an issue because at the normal poll rates of the web interface all can run fine for hours.
Maybe an "echo off" command would be the solution.