Watchdog kills OMG on ESP32-C3 within seconds

argafal · February 15, 2023, 3:30pm

I tried running OMG on ESP32-C3. Board is a Lolin C3 mini v2.1.0. I thought it would be nice to document the changes I needed to make for other users who might want to try the same. I also ran into a problem with, I believe, the watchdog. I would appreciate to hear if there is any advice, or if OMG simply can’t run on this board.

Changes needed. I compile the lastest version, git hash is03c83fb69c2bd9a36d043b323f1008d6802c961b. I used the env:esp32c3-dev-m1-ble environment definition in environments.ini and altered it as follows:

$ git diff
diff --git a/environments.ini b/environments.ini
index e2656304..d5819bda 100644
--- a/environments.ini
+++ b/environments.ini
@@ -1462,9 +1462,9 @@ build_flags =
   '-DGateway_Name="OpenMQTTGateway_ESP32_BLE"'
 custom_description = BLE gateway on the S3
 
-[env:esp32c3-dev-m1-ble]
+[env:lolin_c3_mini]
 platform = ${com.esp32_c3_s3_platform}
-board = esp32-c3-devkitm-1
+board = lolin_c3_mini
 board_build.partitions = min_spiffs.csv
 lib_deps =
   ${com-esp.lib_deps}
@@ -1479,6 +1479,8 @@ build_flags =
   '-DFASTLED_IND_TYPE=NEOPIXEL'
   '-DFASTLED_IND_NUM_LEDS=1'
   '-DRGB_INDICATORS=true'
+  '-DCONFIG_ESP_CONSOLE_USB_SERIAL_JTAG=true'
+  '-DCONFIG_ESP_CONSOLE_UART=ESP_CONSOLE_USB_SERIAL_JTAG'
   '-DNO_INT_TEMP_READING=true' ; Internal temperature reading not building on ESP32 C3 or S3
   '-DGateway_Name="OpenMQTTGateway_ESP32_BLE"'
 custom_description = BLE gateway on the C3

The first change is to select the right board, the additional build flags are to enable serial console debugging on the USB-C port.

I build and upload using pio run -e lolin_c3_mini -t upload --upload-port /dev/ttyACM3. Why does the serial output say “Build:Feb 7 2021”?

Upon boot, OMG starts and reports BLE values on MQTT. Uptime is a few seconds. It then is killed (by the watchdog?) and reboots.

