NodeMCU Amica code doesn't run after upload

[ghost]

With the previous stable code base I could upload code and it would automatically run. With the new stable release the code won't automatically run. The serial monitor shows the normal jibberish and that is it. However if I hit the reset button on the device the code run normally.

[asetyde]

My nodemcu amica go , please check if you clean properly from old realize .

Another thing can be wifi begin or eeprom begin that must do with a correct sequence in setup function

Sent from my iPhone

On 02 dic 2015, at 20:27, Craig Lindley notifications@github.com wrote:

With the previous stable code base I could upload code and it would automatically run. With the new stable release the code won't automatically run. The serial monitor shows the normal jibberish and that is it. However if I hit the reset button on the device the code run normally.

— Reply to this email directly or view it on GitHub.

[ghost]

I uninstalled ESP8266 support completely and then reinstalled v 2.0. I then quit the IDE and restarted it. I still see the same thing. Code uploads but doesn't start. Clicking the reset button on the NodeMCU Amica device (from electrodragon.com) causes the code to run successfully.

I should mention that I'm not doing anything with WiFi. I'm just writing code to run on the device.

On Wed, Dec 2, 2015 at 3:22 PM, Alexandro Todeschini < notifications@github.com> wrote:

My nodemcu amica go , please check if you clean properly from old realize .

Another thing can be wifi begin or eeprom begin that must do with a correct sequence in setup function

Sent from my iPhone

On 02 dic 2015, at 20:27, Craig Lindley notifications@github.com wrote:

With the previous stable code base I could upload code and it would automatically run. With the new stable release the code won't automatically run. The serial monitor shows the normal jibberish and that is it. However if I hit the reset button on the device the code run normally.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/esp8266/Arduino/issues/1130#issuecomment-161452728.

Craig Lindley / Heather Hubbard

New Recordings: craigandheather.net/cnmpage.html Latest CD: craigandheather.net/hellinahandbasket.html

Personal Website: craigandheather.net

Phone: (719) 495-1873 Cell: (719) 502-7925

If you’re one in a million, there are now seven thousand people exactly like you.

[me-no-dev]

funky... the sketch is started at the end of the upload and nothing there has changed recently. I also use NodeMCU board and have no such issues. We also know that after Serial upload, if something software resets the ESP, it will hang, so is there any chance something in your sketch is triggering software reset?

[ghost]

If my sketch were causing a software reset why would it run fine when I click the reset button on the NodeMCU device?

On Thu, Dec 3, 2015 at 4:18 AM, Me No Dev notifications@github.com wrote:

funky... the sketch is started at the end of the upload and nothing there has changed recently. I also use NodeMCU board and have no such issues. We also know that after Serial upload, if something software resets the ESP, it will hang, so is there any chance something in your sketch is triggering software reset?

— Reply to this email directly or view it on GitHub https://github.com/esp8266/Arduino/issues/1130#issuecomment-161602305.

Craig Lindley / Heather Hubbard

New Recordings: craigandheather.net/cnmpage.html Latest rock CD: craigandheather.net/hellinahandbasket.html Latest non-rock CD: craigandheather.net/craigdoesfingerstyle.html

Personal Website: craigandheather.net

Phone: (719) 495-1873 Cell: (719) 502-7925

If you’re one in a million, there are now seven thousand people exactly like you.

[ghost]

OK more info. My sketch is using Serial and I found that if I do setup as follows:

void setup() { delay(1000); Serial.begin(115200); delay(1000); Serial.println("\n\n");

everything is fine. So a 1 second delay before calling Serial.begin and an additional second afterwards makes the code run after an upload. I still think this is an issue because I didn't need to do this for the previous stable release.

[asetyde]

Please check with other Board

Sent from my iPhone

On 03 dic 2015, at 16:01, Craig Lindley notifications@github.com wrote:

OK more info. My sketch is using Serial and I found that if I do setup as follows:

void setup() { delay(1000); Serial.begin(115200); delay(1000); Serial.println("\n\n");

everything is fine. So a 1 second delay before calling Serial.begin and an additional second afterwards makes the code run after an upload. I still think this is an issue because I didn't need to do this for the previous stable release.

— Reply to this email directly or view it on GitHub.

[me-no-dev]

there must be something in your code that does that. on all my sketches I first start the Serial. What do you do right after it?

[ghost]

Here is an example that shows the problem:

#include <Arduino.h>

void setup() {
  // NOTE: with this delay commented out my NodeMCU Amica will
  // not start automatically after upload. However if I click
  // the reset button on the device, the code runs fine.

  // With the delay in it starts everytime after an upload.

  //  delay(1000);

  Serial.begin(115200);
  delay(1000);
  Serial.println();
  const char *testString = "99WORD";
  char *endPtr = NULL;

  long i = strtol(testString, &endPtr, 10);
  if (testString == endPtr) {
    Serial.println("Didn't convert");
  } else  {
    Serial.println(i);
  }
}

void loop() {
  delay(100);
}

[me-no-dev]

I had something similar happen to me a while back and it ended up being the WiFi. Because I was not using WiFi in my sketch but did not say that I want it off, it was starting in the background and the Serial interrupts were making it fail. Just as precaution, instead of that delay, could you please put:

WiFi.mode(WIFI_OFF);
WiFi.disconnect(true);

or init the WiFi normally before doing anything else. Besides that, I have nothing else as clue :(

[ghost]

That doesn't fix the problem; only adding the delay does.

[igrr]

I failed to reproduce the issue with my NodeMCU and the example posted. So the issue is likely within some other part of the environment. Could you please make a dump of the flash memory and upload is somewhere? You can do this using esptool.py as follows:

esptool.py -p /dev/your-serial-port read_flash 0 4194304 flash.bin

[ghost]

Ok I've captured the flash.bin file and it is available here:

http://craigandheather.net/misc2/flash.bin

[igrr]

I have flashed your binary to a NodeMCU board and it prints "99":

Edit: i was able to reproduce this issue after several attempts!

[igrr]

Just to clarify for others watching this issue: the sketch does start, but the initial serial output doesn't get printed. When you add some more print statements to the loop, these do result in visible output. So the issue is with HardwareSerial which doesn't behave properly immediately after the first start.

[me-no-dev]

what should I do exactly to reproduce this?

1. Upload using Serial the sketch above
2. Open Serial immediately after finishing flash I ask because of @igrr words: "immediately after the first start"

[igrr]

That's right, these are the steps. I'm using 1.6.6 which keeps Serial window open during flashing, so once the upload is done there should be some garbage visible in the terminal. When you add this delay(1000); before Serial.begin, you will see 99 printed after the garbage.

[me-no-dev]

ok after lots of pointless reading the of the core source I got to the "duh" idea to hook up another USB Serial to the nodemcu and look at the data coming out throughout the upload and at the moment of boot. What can I say... there is nothing wrong with the ESP or the HardwareSerial library. At the image attached you can see the IDE sketch code, the output of the IDE monitor and the output of the other USB-Serial.

[ghost]

Well something has changed because I am using the exact same NodeMCU unit and the same MacBook for code development. I didn't have this problem before. It only started with the 2.0 release.

[igrr]

Apparently this is an issue with Arduino Serial Monitor, it doesn't recover from UART "garbage" (i.e. framing errors due to different baud rate) quickly enough. The difference is that in the previous staging release there was more lines of output from bootloader, and this, I suppose, gave serial monitor some chance to recover.