Failure to get prompt after flashing firmware / Getting csum err

fsch2 commented 7 years ago

Hi there,

I have a couple of NodeMcu Boards. Some behave correctly and some don't. In any case I can flash the firmware using the esptool.py script. Verification is also successful.

However, with some boards, I cannot upload lua scripts using the nodemcu-uploader. I do not even get a prompt, when I connect to the USB interface using Minicom.

Expected behavior

% python ~/repos/nodemcu-uploader/nodemcu-uploader.py -b 115200 -p /dev/ttyUSB0 upload init.lua
opening port /dev/ttyUSB0 with 115200 baud
Preparing esp for transfer.
Transferring init.lua as init.lua
All done!

Actual behavior

% python ~/repos/esptool/esptool.py --port /dev/ttyUSB0 erase_flash
esptool.py v2.0-beta3
Connecting....
Detecting chip type... ESP8266
Uploading stub...
Running stub...
Stub running...
Erasing flash (this may take a while)...
Chip erase completed successfully in 0.7s
Hard resetting...

% python ~/repos/esptool/esptool.py --after hard_reset --port /dev/ttyUSB0  write_flash  0x00000 /opt/downloads/nodemcu-master-23-modules-2017-05-31-17-56-15-integer.bin
esptool.py v2.0-beta3
Connecting....
Detecting chip type... ESP8266
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 4MB
Flash params set to 0x0040
Compressed 422000 bytes to 272318...
Wrote 422000 bytes (272318 compressed) at 0x00000000 in 24.0 seconds (effective 140.4 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting...

% python ~/repos/esptool/esptool.py --after hard_reset --port /dev/ttyUSB0  verify_flash  0x00000 /opt/downloads/nodemcu-master-23-modules-2017-05-31-17-56-15-integer.bin
esptool.py v2.0-beta3
Connecting....
Detecting chip type... ESP8266
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 4MB
Flash params set to 0x0040
Verifying 0x67070 (422000) bytes @ 0x00000000 in flash against /opt/downloads/nodemcu-master-23-modules-2017-05-31-17-56-15-integer.bin...
-- verify OK (digest matched)
Hard resetting...

% python ~/repos/nodemcu-uploader/nodemcu-uploader.py -b 115200 -p /dev/ttyUSB0 upload init.lua                                                                           
opening port /dev/ttyUSB0 with 115200 baud
Traceback (most recent call last):
  File ".../repos/nodemcu-uploader/nodemcu-uploader.py", line 10, in <module>
    main.main_func()
  File ".../repos/nodemcu-uploader/nodemcu_uploader/main.py", line 250, in main_func
    uploader = Uploader(args.port, args.baud, start_baud=args.start_baud)
  File ".../repos/nodemcu-uploader/nodemcu_uploader/uploader.py", line 71, in __init__
    __sync()However, I canno
  File ".../repos/nodemcu-uploader/nodemcu_uploader/uploader.py", line 69, in __sync
    raise DeviceNotFoundException('Device not found or wrong port')
nodemcu_uploader.exceptions.DeviceNotFoundException: Device not found or wrong port

When I reset the board, I can see a weird and always changing character sequence appearing on the serial interface. Something like this or similar:

�� s'l�|�� {��o�b�gbx

This looks like a wrong baudrate to me, so I suspect that is the root of the problem I am experiencing. This also happens with new boards, that have never been used before. I am unsure whether this is a hardware or a firmware problem. I would appreciate any advice for further debugging.

Test code

see above

NodeMCU version

nodemcu-master-23-modules-2017-05-31-17-56-15-integer.bin built by online build service with just a couple of basic modules.

Hardware

LoLin "new NodeMcu V3"

Thanks in advance for any help!

marcelstoer commented 7 years ago

Some behave correctly and some don't.

Hhmm, would it be naive to assume that it must be hardware issue then? The steps you took are all correct. The default baud rate is 115200.

nodemcu-master-23-modules-2017-05-31-17-56-15-integer.bin built by online build service with just a couple of basic modules.

23 is definitely not what I'd call "a couple of basic modules" 😉.

fsch2 commented 7 years ago

I did some more research and opened the serial port with Python using the baudrate 74880. The bootloader output:

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

load 0x40100000, len 26280, room 16 
tail 8
chksum 0xef
load 0x00000000, len 0, room 0 
tail 0
chksum 0xef
load 0x00000000, len 0, room 8 
tail 0
chksum 0xef
csum 0xef
csum err
ets_main.c

The checksum is wrong, do I interpret this output correctly? Why could this be the case? Is the flash chip broken?

In contrast, a "good" NodeMcu yields the following bootloader output:

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

load 0x40100000, len 26280, room 16 
tail 8
chksum 0xbd
load 0x3ffe8000, len 2212, room 0 
tail 4
chksum 0x42
load 0x3ffe88a4, len 136, room 4 
tail 4
chksum 0xee
csum 0xee
rf cal sector: 1019
freq trace enable 0
rf[112] : 00
rf[113] : 00
rf[114] : 01

SDK ver: 2.1.0(116b762) compiled @ May  5 2017 16:08:55
phy ver: 1134_0, pp ver: 10.2

fsch2 commented 7 years ago

Hi there,

thanks for the reply!

Some behave correctly and some don't.

Hhmm, would it be naive to assume that it must be hardware issue then? The steps you took are all correct. The default baud rate is 115200.

I honestly do not know. Querying the flash ID of the two boards yields:

Manufacturer: c8
Device: 4016

for the "bad" NodeMcu and

Manufacturer: e0
Device: 4016

for the "good" NodeMcu. Since the two boards have different flash chips it could also be the case, that one chip is not well supported with the esptool? In that case, this does not necessarily qualify as a hardware issue.

devsaurus commented 7 years ago

So the NodeMcu boards are of different vintage? Does it help anything if you force the flash mode to dio?

fsch2 commented 7 years ago

@devsaurus: Yes, it does indeed. Thanks a lot. I got the "broken" NodeMcu running by forcing the flash mode to dio:

% python ~/repos/esptool/esptool.py --after hard_reset --port /dev/ttyUSB0  \
write_flash --flash_mode dio 0x00000 /path/to/firmware.bin

Still, I am a bit puzzled why I was able to verify the flashed firmware correctly! I mean, the whole point of doing a verify is to find out, whether something went wrong during the flashing process. If the firmware image or its checksum is bad (for whatever reason) the verify_flash command should definitely not be successful. Should I open a new issue for this problem?

devsaurus commented 7 years ago

Good point, but we can't do anything about this in the nodemcu firmware. That's functionality of esptool.py IMO. I suggest you raise this question in the upstream project. It's odd that the verify is obviously not performed with the "productive" flash interface configuration.

Takeaway for our build system: esptool.py defaults flash mode to the setting found inside the firmware image (wasn't aware of that, did they change default spec recently?). What do we actually enter in there?

marcelstoer commented 7 years ago

Just for the sake of completeness: https://github.com/espressif/esptool/blob/master/README.md#verifying-flash

(wasn't aware of that, did they change default spec recently?). What do we actually enter in there?

Yes, they use keep by default: https://github.com/espressif/esptool/blob/master/README.md#flash-mode---flash_mode--fm That was changed just right before the 2.0 release: espressif/esptool@ef70691b1faa65bb041bdb8f45626fd513517e18

nodemcu / nodemcu-firmware