16:24:15.201 > ESP-ROM:esp32c3-api1-20210207
16:24:15.201 > Build:Feb  7 2021
16:24:15.201 > rst:0x3 (RTC_SW_SYS_RST),boot:0xd (SPI_FAST_FLASH_BOOT)
16:24:15.201 > Saved PC:0x40381e1c
16:24:15.202 > SPIWP:0xee
16:24:15.203 > mode:DIO, clock div:1
16:24:15.205 > load:0x3fcd6100,len:0x438
16:24:15.208 > load:0x403ce000,len:0x918
16:24:15.210 > load:0x403d0000,len:0x24e4
16:24:15.215 > entry 0x403ce000
16:24:15.445 > N: 
16:24:15.445 > ************* WELCOME TO OpenMQTTGateway **************
16:24:15.446 > [   246][E][esp32-hal-gpio.c:102] __pinMode(): Invalid pin selected
16:24:15.447 > E (253) gpio: gpio_set_level(226): GPIO output gpio_num error
16:24:15.447 > N: OpenMQTTGateway Version: version_tag
16:24:15.500 > {
16:24:15.501 >   "mqtt_server": "192.168.1.XX",
16:24:15.501 >   "mqtt_port": "1883",
16:24:15.501 >   "mqtt_user": "",
16:24:15.501 >   "mqtt_pass": "",
16:24:15.502 >   "mqtt_topic": "home/",
16:24:15.502 >   "gateway_name": "OpenMQTTGateway",
16:24:15.502 >   "mqtt_broker_secure": false,
16:24:15.503 >   "mqtt_broker_cert": "",
16:24:15.503 >   "mqtt_ss_index": 0,
16:24:15.504 >   "ota_server_cert": "",
16:24:15.504 >   "ota_pass": "OTAPASSWORD"
16:24:15.504 > }*wm:[2] Added Parameter: server
16:24:15.505 > *wm:[2] Added Parameter: port
16:24:15.505 > *wm:[2] Added Parameter: user
16:24:15.505 > *wm:[2] Added Parameter: pass
16:24:15.505 > *wm:[2] Added Parameter: secure
16:24:15.505 > *wm:[2] Added Parameter: cert
16:24:15.505 > *wm:[2] Added Parameter: name
16:24:15.505 > *wm:[2] Added Parameter: topic
16:24:15.506 > *wm:[2] Added Parameter: ota
16:24:15.506 > N: Attempting Wifi connection with saved AP: 0
16:24:15.588 > E (394) wifi:Association refused temporarily, comeback time 1024 mSec
16:24:16.013 > N: Attempting Wifi connection with saved AP: 1
16:24:16.016 > E (822) wifi:sta is connecting, return error
16:24:16.016 > [   816][E][WiFiSTA.cpp:317] begin(): connect failed! 0x3007
16:24:16.516 > N: Attempting Wifi connection with saved AP: 2
16:24:16.519 > E (1325) wifi:sta is connecting, return error
16:24:16.519 > [  1319][E][WiFiSTA.cpp:317] begin(): connect failed! 0x3007
16:24:17.019 > N: Attempting Wifi connection with saved AP: 3
16:24:17.022 > E (1828) wifi:sta is connecting, return error
16:24:17.022 > [  1822][E][WiFiSTA.cpp:317] begin(): connect failed! 0x3007
16:24:17.522 > N: Attempting Wifi connection with saved AP: 4
16:24:17.525 > E (2331) wifi:sta is connecting, return error
16:24:17.525 > [  2325][E][WiFiSTA.cpp:317] begin(): connect failed! 0x3007
16:24:18.028 > N: Connect your phone to WIFI AP: OpenMQTTGateway_ESP32_BLE with PWD: your_password
16:24:18.028 > *wm:[1] AutoConnect 
16:24:18.028 > *wm:[2] ESP32 event handler enabled 
16:24:18.029 > *wm:[1] AutoConnect: ESP Already Connected 
16:24:18.029 > *wm:[2] setSTAConfig static ip not set, skipping 
16:24:18.029 > *wm:[1] AutoConnect: SUCCESS 
16:24:18.029 > *wm:[2] Connected in 1 ms
16:24:18.029 > *wm:[1] STA IP Address: 192.168.1.XX
16:24:19.545 > [  4344][E][Preferences.cpp:483] getString(): nvs_get_str len fail: BTConfig NOT_FOUND
16:24:19.545 > N: BT config loaded
16:24:19.545 > N: BT sys: {
16:24:19.545 >   "bleconnect": true,
16:24:19.545 >   "interval": 55555,
16:24:19.546 >   "activescan": true,
16:24:19.546 >   "intervalcnct": 3600000,
16:24:19.546 >   "onlysensors": false,
16:24:19.546 >   "hasspresence": false,
16:24:19.547 >   "presenceTopic": "presence/",
16:24:19.547 >   "presenceUseBeaconUuid": false,
16:24:19.548 >   "minrssi": -100,
16:24:19.548 >   "extDecoderEnable": false,
16:24:19.548 >   "extDecoderTopic": "undecoded",
16:24:19.548 >   "filterConnectable": false,
16:24:19.549 >   "pubadvdata": false,
16:24:19.549 >   "pubBeaconUuidForTopic": false,
16:24:19.549 >   "ignoreWBlist": false,
16:24:19.550 >   "btqblck": 0,
16:24:19.550 >   "btqsum": 0,
16:24:19.550 >   "btqsnd": 0,
16:24:19.550 >   "btqavg": 0
16:24:19.550 > }
16:24:19.551 > N: BT config loaded
16:24:19.551 > N: BLE scans interval: 55555
16:24:19.551 > N: BLE connects interval: 3600000
16:24:19.552 > N: Publishing only BLE sensors: false
16:24:19.552 > N: Active BLE scan: true
16:24:19.552 > N: minrssi: -100
16:24:19.553 > N: Low Power Mode: 0
16:24:19.559 > N: OpenMQTTGateway modules: ["BT"]
16:24:19.559 > N: ************** Setup OpenMQTTGateway end **************
16:24:19.568 > W: MQTT connection...
16:24:19.604 > N: Connected to broker
16:24:19.664 > N: Send on /SYStoMQTT msg {"uptime":4,"version":"version_tag","freemem":108588,"mqttport":"1883","mqttsecure":false,"freestack":4528,"rssi":-57,"SSID":"XXX","BSSID":"00:11:32:9D:20:95","ip":"192.168.1.XX","mac":"XXX","lowpowermode":0,"interval":55555,"intervalcnct":3600000,"scnct":0,"modules":["BT"]}
16:24:19.666 > N: Send on /BTtoMQTT msg {"bleconnect":true,"interval":55555,"activescan":true,"intervalcnct":3600000,"onlysensors":false,"hasspresence":false,"presenceTopic":"presence/","presenceUseBeaconUuid":false,"minrssi":-100,"extDe
coderEnable":false,"extDecoderTopic":"undecoded","filterConnectable":false,"pubadvdata":false,"pubBeaconUuidForTopic":false,"ignoreWBlist":false,"btqblck":0,"btqsum":0,"btqsnd":0,"btqavg":0}
16:24:19.673 > N: [ MQTT->OMG ]: {"white-list":["XXX","XXX","XXX","XXXX","XXX"]}
16:24:19.674 > N: Send on /BTtoMQTT msg {"bleconnect":true,"interval":55555,"activescan":true,"intervalcnct":3600000,"onlysensors":false,"hasspresence":false,"presenceTopic":"presence/","presenceUseBeaconUuid":false,"minrssi":-100,"extDe
coderEnable":false,"extDecoderTopic":"undecoded","filterConnectable":false,"pubadvdata":false,"pubBeaconUuidForTopic":false,"ignoreWBlist":false,"btqblck":0,"btqsum":0,"btqsnd":0,"btqavg":0}
16:24:20.560 > [  5359][E][esp32-hal-misc.c:128] disableCore0WDT(): Failed to remove Core 0 IDLE task from WDT
16:24:20.560 > N: Scan begin
16:24:20.571 > N: Device detected: XXX
16:24:20.578 > N: Device detected: XXX
16:24:20.618 > N: Device detected: XXX
16:24:20.635 > N: Device detected: XXX
16:24:20.640 > N: Device detected: XXX
16:24:20.671 > N: Device detected: XXX
16:24:20.833 > N: Device detected: XXX
16:24:20.979 > N: Device detected: XXX
16:24:20.997 > N: Send on /BTtoMQTT/XXX msg {"id":"XXX","name":"ATC_XXX","rssi":-63,"brand":"Xiaomi","model":"LYWSD03MMC","model_id":"LYWSD03MMC_PVVX","tempc":12.88,"tempf":55.184,"hum":88.23,"batt":49,"volt":2.
642}
16:24:21.233 > N: Device detected: XXX
16:24:21.312 > N: Device detected: XXX
16:24:21.499 > N: Device detected: XXX
16:24:21.517 > N: Send on /BTtoMQTT/XXX msg {"id":"XXX","name":"ATC_XXX","rssi":-70,"brand":"Xiaomi","model":"LYWSD03MMC","model_id":"LYWSD03MMC_PVVX","tempc":16.83,"tempf":62.294,"hum":64.04,"batt":78,"volt":2.
91}
16:24:21.748 > N: Device detected: XXX
16:24:21.961 > N: Device detected: XXX
16:24:22.081 > N: Device detected: XXX
16:24:22.311 > N: Device detected: XXX
16:24:22.332 > N: Send on /BTtoMQTT/XXX msg {"id":"XXX","name":"ATC_XXX","rssi":-46,"brand":"Xiaomi","model":"LYWSD03MMC","model_id":"LYWSD03MMC_PVVX","tempc":20.69,"tempf":69.242,"hum":59.89,"batt":78,"volt":2.
746}
16:24:22.641 > N: Device detected: XXX
16:24:22.688 > N: Device detected: XXX
16:24:23.298 > N: Device detected: XXX
16:24:23.302 > N: Device detected: XXX
16:24:28.051 > N: Device detected: XXX
16:24:28.716 > N: Device detected: XXX
16:24:30.564 > N: Device detected: XXX
16:24:30.564 > N: Device detected: XXX
16:24:30.581 > N: Device detected: XXX
16:24:30.582 > N: Device detected: XXX
16:24:31.245 > ESP-ROM:esp32c3-api1-20210207
16:24:31.245 > Build:Feb  7 2021
16:24:31.246 > rst:0x3 (RTC_SW_SYS_RST),boot:0xd (SPI_FAST_FLASH_BOOT)
16:24:31.246 > Saved PC:0x40381e1c
16:24:31.247 > SPIWP:0xee
16:24:31.248 > mode:DIO, clock div:1
16:24:31.250 > load:0x3fcd6100,len:0x438
16:24:31.252 > load:0x403ce000,len:0x918
16:24:31.255 > load:0x403d0000,len:0x24e4
16:24:31.260 > entry 0x403ce000
16:24:31.490 > N: 
16:24:31.490 > ************* WELCOME TO OpenMQTTGateway **************

argafal · February 17, 2023, 10:36am

Finally, after two hours or so, the OpenMQTTGateway dies. The last messages I get on serial console are:

DIAG0 120be3a0
DIAG1 10000005
BB DIAG0: 000a5384
                            BB DIAG1: cd003402
                            BB DIAG2: 00000000
                            BB DIAG3: 8e89bed6
                            BB DIAG4: 00000000
                            BB DIAG5: 00000000
assert rwble.c 261, param 00020000 00000000

It then sits in this state forever. Only remedy is a power cycle or pushing the reset button. Can anyone help with this?

1technophile · February 17, 2023, 10:47am

Let me try on a C3, I will get back to you

1technophile · February 17, 2023, 2:59pm

Reproducing the issue on my C3, will need some time to fix it

1technophile · February 17, 2023, 3:15pm

Seems to have an issue when reactivating the WatchDog, try to comment the line below and let me know:

github.com

1technophile/OpenMQTTGateway/blob/e3fca93e67a4510f8b887cef473715dc14da4fc8/main/ZgatewayBT.ino#L644


      
              pBLEScan->setActiveScan(true);
              timeBetweenActive = millis();
            } else {
              pBLEScan->setActiveScan(false);
            }
            pBLEScan->setInterval(BLEScanInterval);
            pBLEScan->setWindow(BLEScanWindow);
            BLEScanResults foundDevices = pBLEScan->start(Scan_duration / 1000, false);
            scanCount++;
            Log.notice(F("Found %d devices, scan number %d end" CR), foundDevices.getCount(), scanCount);
            enableCore0WDT();
            Log.trace(F("Process BLE stack free: %u" CR), uxTaskGetStackHighWaterMark(xProcBLETaskHandle));
          }
          
          
