ESP8266 Community Forum

- Mon Apr 27, 2015 4:23 pm #15845

Wow ! I have tryed many hardware things... Pull up/down on GPIO0, GPIO2, GPIO15 an RST. Also a 470pF capasity on the RST to GND. All without luck
My ESP-07 is going intozombie mode, after 5-8 minutes, with 1 minute deepsleep.

But the I suddenly tryes to flash "INTERNAL://DEFAULT" and "INTERNAL://BLANK" via NodeMCUflasher. And now my ESP-07 has rund for 5 days with 1 minut deepsleep loop, without any problems I have also removed all pull up/down from my board. Only a pull down 12Kohm on GPIO15.
(Select the 0x7C000 default and 0x7E000 blank sections. Uncheck the box for the 0x10000 IROM section.)
I followed this: http://benlo.com/esp8266/esp8266QuickStart.html

Please try it !!

HI,

I am not completely clear with your proposal !
You mentionned to follow Benlo's link and use NodeMCUflasher. Do you mean ESP8266Flasher.exe ?

If yes your advice is to reflash only DEFAULT and BLANK and to uncheck IROM ? And what about INTERNAL/FLASH ?

JP

- Mon Apr 27, 2015 4:28 pm #15846

I did a really brute force short test using parts of the libmain.a of esp-opensdk:

esp-open-sdk/esp_iot_sdk_v1.0.0/lib/libmain.a (105626 bytes)

In short I extracted user_interface.o from that lib,
removed user_interface.o from nodemcu libmain.a and added the extraction above.
Added fake symbols for the 2 link errors and nodemcu started OK and runs for 20 minutes now
without a crash. Can't test any longer now.

Maybe we should concentrate on making nodemcu usable with latest SDK to avoid fighting ghosts?
From what I understood from comments I read the main reason for not using it is less free memory?
But at some time that problem has to be solved anyway.

Cal

Hi,

I have read all this post (quite complex) and finally designed my own braedboard for ESP12 with all the pull up and so on.
The result is a ...non working deep sleep (I shopuld have read more deeply !)

Well, I have also read that you can reproduce a version of firmware (without MQTT) but working.
Could you please post these files so that I could check them with my code ?
(Currently I had been able to run 900 deep sleeps before bugging)

Thanks in advance
JP

- Mon Apr 27, 2015 8:06 pm #15867

Maybe we should concentrate on making nodemcu usable with latest SDK to avoid fighting ghosts?

Once I got things working I switched to building/linking against the latest 1.0.1b2. Making this change (using the /includes and two from /lib from that SDK ) did not require any other change so I assume the API is compatible. Nevertheless, I am not sure that the nodemcu-firmware checkout does not include copies of 0.9.5 items (thus making the swap partial).

cheers

- Tue Apr 28, 2015 12:06 am #15873 Moin,

the nodemcu does contain 0.9.5 libs. For example libmain.a. They need to be replaced including helper files.
When the changes to nodemcu code can be done in way compatible to 0.9.5 they can be put back into
dev branch. A new dev10 then needs to contain only the minimal changes to actually switch to sdk 1.0.
I would start with including the 1.0 includes/libs until official sdk stabilizes to have defined versions.
In one of the issues tickets where i was involved in discussion is a link to someone who did a port.
Issue is about reset when accessing busy flash. Maybe another issue thats fixed in more recent sdk.
I try to find some time to look into this.

Cal

Get your modules here:

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