Two instances of main code appeared

[pavolsvancarek]

Port, board and/or hardware

esp32 wemos mini d1

MicroPython version

i dont remember the version. It could be 1.21 - 1.18

Reproduction

no code needed. I scanned my code for potentional issues. i dont create second instance and it has been running long time without issue

Expected behaviour

it is written down

Observed behaviour

it is written down

Additional Information

Hey. I have been running my micropython code on esp32 wemos mini d1 for like a year now. Its been running on the tree for my side project. Its been working perfectly fine but something unexpected happened. I am running the reset and deepsleep functions there so i dont consume that much power from the battery that is powered by solar panels. In my code, i am creating a new thread from main thread that does just simple tasks. it is NOT connected to the main thread again. It runs separately. The behaviour of this project was correct for the last year. But today i saw probably two main threads running at the same time. I am not creating second instance and the only thing with creating second thread was already described.

The deepsleep and reset function in the past year reseted my microcontroller probably 10 000 times so maybe i caught really rare ocasion that somehow did happen.

My thought process is that it tried to reset the main or schedule deepsleep and because of something it either did not kill the already running instance and created second one, or it scheduled two instances that started running just few miliseconds after each other when the deepsleep time passed.

Today it was rainy, the moisture was in the air, its also possible that it was under higher load or whatever. i am not 100% sure and i have no way of getting log data. There could have been short circuit.. i did not found any info on internet about this and AI also says that its impossible to get two instances just by short circuit but i think its worth giving it some time to look for this potentional issue

Code of Conduct

Yes, I agree

[Plaque-fcc]

First of all, consider upgrading your firmware to v1.23.0 — it is possible that the bug you encountered in an older firmware has been already fixed since.
Also, when you do soft-reboot, MicroPython tells you which version you're using, so you can write down which version it was.

[pavolsvancarek]

Sure... I will go hike 400m hill 10km from my house to setup long 30m lan cable with lan to usb connectors to plug into my pc from ground (microcontroller is in the trees) every month just to update firmware haha

Yes, that is possible. Btw, that instance was running whole day and drained battery. I tried resseting it with SMS commands but only the other instance got removed (i saw it because it has led lights that signalize the weather). It will drain the battery till the bms says stop. Then it will be hopefully fine. I know that update could remove that issue, but i thought i found maybe something really rare that normal person would not see (but i can because its resseting often and running long time with visual aspects so i can visualy see that two things running paralel). Thats why i reported this. Maybe its fixed, but if this happened to me after a year, probably i wont see it happening for long time again

[projectgus]

Sure... I will go hike 400m hill 10km from my house to setup long 30m lan cable with lan to usb connectors to plug into my pc from ground (microcontroller is in the trees) every month just to update firmware haha

With all due respect, MicroPython v1.18 came out in January 2022 and there have been a lot of code changes since then. Updating is a reasonable thing to try if you think there's an issue that isn't in your code.

[peterhinch]

This is not a bug report that the maintainers can reasonably be expected to action, so I have converted this to a discussion.

[projectgus]

@pavolsvancarek As peter pointed out, there's not really enough context here to debug from or give many suggestions other than to try updating to a more recent MicroPython. If you can post your code, at least the function(s) where it calls deep sleep and where it spawns the other thread, then someone might be able to give some more pointers.

One bit of context that might be useful: in MicroPython versions older than v1.22 then it is possible for machine.deepsleep() to return if deep sleep fails to start due to some unexpected hardware issue, and execution of the Python program will continue. Since v1.22 this can't happen, if deep sleep fails to start then the ESP32 resets instead.

[pavolsvancarek]

If thats the case, then that indeed could have cause it. Yes it is running below v1.22.