Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SOLVED]ESP8266 crashes after firmware upgrade (Arduino, nodemcu) #3753

Closed
dilthings opened this issue Oct 24, 2017 · 14 comments
Closed

[SOLVED]ESP8266 crashes after firmware upgrade (Arduino, nodemcu) #3753

dilthings opened this issue Oct 24, 2017 · 14 comments

Comments

@dilthings
Copy link

@dilthings dilthings commented Oct 24, 2017

Hi All,

This is the first time I am posting although I have been a regular reader of this forum. I have developping for ESP8266 for sometime now with Arduino and nodemcu. Recently I ran into the following issue. First of all this is somewhat similar to issue #2414 documented here. But difference is given below.

First a bit of what I did. I got my hands on Sonoff basic and Sonoff TH10/16 both having the ESP8266 and managed to reprogram them with arduino to do a lot of work. My sonoffs ran without any problems. Last week I got down a few units directly from ITEAD and used the same program to flash these as well. After flashing the devices refused to boot. The console displayed the following (AND) similar output with minor differences.

ets Jan 8 2013,rst cause:1, boot mode:(3,0)

load 0x40100000, len 27144, 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

In one instance it was bootmode(3,5).

Finally I went to the most basic blink program, and still the same. The I wanted to see if I could flash nodemcu onto this. I first used nodemcu_flash_master with the stock nodemcu firmware that came with it (which I have done many times). The I used FLASH_DOWNLOAD_TOOLS_3.4.4 and used nodemcu to flash. Ironically when I boot the same console message. The serial speed is automatically set to the esp default 74880. After the above output nothing. BTW I checked the original sonoff unit before flashing and it works fine. The output of FLASH_DOWNLOAD_TOOLS_3.4.4 is given below as it shows some details of the chip and the environment. (appologies if its too long, didnt want to drop anything at this point)

Thanks

Dil

\PATH\FLASH DOWNLOAD TOOLS V3.4.4\ESPFlashDownloadTool v3.4.4.exe:109: wxPyDeprecationWarning: Using deprecated class PySimpleApp.
test
load config ...
EFUSE MODE: 1
EFUSE ERR HALT: 1
test in load path conf

ESP8266 MultiDownload LOCK SETTINGS:0

get val: False
release settings
load config ...
test label: Download Panel 1
self.num: 1
init finished

COM: 6
ESP ROM BAUD : 115200
EFUSE MODE: 1
SELF.CHIP: ESP8266

LOAD PATH CONF:
MultiDownload 1

test com val: COM7

set string selection: COM7

230400
test baudrate: 230400
test baudrate selection: 1
test label: Download Panel 2
self.num: 2
init finished

COM: 6
ESP ROM BAUD : 115200
EFUSE MODE: 1
SELF.CHIP: ESP8266

LOAD PATH CONF:
MultiDownload 2

test com val: COM7

set string selection: COM7

230400
test baudrate: 230400
test baudrate selection: 1
test label: Download Panel 3
self.num: 3
init finished

COM: 6
ESP ROM BAUD : 115200
EFUSE MODE: 1
SELF.CHIP: ESP8266

LOAD PATH CONF:
MultiDownload 3

test com val: COM7

set string selection: COM7

230400
test baudrate: 230400
test baudrate selection: 1
test label: Download Panel 4
self.num: 4
init finished

COM: 6
ESP ROM BAUD : 115200
EFUSE MODE: 1
SELF.CHIP: ESP8266

LOAD PATH CONF:
MultiDownload 4

test com val: COM7

set string selection: COM7

230400
test baudrate: 230400
test baudrate selection: 1
test label: Download Panel 5
self.num: 5
init finished

COM: 6
ESP ROM BAUD : 115200
EFUSE MODE: 1
SELF.CHIP: ESP8266

LOAD PATH CONF:
MultiDownload 5

test com val: COM7

set string selection: COM7

230400
test baudrate: 230400
test baudrate selection: 1
test label: Download Panel 6
self.num: 6
init finished

COM: 6
ESP ROM BAUD : 115200
EFUSE MODE: 1
SELF.CHIP: ESP8266

LOAD PATH CONF:
MultiDownload 6

test com val: COM7

set string selection: COM7

230400
test baudrate: 230400
test baudrate selection: 1
test label: Download Panel 7
self.num: 7
init finished

COM: 6
ESP ROM BAUD : 115200
EFUSE MODE: 1
SELF.CHIP: ESP8266

LOAD PATH CONF:
MultiDownload 7

test com val: COM7

set string selection: COM7

230400
test baudrate: 230400
test baudrate selection: 1
test label: Download Panel 8
self.num: 8
init finished