/**
           * Connect to BLE devices and initiate the callbacks with a service/characteristic request
           */
          void BLEconnect() {
            if (!ProcessLock) {
              Log.notice(F("BLE Connect begin" CR));
              do {

argafal · February 17, 2023, 3:33pm

[ 15520][E][esp32-hal-misc.c:128] disableCore0WDT(): Failed to remove Core 0 IDLE task from WDT
N: Scan begin
N: Device detected: XX
[repeats for about 20 devices]
N: Device detected: XX
N: Found 22 devices, scan number 1 end
ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0x3 (RTC_SW_SYS_RST),boot:0xd (SPI_FAST_FLASH_BOOT)
Saved PC:0x40381e1c
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd6100,len:0x438
load:0x403ce000,len:0x918
load:0x403d0000,len:0x24e4
entry 0x403ce000
N: 
************* WELCOME TO OpenMQTTGateway **************

Now it gets to the end of the scan, but it also it didn’t pass on messages on mqtt as far as i can see. (Note the absence of “Send on /BttoMQTT” messages.) And then it reboots.

argafal · February 17, 2023, 3:34pm

On the second boot it did send messages on mqtt and continue for a little while longer before the next reboot. One to three completed scans on average, then reboot.

So commenting out enableCore0WDT() made some improvement of sorts.

Edit: Updated with additional information after observing it for a while.

argafal · February 17, 2023, 5:19pm

As before, after an hour-ish the C3 stopped with the following errors.

N: Scan begin
N: Device detected: XX
N: Device detected: XX
N: Device detected: XX
N: Device detected: XX
N: Device detected: XX
N: Device detected: Xx
N: Device detected: ZZ
N: Device detected: ZZ
DIAG0 100be3a0
DIAG1 120b0025
BB DIAG0: 000a5384
                            BB DIAG1: d0004802
                            BB DIAG2: 00000000
                            BB DIAG3: 8e89bed6
                            BB DIAG4: 00000000
                            BB DIAG5: 00000000
assert rwble.c 261, param 00020000 00000000

argafal · February 20, 2023, 9:30am

@1technophile Question, and thanks a lot for your help! Can you still reproduce my issue when commenting that one line? Or does it then work for you as it should?

1technophile · February 21, 2023, 12:06am

Hello,

Give me a few days I will look more into it

1technophile · February 24, 2023, 8:44pm

Hello @argafal,

I think the issue is due to FASTLED, try to remove

  '-DRGB_INDICATORS=true'

You may have to define the pins to avoid an error loop on pin definitions:

  '-DLED_SEND_RECEIVE=2'
  '-DLED_ERROR=2'
  '-DLED_INFO=2'

Once done, I don’t have instability anymore

argafal · February 25, 2023, 10:06am

Florian, this is great. Good find. I confirm that removing the LED configuration resolves the boot loop.

Two minor observations:

The Lolin C3 mini board has a Neopixel (WS2812) on pin 7. We can simply decide not to use it.
When plugging the board into USB the neopixel led will either light up in some (random?) colour, or not. Whatever it does upon power up will stay until the end.

Two major observations. They may or may not be related to the specific board or its configuration:

OpenMQTTGateway now only works when there is a listener for the serial output. If I plug the board into just a power source I do not get any functionality of it. When I plug the board into a computer it works fine as long as I have pio device monitor running. If I stop the listener the OpenMQTTGateway stops reporting data and eventually the MQTT status message changes to home/OpenMQTTGateway/LWT offline.
I connected the board to a computer and let it run with pio device monitor recording the serial output. After about 15000 seconds of uptime everything stops working. I can reproduce this behaviour (time varies, one to a few hours of uptime until the error occurs). The error message is

N: Device detected: XXX
N: Send on /BTtoMQTT/XXX msg {"id":"XXX","name":"XXX","rssi":-33,"brand":"Xiaomi","model":"LYWSD03MMC","model_id":"LYWSD03MMC_PVVX","tempc":18.48,"tempf":65.264,"hum":61.41,"batt":68,"volt":2.682}
DIAG0 1000e1a0
DIAG1 120b0025
BB DIAG0: 000a4004
                            BB DIAG1: c1000c02
                            BB DIAG2: 00000000
                            BB DIAG3: 8e89bed6
                            BB DIAG4: 00000000
                            BB DIAG5: 00000000
assert rwble.c 261, param 00020000 00000000

The last MQTT output was as follows:

home/OpenMQTTGateway/BTtoMQTT {"bleconnect":true,"interval":55555,"activescan":true,"intervalcnct":3600000,"onlysensors":false,"hasspresence":false,"presenceTopic":"presence/","presenceUseBeaconUuid":false,"minrssi":-100,"extDecoderEnable":false,"extDecoderTopic":"undecoded","filterConnectable":false,"pubadvdata":false,"pubBeaconUuidForTopic":false,"ignoreWBlist":false,"btqblck":0,"btqsum":834,"btqsnd":805,"btqavg":1.036025}
home/OpenMQTTGateway/BTtoMQTT/XXX {"id":"XXX","name":"XXX","rssi":-65,"brand":"Xiaomi","model":"LYWSD03MMC","model_id":"LYWSD03MMC_PVVX","tempc":10.98,"tempf":51.764,"hum":79.78,"batt":43,"volt":2.59}
home/OpenMQTTGateway/BTtoMQTT/XXX {"id":"XXX","name":"XXX","rssi":-64,"brand":"Xiaomi","model":"LYWSD03MMC","model_id":"LYWSD03MMC_PVVX","tempc":13.95,"tempf":57.11,"hum":55.46,"batt":46,"volt":2.62}
home/OpenMQTTGateway/BTtoMQTT/XXX {"id":"XXX","name":"XXX","rssi":-33,"brand":"Xiaomi","model":"LYWSD03MMC","model_id":"LYWSD03MMC_PVVX","tempc":18.48,"tempf":65.264,"hum":61.41,"batt":68,"volt":2.682}
home/OpenMQTTGateway/LWT offline

Note that the sensor output here contains three sensors, whereas there are four to read. In the scans before that last one all four sensors have been seen/reported. This might be a coincidence, of course.

Do you have any advice for either of those two issues? Thanks for your help!

1technophile · February 27, 2023, 1:49pm

hello,

Could you share your environment definition please ?
I will try to reproduce it

mrickma · February 27, 2023, 8:20pm

I am here testing a Seeed Studio XIAO ESP32C3 and have reported in a different thread that it was running well. In part, however, I can reproduce @argafals findings. I use Linux “screen -L /dev/ttyACM0 115200” for serial connection. There is a difference between starting after an immediate serial connection and without serial connection. Without, it takes reproducibly nearly exactly 180s to send first MQTT, whereas with serial it starts sending almost immediately. However, WIFI is up immediately in both cases, as checking by pinging the device.
The long term >4h behavior I have not checked on my notebook where mosquitto is set up. I have just connected power supply and will report tomorrow.

argafal · February 27, 2023, 11:20pm

@mrickma Thanks for that report. I confirm your finding: when no serial listener is attached the module is not dead but indeed extremely slow. Is it waiting for an I/O timeout on every serial message?

@mrickma Can you also reproduce the assert rwble.c 261 error when running OMG with a serial console listener attached? It happens after anything between a few minutes and a few hours of runtime. I cannot see a clear pattern/trigger yet.

@1technophile Environment is as follows. My board is a Wemos Lolin C3 mini v2.1.0.

[env:lolin_c3_mini]                                                                                                                                                                     
platform = ${com.esp32_c3_s3_platform}                                                                                                                                                  
board = lolin_c3_mini                                                                                                                                                                   
board_build.partitions = min_spiffs.csv                                                                                                                                                 
lib_deps =                                                                                                                                                                              
  ${com-esp.lib_deps}                                                                                                                                                                   
  ${libraries.wifimanager32}                                                                                                                                                            
  ${libraries.ble}                                                                                                                                                                      
  ${libraries.decoder}                                                                                                                                                                  
build_flags =                                                                                                                                                                           
  ${com-esp.build_flags}                                                                                                                                                                
  '-DZgatewayBT="BT"'                                                                                                                                                                   
  '-DLED_SEND_RECEIVE=6'                                                                                                                                                                
  '-DLED_ERROR=6'                                                                                                                                                                       
  '-DLED_INFO=6'                                                                                                                                                                        
  '-DCONFIG_ESP_CONSOLE_USB_SERIAL_JTAG=true'                                                                                                                                           
  '-DCONFIG_ESP_CONSOLE_UART=ESP_CONSOLE_USB_SERIAL_JTAG'                                                                                                                               
  '-DNO_INT_TEMP_READING=true' ; Internal temperature reading not building on ESP32 C3 or S3                                                                                            
  '-DGateway_Name="OpenMQTTGateway_ESP32_BLE"'                                                                                                                                          
custom_description = BLE gateway on the C3

I have tried different LED pins which made no difference. I have also tried disabling the serial console entirely using -DCONFIG_ESP_CONSOLE_UART = ESP_CONSOLE_NONE in the environment definition. However, the serial output kept working and the problem of OMG on the ESP32C3 being dead/slow kept persisting (when no serial listener is attached).

1technophile · February 27, 2023, 11:23pm

To disable OMG logs you can try:
'-DLOG_LEVEL=LOG_LEVEL_SILENT'
'-DWM_DEBUG_LEVEL=0'

argafal · February 27, 2023, 11:31pm

Yes, now I can run without a serial listener attached. Thanks! Let’s see if it dies with the rwble error in a few hours again, will report again in half a day or so!

argafal · February 28, 2023, 8:19am

Reporting back: OMG died an hour and thirty minutes later, according to the MQTT logs. I assume it’s the same error (assert rwble 261) as before, but without the serial log I cannot know for certain.

argafal · February 28, 2023, 9:04am

I found a reference to the assert rwble.c 261 error. This seems to be a known bug: WiFi and ble run for a period of time, and rwble.c 261 error (IDFGH-7699) · Issue #9241 · espressif/esp-idf · GitHub. It is mentioned that this was recently fixed as of esp-idf release v4.4.3. The release notes of espressif32 v5.3.0 (Release 5.3.0 · platformio/platform-espressif32 · GitHub) suggest that it uses esp-idf@v4.4.3, whereas espressif32@5.2.0 uses esp-idf@4.4.2.

Thus, I changed platformio.ini:

- esp32_c3_s3_platform = espressif32@5.2.0
+ esp32_c3_s3_platform = espressif32@5.3.0

I re-enabled serial output.
I will report back in half a day or so.

mrickma · February 28, 2023, 8:53pm

Oh you have taken big steps. Let me report on my last night findings as promised. I am still in awe with the serial delays. So I have chosen the worst scenario, long term without serial connection. I connected the Seeed Studio XIAO ESP32C3 (C3 in the following) to a power supply and started logging:
mosquitto_sub -u test -P user -t # 2>&1 | tee mosquitto_sub.txt
This morning, info and power leds were on, send/receive and error leds were constantly off. Then I checked the logging.

[mrickma@lahp Platformio]$ date -R
Tue, 28 Feb 2023 08:21:16 +0100

[mrickma@lahp Platformio]$ stat mosquitto_sub.txt
File: mosquitto_sub.txt
Size: 783053 Blocks: 1544 IO Block: 4096 regular file
Device: 259,4 Inode: 10209198 Links: 1
Access: (0644/-rw-r–r–) Uid: ( 1001/ mrickma) Gid: ( 1001/ mrickma)
Access: 2023-02-27 20:17:04.026706468 +0100
Modify: 2023-02-28 06:04:08.747746320 +0100
Change: 2023-02-28 06:04:08.747746320 +0100
Birth: 2023-02-27 20:17:04.026706468 +0100

[mrickma@lahp Platformio]$ ping 192.168.1.139
PING 192.168.1.139 (192.168.1.139) 56(84) bytes of data.
From 192.168.1.98 icmp_seq=1 Destination Host Unreachable
From 192.168.1.98 icmp_seq=2 Destination Host Unreachable
…
The C3 had been sending MQTT for about 9h 47min (35220 sec) and was unresponsive thereafter. The MQTT log showed three LYWSD03MMC_ATC which were correctly decoded. Other TH-sensors were only recorded because they were advertising in BTHome format. During the whole period the C3 went offline 40 times. On average that meens every 15 min offline. Minimal uptime inbetween the offlines was 317, maximal uptime 22025 just at the end. Otherwise, the these periods appeared randomly distributed.
I suspect that this degree of on/off is not normal. That the C3 appeared dead in the morning does not look too good either. This definetly contrasts the good feeling which I had when the C3 had serial connection. Tonight I will log both MQTT and serial output with timestamps added. Then I can compare and look for assert errors.
My esp32_c3_s3_platform is still at 5.2.0. If Espressif has fixed the concurrency problem on sigle cores in a general way then 5.3.0 may fix also the serial trouble. Let us hope.