ESP8266 Community Forum

- Mon Feb 02, 2015 2:05 am #8748 How can we solve this problem? Have you any idea?

Same here after several 10 deep sleeps, captured this in zombie mode with off-the-shelf NodeMCU 0.9.5 build 20150127

MEM CHECK FAIL!!!\r\n
Fatal exception (29):\r\n
epc1=0x40222788, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000044, depc=0x00000000\r\n

Checked the pins with an oscilloscope. There is a heavy (voltage > Vcc) 1kHz oscillation on the GPIO0 pin in the error case.

That signal is always there when booting but in the boot-ok case it disappears after about 100ms.

ESP8266.com Moderator
Lets get the party started and +1

[url=https://www.banggood.com/custlink/KvGGhGF4wG[/url]

I like ESP8266 and ESP8285 and ESP32

- Mon Feb 02, 2015 3:24 am #8752 Sorry, I have very little information about this chip, just got my -01 boards.

just guessing:

- some chip-internal switching power supply not starting
- instruction/data cache not setup properly before deep sleep/when starting
- the SPI memory chip not starting correctly
- some internal hardware module not disabled properly before deep sleep

Is there any information on the addresses that are given in the message?
Does this "mem check fail" happen in the boot ROM code?
Did the boot ROM try to read from SPI memory already?
Are the caches initialized at that point?
Do other designs have more/other blocking capacitors at some pin?

Tried to

- put different capacitors to GPIO0
- put different resistors to GPIO0
- add capacitors to the power supply
- tried to disable Wifi before sleeping

None really helped. Having a higher and more stable (added capacitors) supply voltage increased the likeliness that the device booted ok. That could mean it is related to the internal switching supply.

Next thing would be to have a look at the SPI lines at boot.

- Mon Feb 02, 2015 10:05 am #8776 Although I haven't been investigating due to other commitments, I do have a few chips cycling here for observation.

I am noting that sometimes the failure to resume occurs when the previous cycle failed to complete the WiFi transaction. Either didn't connect to the router or didn't complete the TCP/IP connection to an on("disconnection" response before the timeout put the chip back to sleep.

This may be a red herring. But I am noting it for others looking for a cause and solution in case it might be relevant.

2 days is still the record for sleep and restart for me. (1 minute cycles).

Infinity is the goal...

I am not (intentionally) reading or writing flash.

Peter

ESP8266 for dummies, LuaLoader and project updates: http://benlo.com/esp8266

- Tue Feb 03, 2015 10:56 am #8861 I've asked a question on the EEVblog forum because this smells so weird I'm hoping that someone with broad experience will recognise it and be able to help us work out what's going on.

http://www.eevblog.com/forum/projects/e ... -failures/

I'm happy to act as a forum gateway here!