Try to look for repeating sectors before reverting to reading the
JEDEC ID of the flash chip. This way we don't interrupt the flash
execution if a valid program is running, but can detect the flash
size if the flash memory has been erased.
The command can be used either by specifying the length only, or
the start address and the length like so:
monitor erase_sector <length>
monitor erase_sector <start_addr> <length>
If no start address is specified, it will begin erasing from the
start of the flash sector.
There seems to be a bug in the bootrom for the rp2040 which means
that the chip erase command is not accepted. This is because the
CS pin must be released (set high) directly after sending the chip
erase command (0x60 or 0xC7) (see Winbond W25Q128JV datasheet for
details). Instead the bootrom sends the address after the command,
thus the SPI flash silently ignores the command. Instead, we must
erase each 64KB block one at a time, but thankfull the bootrom
handles this correctly for us.
There are some cases when the this old method for finding the flash
size will fail, such as if the flash chip has been erased with 0xFF
bytes (rather than blank 0x00 bytes). As this is unreliable,
setting the wrong flash size could cause problems when trying to
inspect memory regions which appear to be out of range.
If the RP2040 is using the ring oscilator (ROSC) rather than the crystal
oscilator (XOSC) then flashing program will take much longer. As the XOSC is not
enabled at boot we should not assume it will be enabled before the debugger is
connected (or indeed at all), thus should use the longer timeout during load
commands.
Increasing spinner timeout to 500 means `tc_printf` is not called during
the `_flash_range_erase`. This is important as `_flash_range_erase` is
used when loading. This fixes the issue:
https://github.com/blacksphere/blackmagic/issues/875
Also adding spinner timeout counter to reduce bus traffic.