COM: 6
ESP ROM BAUD : 115200
EFUSE MODE: 1
SELF.CHIP: ESP8266

LOAD PATH CONF:
MultiDownload 8

test com val: COM7

set string selection: COM7

230400
test baudrate: 230400
test baudrate selection: 1
load config ...
EFUSE MODE: 1
EFUSE ERR HALT: 1
test in load path conf

ESP8266 SPIDownload LOCK SETTINGS:0

get val: False
release settings
load config ...
test label: Download Panel 1
self.num: 1
init finished

COM: 6
ESP ROM BAUD : 115200
EFUSE MODE: 1
SELF.CHIP: ESP8266

LOAD PATH CONF:
SPIDownload 1

test com val: COM6

set string selection: COM6

921600
test baudrate: 921600
test baudrate selection: 3
test flag
print current path: \PATH\Downloads\FLASH DOWNLOAD TOOLS V3.4.4
RF option applied...
load config ...
EFUSE MODE: 1
EFUSE ERR HALT: 1
test in load path conf

ESP8266 HSPIDownloads LOCK SETTINGS:0

get val: False
release settings
load config ...
test label: Download Panel 1
self.num: 1
init finished

COM: 6
ESP ROM BAUD : 115200
EFUSE MODE: 1
SELF.CHIP: ESP8266

LOAD PATH CONF:
HSPIDownloads 1

test com val: COM7

set string selection: COM7

230400
test baudrate: 230400
test baudrate selection: 1
get selection: 0
notebook select 0
on combo box down
Current platform: Windows
com list: [('COM8', 'USB Serial Port (COM8)', 'FTDIBUS\VID 0403+PID 6001+A9W7FT55A\0000')]
test cp intop : 1
string sel: COM8
value: COM8
close combo box
test cp intop : 1
string sel: COM8
value: COM8
test offset : 0 0x0
case ok
test offset : 65536 0x10000
case ok


check res: (True, [[u'\PATH\firmware\0x00000.bin', 0], [u'\PATH\firmware\0x10000.bin', 65536]])
is running : False


set STOP FLG: True


pic path: ./RESOURCE/IDLE S.bmp


rep path : \PATH\Downloads\FLASH DOWNLOAD TOOLS V3.4.4\bin tmp\downloadPanel1
offset: 0
filename: \PATH\firmware\0x00000.bin
self.cp.disable change bin: 0

size speed : f
mode: 0
flash size: 0
flash speed: 3
test fpath: \PATH\firmware\ temp by dltool/downloadPanel1
test fname: \PATH\firmware\ temp by dltool/downloadPanel1\0x00000.bin rep
mode : speed:
write bin : \PATH\firmware\ temp by dltool/downloadPanel1\0x00000.bin rep
offset: 65536
filename: \PATH\firmware\0x10000.bin
self.cp.disable change bin: 0

TEST!!!!
SELF.COMSTR: COM8
test running : False
BAUD 0 : 921600
test COM: COM8 <type 'unicode'>
test self. COM: COM8
test baud: 921600

CONNECT BAUD: 115200

com open
com port closed
test type : <type 'unicode'>
COM type: string
is open: False
serial port opened

baud: 115200
root baud: 115200

BAUD : 115200

Connecting...


pic path: ./RESOURCE/SYNC S.bmp


chip sync ok!
0x3ff00050: 75720000
0x3ff00054: 0200581d
0x3ff00058: 6400b000
0x3ff0005c: 005ccf7f
EFUSE MODE : 1
reg0:75720000
reg1:0200581d
reg2:6400b000
reg3:005ccf7f
check err 0: 0b
check err 1: 00
check err 2: 00
check err 3: 02
check err 4: 0b

EFUSE NORMAL MODE

CRC IN MODE 1:
crc calc res: 100
target crc val: 100

CRC IN MODE 1:
crc calc res: 114
target crc val: 114

EFUSE LOG:

EFUSE LOG:

REG0:75720000
REG1:0200581D
REG2:6400b000
REG3:005CCF7F

EFUSE NORMAL MODE

EFUSE CHECK PASS...
48bit mac
debug:

5c cf 7f 58 1d 75
CUSTOM ID: 06 40 00 00 00 07 20 00
CUSTOM ID: 0640000000072000

crc efuse 4bit: 0
crc calc 4bit: 0
48bit mac
MAC AP : 5E-CF-7F-58-1D-75
MAC STA: 5C-CF-7F-58-1D-75
get mac res: True
('tttest uuuuuuuuuuart : uart reg: ', 458)
(' baudrate: ', 115200)
get crystal: 26380800
get flash id : 0x1f14405e
manufacturer id: 0x5e

