ESP8266 Community Forum

- Fri Apr 10, 2015 3:06 am #14076

Hi all,

Just to confirm this zombie mode is specific to lua nodeMCU firmware, indeed I compile a native C program and didn't have this issue on the same hardware.

I think this has been mentioned in a previous post.

Conclusion, if you need deep sleep, you will have to compile your own code for the time being.

Cheers,
Plucker

Yes, this is correct for me also. With nodeMCU it went to zombie mode in 30 minutes or less (30 second deep sleep). In native mode no problem for 24 hours (30 second deep sleep). Same module esp-01.

Regards, Ales

- Fri Apr 10, 2015 11:26 am #14121 Hi all,

this calls for someone with solid expert knowledge and time to spare to review the nodeMCU source to find the bug
I am quite sure, that at least the "nodemcu_512k_20141219.bin" did NOT have the issue! Unfortunately, this task is out of my league...

Best regards
Heinz-Georg

- Sat Apr 11, 2015 3:31 pm #14214 Moin,

I wonder if the node prints a last farewell before it went zombie.

Thanks to this hack by Tim Jagenberg (http://tim.jagenberg.info/2015/01/18/low-power-esp8266/, many thanks for the post!) I was able with more luck than expertise to get deep sleep working.

I am also able to enter zombie mode
But the last message that is printed on serial in these cases is an exception 29 in some pm code from libphy.a.
I was able to change that now to

Fatal exception (0):
epc1=0x40210424, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x00000000

I know that exception 29 is an illegal write but what this exception is, I don't have a clue.

Do you get similiar exceptions on any baudrate of 115200/9600/74880 before your modules enter zombie mode?

Carsten

Get your modules here:

https://www.banggood.com/custlink/KvGGhGF4wG

- Tue Apr 14, 2015 3:21 pm #14507 Moin,

any information about exceptions available?
I was able to repeat an exception 29, always in the same method pm_wait4wakeup.
Then I wanted to get more control about the failing code:

1. I rewrote the method in c
2. Replaced the call side to use my method.

Now the test code that does 1s dleep and increments counter in file in fs runs for 3 days now.
I don't think its a bug in the library code I rewrote.
Lua flash code and spiff filesystem share same flash, yes? Can the code be corrupted?
That could explain cases where some/full reflash was needed.
In my case a reset was enough. The flash part is somehow being cached by ram, yes?
Is that corruptable somehow so that its fixed on reset?

Any ideas?

Carsten

P.S. I was able to force a fatal exception 29 by accessing memory location 1040 and my pc and the memory address
I accessed were correctly reported so the exception message at 115200 baud can be helpful.

Get your modules here:

https://www.banggood.com/custlink/KvGGhGF4wG