Exception when setting GPIO to WS2812 #5581
Comments
|
Sdk 3.0.0 you used is known to be buggy. We provide no support for. |
|
Ahh fair enough. Will try the prebuilt images shortly. I wasn't aware I was using the 3.0 version of the SDK. Apologies for the naive question but is that a VS Code or Platform IO component? |
|
Very interesting thing happened. So I uploaded the prebuild image of sonoff (the recommended 2.3.0 binary). Reconfigured wifi & GPIO and it worked perfectly. 20 minutes later, went to configure my MQTT settings (server and topic) and it crashed with the same exception details as above. |
|
Looks like a power supply issue of the ESP8266. Sdk 3.0.0, 2.2.1 and 1.5.0 is the code to make the ESP useable (compatible) with a IDE and needs another layer (Arduino ESP) to make it useable with Arduino. |
|
Exception 0 is a illegal instruction in program memory and it is most of the time related to not enough power issue. Another cause of that is a broken flash memory, but that is not so frequently. Also, this can be a bad flashing with not enough power when flashing leading to incorrect data stored in flash. Please, try another board. |
|
Closing this issue as it is hardware related and nothing can be done from Tasmota software side. Please, if you need further assistant, you can address this to the Tasmota Support Chat. The chat is a better and more dynamic channel for helping you. Github issues are meant for Tasmota Software Bug Reporting. Please check the Contributing Guideline and Policy and the Support Guide). Thanks. Support InformationSee Wiki for more information. |
|
Hey @ascillato2, thanks for replying. Unfortunately while the exception 0 explanation may be correct most of the time, I think it may be incorrect here. My reasoning is by clearing retained MQTT messages and trying the prebuild (or using core in my own compiled version), the exact same device with the exact same power supply works perfectly fine past several power cycles and 100% brightness calls (from 0%). If it was due to a power supply issue or flash failure (or other hardware failure) then I would expect the problem to persist? I think I'm getting slightly closer to the issue. As I mentioned above, one of the key actions I did last night was to clear the MQTT retained messages. That seemed to solve the issue. When I looked to see what messages had been retained, an openHAB rule I had made had tried to call HSBColor with 255,0,0 (I now know thats an invalid HSB code!) among other calls (dimmer & scheme) within quick succession. I'm going to be trying to reproduce it today to hopefully have some steps for others to replicate what I'm seeing. |
|
I have been searching and another cause of exception (0) is a bad flashing due to not using DOUT. So, can you confirm that you have erased all flash with esptool.py as explained in the wiki and flashed the precompiled bin with esptool.py with DOUT as explained in the wiki? |
|
Not explicitly. Annoyingly I haven't been able to reproduce the problem today either. I'll keep playing but if I come up against the problem again and can offer more information I'll update further. Until then, thank you for the suggestions (especially the core bits)! |
|
So, don't worry. Sometimes this weird issues are just a bad flashing. Erasing and flashing again (with esptool.py) solves these problems |
I previously raised this as #4645, however I've been experiencing this again today. The previous issue was mistakenly raised as boot loop reverting settings. To be clear - that is not the issue here.
After upgrading to 6.5.0.4 today, my D1 mini goes into a boot loop. Once it's finally cleared the GPIO settings, I try and reset the D4 pin to use WS2812 and it causes an exception triggering the boot loop once again.
Things I've tried today:
I can also provide the stack traces here:
Any clues?
The text was updated successfully, but these errors were encountered: