how to hang ESP module

[kwis2]

According to #1020 there is very simple way to kill ESP with WDT unable to wake up module. I have tested ESP8266-01 and WeMOS modules. Simple program could kill module forever and only hard reset could it awake. Works with any version of Sming from 2.1.5.
The reason is System.restart() command.
I have written very advanced software which after 10 seconds run System.restart() and:

19:26:50.328, tick
19:26:52.403, tick
19:26:52.512,
19:26:52.512, ets Jan 8 2013,rst cause:2, boot mode:(1,6)
19:26:52.512,
19:26:59.610,
19:26:59.610, ets Jan 8 2013,rst cause:4, boot mode:(1,6)
19:26:59.610,
19:26:59.610, wdt reset

and a few minutes later reset button pressed

19:29:36.094, goî<0>dŚÇ$����o'�l���o;Ç›Ű'�›lś�d8űgŕ���r„śÜăŕ��b'ă|��l„‡cÄň'oď<0>�d����ng�l���'{‡“›g�ó$l �xónŕ��{Śśśăŕä�c�gă|�Ś$쎇#Äňnoď<0>�d���'o$���g{Ź’›o��dl��r›Ű'��ld�don't use rtc mem data
19:29:38.278, ;l<0>dśź|<0>Ś$ŕ|���Ädě�c<Ç��ä�“›lś�d8űgŕ���r„śÜăŕ��b'ă|��l„‡cÄň'oď<0>�d����ng�l���'{‡“tick
19:29:40.353, tick
19:29:42.318, tick

[ADiea]

Hi Are you saying System.restart is not working as expected?

[kwis2]

Exactly. I didn't expect that module hang forever.

Try yourself ...

below advanced program I used. Basic_blink application.cpp modification

#include <user_config.h>
#include <SmingCore/SmingCore.h>

Timer procTimer;
int state = 0;

void blink()
{
    //	digitalWrite(LED_PIN, state);
    state  ++;
    Serial.println("tick");
    if(state>10)
    {
        System.restart();
    }
}

void init()
{
    //	pinMode(LED_PIN, OUTPUT);
    Serial.begin(115200);
    procTimer.initializeMs(2000, blink).start();
}

[ghost]

rl�lœž|�Œlà|����Œ�lì�b|Ž‚�ì�’r’bŒ�bŒònnžlnnœâì�b�pìŽlrlrlpònà����‚�l������b�nâ|�ŒŒŽŽ|œ�bŒònnî�lŒŽl`����nnlŒl`���nrŽ’’n��rìl`�`òn���žàb‚nlŒ�Œònnî��Ž�lpònà����rŒœœâà����b�nâ|��lŒŽbŒònnî�lŒ�l`����nn�Ž�l��nrŽ’’n���Œl`�pònà����rŒœœâàì���b�nâ|�ŒŒ��ŽbŒònnî��Žl`����nn�l`���nrŽ’’n��‚�’`��r’’n��‚�’`�Œâ�ì�‚nì’r‚òn|ì�lŒìl`�Œâr’lŒþtick
tick
tick
tick
tick
tick
tick
tick
tick
tick
tick

 ets Jan  8 2013,rst cause:2, boot mode:(3,7)

load 0x40100000, len 26796, room 16 
tail 12
chksum 0x33
ho 0 tail 12 room 4
load 0x3ffe8000, len 896, room 12 
tail 4
chksum 0x82
load 0x3ffe8380, len 2204, room 4 
tail 8
chksum 0xda
csum 0xda
Œâ�ì�‚nì’r‚òn|ì�lŒìl`�Œâr’lŒþtick
tick
tick
tick
tick
tick
tick
tick
tick
tick
tick

 ets Jan  8 2013,rst cause:2, boot mode:(3,7)

load 0x40100000, len 26796, room 16 
tail 12
chksum 0x33
ho 0 tail 12 room 4
load 0x3ffe8000, len 896, room 12 
tail 4
chksum 0x82
load 0x3ffe8380, len 2204, room 4 
tail 8
chksum 0xda
csum 0xda
Œâ�ì�‚nì’r‚òn|ì�lŒìl`�Œâr’lŒþtick
tick
tick
tick
...

It works as expected!

Check your power supply and connections

[kwis2]

@neut2012 thank you for your help. I have been working with hang up problem for more than week without any result. I have checked several modules, I was able to get, and only by your help I think I found the reason.
With your module (btw. which module you use?) I found that reason is boot mode.
As you can see your module boot with boot mode (3,7) but my module boot with (1,6) regardles of GPIO0 state. What mean that module "remember" its power up GPIO0 state, and System.restart makes module boot into programming mode.
Question for now is how could I reset module to be sure that it won't go into programming mode, or just test GPIO0 boot state?

log for programming mode boot mode (1,7)

8:39:38.766, tick
8:39:40.735, tick
8:39:40.842, 
8:39:40.842,  ets Jan  8 2013,rst cause:2, boot mode:(1,7)
8:39:40.842, 
8:39:47.941, 
8:39:47.941,  ets Jan  8 2013,rst cause:4, boot mode:(1,7)
8:39:47.941, 
8:39:47.941, wdt reset

**and press reset after a few minutes**

8:41:43.108, ���og�l ���n;‡“Űg�űll`�xűoŕ���;Śśśăŕě�b'ă|�„l䏇bŚóogç<0>�$`����og�l`���'{‡“›g��$l`��s›’n��ld`�don't use rtc mem data
8:41:42.999, {l<0>lśź|<0>Śdŕ|��Äděc<Ç��ä�’{ŰcÄbŚóogźl'ośăě#�pŚŹ${lóogç<0>�$`����og�l`���'{‡“›g��$l`��s›’n��ld`�don't use rtc mem data
8:41:45.292, gŕ���sÄśśăŕ��cnâ|�lć#Śóogď<0>$`�tick
8:41:47.258, tick
8:41:49.333, tick

and below log with run mode boot mode (3,6)

8:42:25.696, tick
8:42:27.662, tick
8:42:27.771, 
8:42:27.771,  ets Jan  8 2013,rst cause:2, boot mode:(3,6)
8:42:27.771, 
8:42:27.880, tail 0
8:42:27.880, chksum 0x5e
8:42:27.880, load 0x3ffe8000, len 896, room 8 
8:42:27.880, tail 8
8:42:27.880, chksum 0x71
8:42:27.880, load 0x3ffe8380, len 2176, room 0 
8:42:27.880, tail 0
8:42:27.880, chksum 0x89
8:42:27.880, csum 0x89
8:42:27.880, don't use rtc mem data
8:42:27.771, load 0x40100000, um 0x71
8:42:30.064, load 0x3ffe8tick
8:42:32.030, tick
8:42:34.105, tick

[ghost]

I'm using an ESP12. Please make sure your connections are correct for proper boot mode

[ADiea]

also gpio15 should be pulled to ground with something like 4k7

[kwis2]

With ESP8266-01 except TX and RX I have only two pins availiable. GPIO0 and GPIO2, and when I would like to program module I have to pull down GPIO0 while reset. GPIO0 which in your circuit is permanently pulled high, so you are not able to go into programming mode, which is source of my problems. I don't know how you are able to program module - botloader ?
I am wondering if problem with GPIO0 state while System.restart() is SDK not Sming problem?

[ghost]

I posted this circuit just for illustration.. I simplified it (and I accidentally removed the connection of GPIO15 to ground, like @ADiea noted) just to try and help you.. I program it using a usb-to-ttl adapter with RX, TX, RTS, DTR connected to TX, RX, GPIO0, RESET respectively.

I am wondering if problem with GPIO0 state while System.restart() is SDK not Sming problem?

No. Neither!

[kwis2]

boot mode (1,X) mean GPIO0 connected to ground. boot mode (3,X) mean GPIO0 high state. Question is why modules I checked ESP8266-01, ESP8266-01S and WeMOS show low state of GPIO0 and I measure 3.28 V on pin while System.restart()

[uzi18]

Do You use oryginal bootloader or rboot? Original hangs on rx not pulled to ground with resistor. 13.03.2017 9:53 PM "kwis2" <notifications@github.com> napisał(a):

…

boot mode (1,X) mean GPIO0 connected to ground. boot mode (3,X) mean GPIO0 high state. Question is why modules I checked ESP8266-01, ESP8266-01S and WeMOS show low state of GPIO0 and I measure 3.28 V on pin while System.restart() — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1024 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHOU89NTRNUdiiERWBKippPiJHySDNwks5rlazPgaJpZM4MaSrR> .

[anakod]

If ESP in flasing mode (GPIO0 low) than module willn't start your code but will wait external flashing instead. This is hardware connection issue. Please try reset module by hardware reset button and compare results.

[kwis2]

As you can see module work without reset after flashing. In fact modules work properly after hardware reset, but I would like not to worry about module, so for now I am looking for way how to efficiently reset module by soft reset.
@uzi18 I am not sure if with flash mode I am using any bootloader

[anakod]

As you can see module work without reset after flashing
Yes, it's standard behavior and isn't related.

If you module stay in programming mode how it can start after reset? Bootloader will go to programming mode after soft reset as expected then. So you should check GPIO0 connection.

[riban-bw]

@kwis2 The ESP8266 has 3 boot modes which are selected by the state of three pins.
To download new firmware from the serial port and write to ESP8266 flash, GPIO0 should be pulled to 0V, GPIO2 should be pulled to 3.3V and GPIO15 should be pulled to 0V. This is the programming mode.
To boot from the internal flash memory, GPIO0 should be pulled to 3.3V, GPIO2 should be pulled to 3.3V and GPIO15 should be pulled to 0V. This is the normal run mode.
To boot from external SD memory, GPIO15 should be pulled to 3.3V. (Other pins do not matter.) This is not a mode specifically supported by Sming.

So the first two modes are of interest. To allow the GPIO pins to be used by your program, you don't want to tie any to supply rails. Add a resistor (approx. 10K) between the pin and the supply rail that is required for normal run mode, i.e. connect a 10K resistor between GPIO0 and 3.3V, a 10K resistor between GPIO2 and 3.3V and a 10K resistor between GPIO15 and 0V.

To allow flashing a new firmware, connect a push to make, non latching switch between GPIO0 and 0V. This may be pressed at power-up to force GPIO0 low and hence put the device in flash update mode. When released, GPIO0 will return to 3.3V and allow normal boot.

Your module may not have all of these pins in which case the missing pins will (should) already have the appropriate resistors connected and you will just need to add the ones for the pins that are exposed on your module. Some modules (e.g. NodeMCU) have all the required resistors already.

You need to ensure there is no connected components that will force these GPIOs to different values at start-up. It is essential that hardware connected to GPIO0, 2 & 15 do not force their values at boot (other than the resistors described above) otherwise you will experience issues during startup.

[kwis2]

@anakod after programing by pulled low while reset modules I tested normally start to work and after soft reset it looks like module ignore GPIO0 state.
@riban-bw there is information about pin state with boot mode (X,y) where bits of X mean GPIO15, GPIO0, GPIO2. what mean boot mode (1, y) mean GPIO0 low, GPIO2 high nad boot mode (3, y) mean GPIO0 high, GPIO2 high.
With above log I got boot mode (1,7) while I measured high state on GPIO0 what is in conflict. The only explanation could be that module remember state of GPIO0 from power on state. And question is how could I ask module to "forget" about this state without physical reset.

[riban-bw]

@kwis2 are you saying that, with GPIO0 pulled high during run-time, when you perform a software reset, the device does not restart? That is not my experience. With a resistor pulling GPIO0 to 3.3V, calling reboot() will correctly restart the application.

[kwis2]

@riban-bw I have 100k pull up resistor connected to GPIO0 and everytime I have boot mode (1,x) with System.restart() after programming, and boot mode (3,x) after any other reset

[riban-bw]

100k is probably too high a value which will allow noise or capacitance to affect the pin value. Try with 10k which is the maximum recommend value. Also tell us whether you have anything else connected to GPIO0.

[kwis2]

I soldered 1k pull up resistor to GPIO0. Result exactly the same

[riban-bw]

Your report says you get the message: rst cause:2, boot mode:(1,6) which means the device was reset with GPIO2 high, GPIO0 low and GPIO15 low and the module is trying to boot from serial at low speed (or high speed for 1,7) so it does look like the module has GPIO0 low during reboot.
What is connected to your module?

[kwis2]

I have absolutelly nothing connected, except pull up resistor connected to module. Testing circuit this is only ESP8266-01 or ESP8266-01S module connected with the simples circuit possible to USB/RS converter. The whole circuit it is GND, VCC, TX, RX connected by jumper wire to converter, CH_PD solder to VCC, and RST and GPIO0 by jumper wire connected by button to gnd. I have tested different USB/RS converters and programmers. The same resuts I got with simple WeMOS module.
Now I am waiting for NodeMCU module to test if there is the same problem.
The only common part with all my trials it is computer with windows 7 configured by choco and netbeans environment. If nobody except me has problem it could mean that it is problem with my compiler....
I am wondering if could you @riban-bw send me bins compiled with your environment to test?

[riban-bw]

I will try to dig out my ESP-01 and compile a basic Sming firmware for you. You should have 4 resistors (all about 4k7 but anywhere between 1k & 10k should do). These should all be connected to 3.3V with other ends connected to: GPIO0, GPIO2, RESET & CH_PD. (Can probably get away with tying CH_PD directly to 3.3V.)