gdb/target-memory.c:block_boundaries() figures out which flash blocks need to be erased for a particular range of addresses, based on the flash blocksize. However, it incorrectly rounds the absolute flash address, rather than the offset from the start of the flash region. For example, with OpenOCD HEAD and the nRF51 target, which defines a single-block region of size 0xfc [*]: (gdb) info mem Using memory regions provided by the target. Num Enb Low Addr High Addr Attrs 0 y 0x00000000 0x00040000 flash blocksize 0x400 nocache 1 y 0x00040000 0x10001000 rw nocache 2 y 0x10001000 0x100010fc flash blocksize 0xfc nocache 3 y 0x100010fc 0x100000000 rw nocache (gdb) load target state: halted target halted due to debug-request, current mode: Thread xPSR: 0xc1000000 pc: 0x000006d0 msp: 0x000007c0 target state: halted target halted due to debug-request, current mode: Thread xPSR: 0xc1000000 pc: 0x000006d0 msp: 0x000007c0 Error: No flash at address 0x10000fb0 Error: flash_erase returned -4 Error erasing flash with vFlashErase packet (gdb) GDB tries to erase the block from 0x10000fb0 even though the flash region starts at 0x10001000. It should erase the one and only block at 0x10001000 instead. [*] The size 0xfc is a bug in OpenOCD, but GDB is still doing the wrong thing here.
Created attachment 8142 [details] Fixes #17518, that happens when the start address of the mem region is not on the boundary of its blocksize I'm facing on the same kind of the bug, for some processor which have memory region whose start address is not on the boundary of its block size. For instance, MB9AF156NA MCU has SA3 whose block size is 48k and its start address is 16k, that is not on the boundary of 48k. (see http://www.spansion.com/downloads/MB9AB40N_MN706-00019-E.pdf) In this case, GDB issues vFrashErace packet with start = 0 and length = 48k. To correct this, address should be offset to its start address before rounding to block size, and restore original offset after that.