Unknown esp32 ROM loader status error?

iklask
Posts: 4
Joined: Tue Jul 02, 2019 6:50 pm

Unknown esp32 ROM loader status error?

Postby iklask » Tue Jul 02, 2019 7:27 pm

So I'm currently working on a project to upload a precompiled binary for an esp32 from an embedded device. I've been following the wiki on the protocol, and I've been looking at the esptool.py to put together my own uploader.

Problem is, my uploader seems to work sometimes and fail other times. In the status byte of a response packet I get 0x0108: 0x01 to state that there's an error with an error code of 0x08. However that wiki only mentions 4 ROM Loader error status codes, and 0x08 isn't one of them. Is there any other documentation to help me with this error code?


More background on my issue:
The python esptool.py NEVER throws errors using the same binaries, boot loaders, and settings (no stub, no compress, same flash freq, etc). I can even see that the data packets being sent are exactly the same as when esptool.py uploads this... I'm at a loss for what I could be missing that'd throw this unknown error code.

When it does happen, it generally throws the error on the same address of my binary (0x00031000). Oddly enough, it throws it sometimes when I'm uploading the bootloader_dio_80m.bin which I grabbed from the Arduino board package... so its pre-compiled and known to work (will error at address 0x00003000 sometimes).

In case this helps at all, a summarized version of my upload process goes like this:
  • Sync packets for handshake
  • Read date reg to check esp32 vs esp8266 (I can do both and 8266 has been working fine with no errors)
  • Read registers for chip description, features, and mac address
  • Attach SPI flash command
  • Detect flash size from SPI
  • Set flash parameters
  • Then for each binary I upload:
    • update flash parameters for this image if its a bootloader (flash mode, size/freq)
    • flash begin command for total size of binary at specific address
    • use block number from flash begin to Flash Data each block (of around 1040 bytes in size)
    • finally send md5sum packet to check hash of uploaded bin

ESP_Angus
Posts: 2344
Joined: Sun May 08, 2016 4:11 am

Re: Unknown esp32 ROM loader status error?

Postby ESP_Angus » Wed Jul 03, 2019 12:19 am

Hi iklask,

Thanks for the detailed account of what you're doing.

I just added three more error codes to the wiki. I'm not sure why I didn't document these ones in the first place, sorry.

I believe you're getting error 0x08 after sending a block of flash data because the values read back from flash don't match. The ROM loader writes the block to flash, then immediately reads back the same data from flash and compares the 8-bit CRC to what was written. If they don't match, you get this error.

This could indicate a problem with the flash chip (ie the actual flash contents aren't matching due to signal integrity problems, or write protection, or the flash not being fully erased), or maybe an alignment issue (all lengths & offsets should be 4-byte aligned).

Reading back the flash contents manually may give you some clues.

iklask
Posts: 4
Joined: Tue Jul 02, 2019 6:50 pm

Re: Unknown esp32 ROM loader status error?

Postby iklask » Wed Jul 03, 2019 1:42 am

Thank you for the edit to the wiki :D ! I was thinking I must have had a bad esp or something.

So this caused me to look at my output again especially when it came to my flash_begin. I compared my data packets to the esptool.py output a second time and did find a few small differences.

Looks like I was accidentally using the esp8266 flash erase size "fix" for that ROM instead of just passing the normal erase size. I have since changed it and ran a couple tests and its working so far... but this issue seemed to randomly appear and disappear so I'll have to test more tomorrow to make sure that's the issue. But sounds like it could be the issue if the erase size was off.

ESP_Angus
Posts: 2344
Joined: Sun May 08, 2016 4:11 am

Re: Unknown esp32 ROM loader status error?

Postby ESP_Angus » Wed Jul 03, 2019 4:14 am

Incomplete erase sounds like it could be the reason. If you don't erase flash and then write 100% identical bytes to it, this will succeed as nothing is changed when it reads back. So this may explain why the same offset passed sometimes and failed other times.

Who is online

Users browsing this forum: lironghua and 59 guests