flash_range_program will not work if flash is not erased

[MohamedGhardallou]

flash_range_erase must be called before calling flash_range_program. Otherwise flash_range_program will not work.

To test this behavior , just comment line 40 in flash_program example.

Could you please add a comment in the header file rp2_common/hardware_flash/include/hardware/flash.h to indicate this.

This is not obvious and it may save a lot of time to a lot of people.

Thanks

[dshadoff]

Are you commenting on the behaviour of flash memory itself ? Or is there some different behaviour / error code sent back by the SDK ?

For regular flash chips, the behaviour is:

• when erased, all bits are '1'
• when programmed, various bits are set to '0'
• reprogamming can not bring any '0' values back to '1', but may bring additional '1' bits down to a '0'.
• if the flash memory has an auto-verification method, it may error out before programming the full block (specific chip-defined behaviour).
• The only way to return a '0' value back to '1' is with erase (which is usually sector/block/chip in scope)

[MohamedGhardallou]

@dshadoff Thank you for your response. Yes i was asking about the behavior of flash memory itself. I was not aware of this behavior and when i discovered it , i thought we may add a comment to the header file to highlight this. But then this is not necessarily as we can also program the flash without erasing if that sector bits are already ones. So no need to change the header.

Thank you again.

[savejeff]

just stumbled over the same unexpected behavior. a hint in the header of fash.h would be nice for people not familiar with how flash cells work

[LucaOverflow]

Jup. Spent half a day because it's not documented. It would be very nice if it's not just a note in the header but contained in the online documentation.

[kilograham]

re-opened to add documentation to header

[jaguilar]

One option here would be to assert in debug mode like

for (int i = 0; i < write_size; ++i) {
  assert(!(writebuf[i] & ~existingbuf[i]));
}

for all bytes to be programmed. It could easily prevent accidental misuse and serve as a hint to users. I'm not sure how much the overhead y'all tolerate on debug-mode vs. release-mode builds.

[lurch]

Fixed by #1772