device id: 0x4014

vendor: 94
mode: 64
size: 20
DEBUG!!!!
SET FLASH PARAMS
filename: \PATH\FLASH DOWNLOAD TOOLS V3.4.4\bin tmp\downloadPanel1\0x00000.bin rep
offset : 0
filename: \PATH\FLASH DOWNLOAD TOOLS V3.4.4\bin tmp\downloadPanel1\0x10000.bin
offset : 65536
Erasing flash in old style...


pic path: ./RESOURCE/DOWNLOAD S.bmp


Traceback (most recent call last):
File "download panel info.pyo", line 539, in update pic
AttributeError: ESPDOWNLOAD instance has no attribute 'ESP MAC BT'
Took 0.58s to erase flash block
Erasing flash in old style...
Took 3.22s to erase flash block
TEST !!!!
FAST BAUD: 921600
fACTORY REBOOT MODE: False
Running Cesanta flasher (speed 921600)...
params:
MEMORY START
ELSE.... 26
P: OHAI
Writing 32768 @ 0x0... 0 (0 %)
1024 (3 %)
2048 (6 %)
3072 (9 %)
4096 (12 %)
.
.
31744 (96 %)
32768 (100 %)

Wrote 32768 bytes at 0x00000000 in 0.7 seconds (400.2 kbit/s)...
Writing 581632 @ 0x10000... 0 (0 %)
1024 (0 %)
.
.
581632 (100 %)

Wrote 581632 bytes at 0x00010000 in 8.6 seconds (542.5 kbit/s)...
Leaving...
com closed

pic path: ./RESOURCE/FINISH S.bmp

@dilthings

This comment has been minimized.

Copy link
Author

@dilthings dilthings commented Oct 24, 2017

One more thing I wanted to highlight, when I checked the esp chip it was a bit different from the rest I have seen. It said

ESP8266EX
272017
TURBOPFKP43

i have not seen this "TURBO" thing before. Does it have any bearing on this issue?

Dil

@devyte

This comment has been minimized.

Copy link
Collaborator

@devyte devyte commented Oct 24, 2017

@dilthings please edit your post with markup to fix the appearance. While editing, there's a preview tab above your text to check appearance.
Are the new boards identical to the old?
Did you erase the entire flash before flashing a sketch?
Did you flash the blink from Arduino IDE or with flashtool?

@dilthings

This comment has been minimized.

Copy link
Author

@dilthings dilthings commented Oct 24, 2017

@devyte Thanks for the prompt reply. As you asked I reformatted the text. Had to remove some orginal formatting in order to keep the text sane.

