Closed fsch2 closed 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" 😉.
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
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.
So the NodeMcu boards are of different vintage?
Does it help anything if you force the flash mode to dio
?
@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?
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?
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
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
Actual behavior
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!