ESP8285 Can't self-flash

[cnlohr]

I don't really know what's going on here, but for some reason the ESP8285 passes the check for MD5 matches, the final copy-to-flash seems to work, too? But, once in place, the system won't boot at all.

Anyone have any idea why the ESP8285 won't self flash? (This applies to USB and WIFI flashing)

[cnlohr]

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

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

[leopck]

Hey, I don't have an esp8285, but I can help brainstorm with you. Based on the reset causes and the boot device, it seems to state that you're booting normally and you're booting from flash. You can check the document here (http://www.esp8266.com/viewtopic.php?p=2096#p2112) to learn more on the rst causes and boot device.

Also, if you google the last three errors, there's a few ppl that is also facing something similar but not the same situation.

csum 0xef
csum err
ets_main.c 

There's this thread that talks about this, and the error given looks about the same with some difference:

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

load 0x40100000  len 612  room 16 
tail 4
chksum 0xef
load 0x00000000  len 0  room 4 
tail 0
chksum 0xef
ho 12 tail 0 room 4
load 0x00000000  len 0  room 12 
tail 0
chksum 0xef
csum 0xef
csum err

And they said the fixed was here: http://bbs.espressif.com/viewtopic.php?f=7&t=25&p=70#p70 I'm not sure how these information might help you. Hopefully it finds it way to help you in your troubleshooting.

On top of that, this might not be relevant or I might be totally wrong here, but I thought it might be worth mentioning so that we can consider the possibility, in my previous post I mentioned that the SPI flash inside the ESP8285 is a DOUT mode flash. I am not sure how things works, but from what I understand what DOUT mode means doesn't it mean that it is only a read operation?

3.spi mode :
1)QIO ,for flash that support quad r/w operation(e.g. W25Q)
2)QOUT,for flash that support quad read operation(e.g. W25Q)
3)DIO,for flash that support dual r/w operation(e.g. W25Q &W25X)
4)DOUT, for flash that support dual read operation(e.g. W25Q &W25X)

Now the question I'm wondering, if it is truly a DOUT mode only, then how does the flashing process writes into the flash for programming? This is merely my speculation and I could be wrong, but I hope this helps.

[cnlohr]

They are definitely timeouts and by playing with a lot of aspects, I seem to be able to make the problem effect me to varying degrees. I cross-posted more status below.

Ok. This is getting weird.

If I try reading the data first into a buffer on the stack, i.e. spi_flash_write/SPIRead/ets_memcpy( buf, (uint8_t*)0x40200000 + from1, SRCSIZE ); -- then SPIErase/spi_erase_sector it, then it freezes on the erase.

Maybe there's some status I need to check? hmm.

This does not appear to be the case with '86's. - See more at: http://www.esp8266.com/viewtopic.php?f=13&t=11515&p=53948#p53948

I can definitely read and write to it, as I can "push" a webpage to it via USB.

But, when it comes to my code that lives in IRAM to overwrite the boot sector, etc... things start freezing an inopportune times. Your post about the timeout looks really interesting since I am definitely seeing a timeout.

P.S. https://github.com/esp8266/Arduino/issues/1844 suggests it may be just different cap configuration. Will try now.

[cnlohr]

Not caps. Added an extra .1er to no effect.

[cnlohr]

Ok - figured I should say now. Not everything's figured out, but most of the weirdness was due to my stack growing too large. Still not burning correctly, but at least it's not freezing and freaking out.

[leopck]

Hm that's interesting, I wonder why we can read and write thru DOUT when it is stated as dual read operation only. What happens if you were to change the esptool settings from dout to dio? Does it even flash? Sorry this question is more on my curiousity since I do not own a esp8285.

[cnlohr]

INTERESTING: If I switch it to dio from dout, our old friend appears.

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

load 0x40100000, len 30476, room 16 
tail 12
chksum 0xef
ho 0 tail 12 room 4
load 0x00000000, len 0, room 12 
tail 0
chksum 0xef
load 0x00000000, len 0, room 4 
tail 0
chksum 0xef
csum 0xef
csum err
ets_main.c 

Also, Oddly. If I read the contents back from the ESP, everything looks like its in perfect order. Every byte matches perfectly.

[leopck]

This error boot mode:(3,0) is showing up after you convert to dio and flash or does it show up in during the self-flash after your convert to dio in the esptool?

you're reading off the contents of the ESP in dio or in dout?

[cnlohr]

The exact same error comes up if I self-flash or if I dio flash (With esptool)

I don't believe you can choose. read_flash decides for you.

[leopck]

Is it safe for us to assume this: Since the error that is shown in dio flash and self-flash is the same, could it be that the method of self-flashing is seen as the same as DIO flashing? Hm, the strange thing is that the read_flash shows the same content...

[cnlohr]

I would not say it's safe to assume, though maybe possible? I would have expected espressif to make the flashing functions work correctly on all platforms. I will agree that it is quite odd. I wonder if there's some flags that get set or something like that.

[cnlohr]

Ok @leopck you were correct the whole time. I seriously tested it a few times, I don't know what I did differently today, but the difference lit up like a lightbulb. It worked immediately when I set the flash bits correctly in the elf2image command.

ifeq ($(CHIP), 8285)
$(FW_FILE1) $(FW_FILE2) : $(TARGET)
    PATH=$(PATH):$(FOLDERPREFIX) $(ESPTOOL_PY) elf2image $(TARGET) --flash_mode dout --flash_freq 80m --flash_size 8m
else
$(FW_FILE1) $(FW_FILE2) : $(TARGET)
    PATH=$(PATH):$(FOLDERPREFIX) $(ESPTOOL_PY) elf2image $(TARGET)
endif

BOOM! You were totally right.