Thanks @1technophile , in fact I was going a little too OT here 
Another update: the C3 arrived at 57490 seconds of uptime (roughly 16 hours) and then hang again.
Now trying @mrickma suggestions
Of course, I’ll have to wait for 16+ hours to tell if it has solved the problem or not, but for now I can tell the average power consumption stayed the same (usually, this is a good indicator of “how much stuff is going on”) at roughly 75mA
@ilgrank: Sorry, you were doing so well. If it is a complete hang you were probably hit by the “assert rwble.c 261, param 00020000 00000000” error. Remedy should be upgrading to “platform = espressif32@5.3.0” in your build environment. Best wishes.
@mrickma : I’ve tried the following config (mostly a copy of yours) but this time it lasted even less: only 9649 seconds before hanging… I’m really puzzled 
[platformio]
default_envs = seeed_xiao_esp32c3
[env:seeed_xiao_esp32c3]
;platform = ${com.esp32_c3_s3_platform} ; standard, problems
platform = espressif32@5.3.0 ; override
board = seeed_xiao_esp32c3
board_build.partitions = min_spiffs.csv
monitor_speed = 115200
lib_deps =
${com-esp.lib_deps}
${libraries.wifimanager32}
${libraries.ble}
${libraries.decoder}
build_flags =
${com-esp.build_flags}
'-DZgatewayBT="BT"'
'-DTRIGGER_GPIO=7' ; Reset button
'-DNO_INT_TEMP_READING=true' ; Internal temperature reading not building on ESP32 C3 or S3
'-DLOG_LEVEL=LOG_LEVEL_SILENT'
'-DWM_DEBUG_LEVEL=0'
'-DGateway_Name="OpenMQTTGateway"'
'-DBase_Topic=""'
'-DESPWifiManualSetup=true'
'-Dwifi_ssid="myssid"'
'-Dwifi_password="mywifipass"'
'-DMQTT_USER="mqttusr"'
'-DMQTT_PASS="mqttpass"'
'-DMQTT_SERVER="192.168.0.102"'
'-DsimpleReceiving=false'
'-UZmqttDiscovery' ; Disable HA discovery
'-DNTP_SERVER="pool.ntp.org"'
Another day, another update. Using the ‘default’ ${com.esp32_c3_s3_platform} platform this time It got to 46970seconds , that is 13 hours… and then hang again
I will try to reproduce with my M5Stamp c3
@ilgrank: I have several points what to omit from your configuration. But before grasping at straws, try to add
'-DLED_SEND_RECEIVE=10' ; dummy but valid GPIO
'-DLED_INFO=10'
'-DLED_ERROR=10'
to your build environment. I recommend this because I had fast firmware hickups on a different ESP32C3 board last night,
gpio: gpio_set_level(226): GPIO output gpio_num error
, when the signalling LEDs were not declared.
I had missed (up to this evening) the other thread about the C3 crashing, lots of interesting discussion there!
Unknowing of that thread,I had been experimenting with platform = espressif32@6.0.1
and while it still had problem, my C3 rebooted instead of hanging. (not ideal, but better than having to reset manually)
Now I’m back to 5.3.0 and trying @mrickma suggestion about the neeed to declare LEDs.
As usual, I’ll keep the thread updated with my findings
Thanks for the support @mrickma and @1technophile !
1 Like
@mrickma : Alas, it lasted 16325 seconds and then rebooted.
Reading the other thread, I’m exactly in the same situation as @argafal : the reboots are better than the hangs I had before, but still not an ideal situation…
here is my full env (just redacted the passwords)
[platformio]
default_envs = seeed_xiao_esp32c3
[env:seeed_xiao_esp32c3]
;platform = ${com.esp32_c3_s3_platform} ; standard, problems
;platform = espressif32@6.0.1 ; uses more resources, same reboots
platform = espressif32@5.3.0
board = seeed_xiao_esp32c3
board_build.partitions = min_spiffs.csv
monitor_speed = 115200
lib_deps =
${com-esp.lib_deps}
${libraries.wifimanager32}
${libraries.ble}
${libraries.decoder}
build_flags =
${com-esp.build_flags}
'-DZgatewayBT="BT"'
'-DLED_SEND_RECEIVE=10' ; dummy but valid GPIO
'-DLED_INFO=10'
'-DLED_ERROR=10'
'-DNO_INT_TEMP_READING=true' ; Internal temperature reading not building on ESP32 C3 or S3
'-DLOG_LEVEL=LOG_LEVEL_SILENT' ; No serial Out to prevent C3 from overloading
'-DWM_DEBUG_LEVEL=0' ; Same as above?
'-DGateway_Name="OpenMQTTGateway"'
'-DBase_Topic=""'
'-DESPWifiManualSetup=true'
'-Dwifi_ssid="myssid"'
'-Dwifi_password="mypass"'
'-DMQTT_USER="OMQTTG"'
'-DMQTT_PASS="password"'
'-DMQTT_SERVER="192.168.0.102"'
'-DsimpleReceiving=false'
'-UZmqttDiscovery' ; Disable HA discovery
'-DOMG_VERSION="1.4.0b"'
'-DNTP_SERVER="pool.ntp.org"'
@mrickma : if you have any other idea, I’m open to any suggestion of course, and willing to experiment Thanks
Good to hear that someone else can reproduce my issue. Thanks for reporting. Did you look at the serial output? Do you see any error message or Exception? (I didn’t.)
In the latest tests, I have serial output disabled, so I can’t check if there’s any error.
From what I see tho, having serial disabled did not change the stability of the C3
I’ve been also following a thread here and trying an older version of expressif32 library (4.4.0)
From what I can see, it has a lot (10kb) more free memory, but I’m just at 6000 uptime, l’ll post my findings later on
If it is a memory leak (as I suspect to be) it should maybe last a little longer
…nope. Even with 4.4.0, it lasted 25326 seconds (roughly 7 hours) and then rebooted:
I really wonder what causes these occasional random reboots which you @ilgrank and @argafal experience. I do not have them any longer with the Seeed board. The Espressiv ESP32C3 board which I test is currently uptime > 113000. I am having the boards connected either to an USB3 port of my notebook or to power supply which we use to fast-charge our mobiles. Both provide plenty of current.
So tried to forget about configurations and looked for information on power requirement of the ESP32C3. The board makers seem to publish data on static conditions like having switched on WIFI with an AT command. For our situation I found the Espressiv ESP32C3 Series Datasheet more realistic. The document is long and written for electronics experts. When you search in it for “0 ma” you will find “500 mA or more” in the section on recommended operating condition. That seems an aweful lot for such a small piece but a condition I have fulfilled.
See you.
1 Like
I’ve tried different power supply, and now it is hooked to a quality (genuine samsung mobile) ‘old’ (ie: non-USB-PD enabled) 1500mA USB power supply.
It did not make a difference, alas.
I’m using a Seeed XIAO C3, but I’ve been able to replicate the problem in other C3 boards as well
I’m investigating also the restarts
@mrickma Thanks for thinking out of the box. I have tried the Lolin C3 mini on a different (better) power supply. The random reboots remain the same. I think we can rule out the power supply as an explanation for them.
I begin to think there may be an error in the C3 libraries (given the C3 has a different µarch than the ESP32, that may even be likely)
The same code, recompiled for the ‘plain’ ESP32 has been running for more than 166000 seconds (more than 46 hours) with no hang and no reboot
@argafal : btw I’m using a different C3 board than yours: the Seeed XIAO C3 but I’m having exactly the same issues.
As a side note, I’m using the released OMQTTGW 1.4.0 codebase, and not a git clone. What are you using?
Yes, we are using different C3 boards. I use a Wemos Lolin C3 mini v2.1.0. I believe @mrickma did tests using the same board as you. They couldn’t reproduce our random reboots, afaik.
I used git hash 1b5215de, one of the most recent development snapshots. In a sense it’s good to hear that you reproduced the problem also with a stable release. So it’s probably not a very recently introduced (new) bug.
Honestly, I doubt it has anything to do with MQTTGateway, it is most likely a bug in Expressif C3 libraries, as even other projects using the same libraries are experiencing the same issues. See here as an example.
…and the same code, compiled for an ESP32, runs perfectly
I agree, @ilgrank. It’s totally possible that this is a bug in Espressif for the C3.
On the other hand, I have not seen a similar issues yet using a C3 in other projects. But that doesn’t necessarily mean much.
The issue you quote (XIAO ESP32 C3 not restarting - #6 by Musa_Khan - Arduino & Seeeduino - Seeed Forum) though discusses someone who couldn’t flash a new programme, since they didn’t push the boot button, did I get that right? I see nothing there about a random reboot without an error message. Maybe you accidentally linked the wrong issue?