To answer your questions,

  • The boards at the face of it looks the same as the old ones. However, I still did not try to trace the paths to see if anything at the circuit level is different.

  • I did not erase the flash just used the different tools (arduino ide, nodemcu_flash_master and FLASH_DOWNLOAD_TOOL. Just after posting I flashed another sonoff unit that came with the same batch and it worked. The only difference I could see was the markings on the chip. This one was from 2016 and did not have the TURBO... on the markings as mentioned above in the original post. COuld this be a newer version of the chip???

  • I flashed blink from arduino IDE.

One more thing I did not mention earlier is the apparent power consumption of these "new" ones. With the earlier models I was just able to use the power from the FTDI module to power them up. However even with the stock sonoff firmware the units did not power up properly from the FTDI. I had to use an external phone charger to get these console outputs. When only powered with the FTDI even the console output did not appear. But when powered with the external supply OR the mains supply as intended by sonoff the console outputs were visible at the time of powering up. Then nothing.

Dil

@devyte

This comment has been minimized.

Copy link
Collaborator

@devyte devyte commented Oct 24, 2017

Google doesn't show any results for the turbo marking that you mentioned.
The error on boot that you show says checksum is bad, meaning that the flash data is corrupted. Did you try flashing while connected to mains power? Flashing requires extra.
Also, I'm a bit confused. The above messages are from the flashtool. Did you try the esptool, or from within the Arduino IDE?
And erase the flash first with the esptool before flashing a new sketch, you should do this anyways.

@dilthings

This comment has been minimized.

Copy link
Author

@dilthings dilthings commented Oct 24, 2017

@devyte in my haste to get this thing working I have added an 'R' to the marking. It says TUBOxxxx. I have uploaded a closeup view if it has any bearing to this issue.
esp8266-tubo-markings.

To answer your questions, I tried what you have mentioned.

  • I used esptool.py --port /dev/ttyUSB0 erase_flash to erase flash. It was done in 2.9 seconds. Is this typical?
  • On the power I am currently powering through a mobile USB charger and using an FTDI connector to connect to the serial port. I have bypassed the 3.3v line from FTDI and directly connected the power from USB charger. Grounds of the power supply and the FTDI are made common with the sonoff board.
  • I also tried this with sonoff being powered directly from the mains.
  • After erasing, reflashed a simple sketch from the Arduino IDE --> Same results.
  • Erased the flash again and booted --> only the following appears now on the arduino serial console without the crc, checksum lines seen above:

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

ets_main.c

  • To clarify your question above, yes the first set of (long) messages are from the FLASH_DOWNLOAD_TOOLS V3.4.4, when I flashed a nodmcu firmware.

  • In addition I raised a ticket with ITEAD.cc about this. Their response was that they dont support custom firmware. Then I asked them if they have done something to stop custom firmware from being installed and run on these since recently (as my earlier batches worked fine). Waiting for a reply from them. Will update the thread if / when I get an answer.

@devyte

This comment has been minimized.

Copy link
Collaborator

@devyte devyte commented Oct 24, 2017

They don't have to support a custom firmware, but they should support flashing their own .bin over serial. See of you can engineer some help from them just for flashing their own firmware over serial.

TUBOPFKP also doesn't show up anything in google. Please post a pic of the entire board.
I'm not sure how much further I can help with this, I've been pursuing with the view of some compatibility or configuration issue in the tools, but so far I haven't seen anything concrete that points to an issue in the core, and I'm running out of ideas.
If I were you, I'd return the boards, but that's just me.

@dilthings

This comment has been minimized.

Copy link
Author

@dilthings dilthings commented Oct 24, 2017

Thanks @devyte for the time and effort you put in to try and solve this 🥇.

As a last resort I will try what you mentioned with them - install their firmware over serial. Also I will wait for their response on my last question on whether they have blocked other firmware from being installed somehow (may be burning fuses - btw I am completely ignorant about these possibilities at the moment). Returning the devices is currently not an option to me. I was actually planning on using them (probably 1000+) in a much larger project due to their cost effectiveness :(

@lrmoreno007

This comment has been minimized.

Copy link
Contributor

@lrmoreno007 lrmoreno007 commented Oct 24, 2017

Hi!

ESP8266EX
272017
TUBOPFKP43

The second line is the manufacturing week and the year in this format: WWYYYY (Week 27 of year 2017).
And I think the third line is a serial number or lot-trace code.

Therefore TUBO is not relevant at all.

Regards

@lrmoreno007

This comment has been minimized.

Copy link
Contributor

@lrmoreno007 lrmoreno007 commented Oct 24, 2017

I found this:
captura

@dilthings

This comment has been minimized.

Copy link
Author

@dilthings dilthings commented Oct 25, 2017

@lrmoreno007 Thanks, for the marking convention diagram.

Now its working - details below

When I asked Itead if they have done anything to stop repurposing the devices their response was "You can refer to one customer method:https://github.com/arendst/Sonoff-Tasmota".

The link given provided useful information as below:

ATTENTION All versions

Only Flash Mode DOUT is supported. Do not use Flash Mode DIO / QIO / QOUT as it might seem to brick your device.

All this time I was using DIO/QIO as flash mode. As soon as I changed to DOUT, it all started WORKING :). Earlier I used the other flash modes on the previous versions of Sonoff and they worked fine.

Anyways simple wifi sketches DO work now. However the sketch I have developed to communicate with Azure IoTHub (which is working very stable on a older sonoff TH16) is crashing halfway with a lot of system related errors.... :(. I have opened another issue for that #3755. But for the time being Thanks for all who tried to help 👍

@dilthings dilthings changed the title ESP8266 crashes after firmware upgrade (Arduino, nodemcu) [SOLVED]ESP8266 crashes after firmware upgrade (Arduino, nodemcu) Oct 25, 2017
@dilthings

This comment has been minimized.

Copy link
Author

@dilthings dilthings commented Oct 25, 2017

After the solving the issue, further research revealed a similar case answered here arendst/Tasmota#683.

@lrmoreno007

This comment has been minimized.

Copy link
Contributor

@lrmoreno007 lrmoreno007 commented Oct 25, 2017

That's more or less what I expected and was investigating, because your bootmode message was (3,5). Just to learn something: What message do you get from bootloader now? boot mode (x, y)

And close this, please.

Regards

@dilthings

This comment has been minimized.

Copy link
Author

@dilthings dilthings commented Oct 25, 2017

After solving the issue as described above, now I don't get the boot mode message. However, now the problem has changed to #3755

@devyte

This comment has been minimized.

Copy link
Collaborator

@devyte devyte commented Oct 25, 2017

Closing as resolved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.