Issues programing nodemcuv2

I recently started working with a Node MCU v2 device. When I try to use the PIO environment in Visual Studio Code to program the example Blink program (RTOS, non-RTOS, nothing happens. When I try to program the Arduino Blink example, it programs but then PIO immediately compiles again and programs the device, ad infinitum. For the short time that the Arduino sketch is compiling the blink program does behave as expected before the programming process starts.

When I program the RTOS and non-RTOS versions, the LED on pin 16 does not blink every other second. It sinply stays off until I press the reset button. At that point it blinks much faster and the serial monitor prints garbage. There should be not serial output.

My platformio.ini file is:
platform = espressif8266
framework = esp8266-rtos-sdk
board = nodemcuv2

When I program the sketch using the Arduino program, the program is uploaded correctly and the program works as expected. This leads me to believe that the device is working as expected.

I’ve removed and reinstalled the espressif8266 platform a couple of times without any change in outcome.

What can I do to get the example working?


I can confirm that this is an issue. I’m using this module (ESP12-F, 4MB / 32 Mbit).

I’ve created a new project using pio init -b nodemcuv2 --ide=visualstudio, then added a main.cpp from here to the project and it compiles fine. Be careful though, when I added the main.cpp using the Visual Studio “Add Element” dialogue, it added a main.cpp in them main folder, not in the src folder, and thus PIO failed to compile it. If you move the file manually it works. It compiles only once when I do Build -> Build Solution, so I can’t reproduce that issue.

Also works with the esp8266-rtos-sdk framework and example code:

And with the esp8266-nonos-sdk:

When uploading the Arduino code, everything works fine.

After uploading the esp8266-nonos-sdk version and rebooting the ESP (esptool didn’t do that automatically this time?), the ESP8266’s onboard LED goes wild.

What happens is that the ESP is continously rebooting. The bootloader spews out these messages at approx. 79900 baud:

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

load 0x40100000, len 25408, room 16 
tail 0
chksum 0xbe
load 0x3ffe8000, len 892, room 8 
tail 4
chksum 0x32
load 0x3ffe8380, len 956, room 4 
tail 8
chksum 0x8e
csum 0x8e
rf_cal[0] !=0x05,is 0x00

I’ve actually answered a StackOverflow question about this a year ago here. Summarized, the firmware is trying to access radio calibiration data (rf_cal). It fails reading because it cannot find the first magic byte 0x05, it finds 0x00 instead.

Two causes:

  • esp_init_data_default.bin is flashed to wrong address for the module. The bootloader comes in different versions (each flash size a version) and each one expects this rf calibration data at a different address (as seen here).
  • the user_rf_cal_sector_set function in main.c computes the wrong sector address. Not very likely because I’ve seen this code elsewhere and all it does is calculate the normally expected sector depending on the flash size and configuration.

The used flash command is

esptool -vv -cd nodemcu -cb 115200 -cp "COM8" -ca 0x00000 -cf .pioenvs\nodemcuv2\eagle.flash.bin -ca 0x10000 -cf .pioenvs\nodemcuv2\eagle.irom0text.bin

I’ll investage whether it starts working when I start flashing esp_init_default.bin at the correct address, too.

I can confirm that this was indeed the problem.

I have manually flashed the device by using the extra parameters which are correct for my chip: -cr -bz 32M -bm dio (-cr: chip reset after flash; -bz Flash size, 32 MBit here; -bm Flash mode DIO, see esptool.exe -h for more options). I’m also using the esp_init_data_default_v08.bin from Espressifs Github repo.

New flash command (for my computer):

C:\Users\Maxi\.platformio\packages\tool-esptool\esptool.exe -vv -cd nodemcu -cb 115200 -cp "COM8" -ca 0x00000 -cf .pioenvs\nodemcuv2\eagle.flash.bin -ca 0x10000 -cf .pioenvs\nodemcuv2\eagle.irom0text.bin -ca 0x3fc000 -cf esp_init_data_default_v08.bin -cr -bz 32M -bm dio

Bootloader now says

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

load 0x40100000, len 25408, room 16 
tail 0
chksum 0xbe
load 0x3ffe8000, len 892, room 8 
tail 4
chksum 0x32
load 0x3ffe8380, len 956, room 4 
tail 8
chksum 0x8e
csum 0x8e
rf cal sector: 1019
freq trace enable 0
mode : null

After that the firmware toggles the internal LED on and off every 1 second at GPIO2, just as the firmware code says.

So, after manually specifying flash size and mode, and additionally flash the init data at the correct address for the 32 MBit bootloader, it works.

Does this manual solution solve your problem too ?

Thanks for your help. I was able to get the NONOS blinking example by writing to the correct addresses. I tried the RTOS version, but the boot sequence hangs after printing the correct checksum for the third section, right before “rf cal sector” would get printed.

I wrote a bat file that uploads all of the bins and used it for both just changing the blank and init bins to the ones for the given SDK. It results in a working chip with the NONOS code, but not with the unmodified RTOS code.

The command used to upload is

espTOOL.exe -v -cd nodemcu -cb 230400 -cp COM4 -ca 0x3fc000 -cf "C:\ESP8266\ESP8266_RTOS_SDK\bin\esp_init_data_default.bin" -ca 0x00000 -cf ".pioenvs\nodemcuv2\eagle.flash.bin" -ca 0x10000 -cf ".pioenvs\nodemcuv2\eagle.irom0text.bin" -cr -bz 4M -bm qio

If you have any other ideas I would appreciate it, but if not I at least can use the non-RTOS code. Thanks.

In your flash command you are using -bz 4M which means 4 MBit aka 0.5 Megabyte but write the init data to 0x3fc000 which is for the 32 MBit aka 4 Megabyte image. Since you have a NodeMCU that should be a 32MBit/4MByte module, so maybe it works when you just say -bz 32M? Also maybe try -bm dio instead of -b qio.

Otherwise I’ll test this later the day.

I’ve been using the most recent release of esptool-ck 0.4.13. When I try to use the argument -bz 32M, it throws an error, error: Invalid flash size value: 32M. So I went to the esptool-ck source code to see why. It turns out that 32M is not an option in the array that the flash size argument is compared against, even though the README says that it is.

I then tried using the pio version of esptool-ck (0.4.9). It takes 32M as an argument, but when I tried to program my board with the NONOS code that worked with -bz 4M it didn’t work.

Looking at the most recent commit of “esptool_binimage.c” it references adding support for 8MB and 16MB. So it appears that -bz is in bytes. Its also in this commit that 32M is removed as an option for that argument as well.

Changing -bm qio to -bm dio didn’t fix anything.

At this point I think I am done wasting my time (and yours) trying to get the RTOS SDK to start working and will just use the NONOS.

Thank you very much for your help. I appreciate it.