-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Add workaround for a bug in SPIEraseArea #33
Comments
This was referenced Apr 30, 2015
That is very informative. I've been having trouble with this since version 1.0 of the SDK and reversing the flashing order sorts it - but it would be nice if it worked properly... unfortunately the code above... I have no idea where that goes, using Windows Eclipse and Makefile. Any idea? |
kanflo
added a commit
to kanflo/esp-open-rtos
that referenced
this issue
Jul 23, 2015
Workaround for a ESP8266 ROM bug that cuases SPI flash erase to sometimes erase an extra sector. See espressif/esptool#33
kanflo
added a commit
to kanflo/esp-open-rtos
that referenced
this issue
Jul 23, 2015
Workaround for a ESP8266 ROM bug that cuases SPI flash erase to sometimes erase an extra sector. See espressif/esptool#33
Closed
espressif-bot
pushed a commit
to espressif/esp-serial-flasher
that referenced
this issue
May 29, 2023
Due to a bug in the ESP8266 ROM discussed here: espressif/esptool#33 (comment), more sectors get deleted than necessary, potentially erasing other images. This commit fixes the issue according to the description of the bug. Additionally, we now pass `image_size` to other chips instead of the rounded number. Closes #61
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
SPIEraseArea
function in the esp8266 ROM has a bug which causes extra area to be erased.If the address range to be erased crosses the block boundary (block is 16 sectors), then extra
head_sector_count
sectors are erased.If the address range doesn't cross the block boundary, then extra
total_sector_count
sectors are erased.Where
head_sector_count
is the number of sectors from the start of erased area to the block boundary, andtotal_sector_count
is the total number of sectors to be erased.Espressif added the workaround to their version of flash tools. The trick is to modify the erased size:
Perhaps after some cleanup this fix should be applied here as well.
This issue causes the first 0x1000 to be erased in some cases when writing near the end of flash. In turn, this leads to a corrupted flash image when writing two binaries (0x00000 and 0x40000) separately.
The text was updated successfully, but these errors were encountered: