Datasheet

'E','X' void _flash_exit_xip(void)
First set up the SSI for serial-mode operations, then issue the fixed XIP exit sequence described in
Section 2.8.1.2. Note that the bootrom code uses the IO forcing logic to drive the CS pin, which must be
cleared before returning the SSI to XIP mode (e.g. by a call to _flash_flush_cache). This function
configures the SSI with a fixed SCK clock divisor of /6.
'R','E' void _flash_range_erase(uint32_t addr, size_t count, uint32_t block_size, uint8_t block_cmd)
Erase a count bytes, starting at addr (offset from start of flash). Optionally, pass a block erase command
e.g. D8h block erase, and the size of the block erased by this command — this function will use the larger
block erase where possible, for much higher erase speed. addr must be aligned to a 4096-byte sector, and
count must be a multiple of 4096 bytes.
'R','P' void flash_range_program(uint32_t addr, const uint8_t *data, size_t count)
Program data to a range of flash addresses starting at addr (offset from the start of flash) and count bytes
in size. addr must be aligned to a 256-byte boundary, and count must be a multiple of 256.
'F','C' void _flash_flush_cache(void)
Flush and enable the XIP cache. Also clears the IO forcing on QSPI CSn, so that the SSI can drive the
flash chip select as normal.
'C','X' void _flash_enter_cmd_xip(void)
Configure the SSI to generate a standard 03h serial read command, with 24 address bits, upon each XIP
access. This is a very slow XIP configuration, but is very widely supported. The debugger calls this
function after performing a flash erase/programming operation, so that the freshly-programmed code
and data is visible to the debug host, without having to know exactly what kind of flash device is
connected.
A typical call sequence for erasing a flash sector from user code would be:
•
_connect_internal_flash
•
_flash_exit_xip
•
_flash_range_erase(addr, 1 << 12, 1 << 16, 0xd8)
•
_flash_flush_cache
•
Either a call to _flash_enter_cmd_xip or call into a flash second stage that was previously copied out into SRAM
Note that, in between the first and last calls in this sequence, the SSI is not in a state where it can handle XIP accesses,
so the code that calls the intervening functions must be located in SRAM. The SDK hardware_flash library hides these
details.
2.8.2.1.4. Debugging Support Functions
These two methods simplify the task of calling code on the device and then returning control to the debugger.
Table 178. Debugging
Support Functions
CODE Description
'D','T' _debug_trampoline
Simple debugger trampoline for break-on-return.
This methods helps the debugger call ROM routines without setting hardware breakpoints. The function
address is passed in r7 and args are passed through r0 … r3 as per ABI.
This method does not return but executes a BKPT #0 at the end.
RP2040 Datasheet
2.8. Bootrom 162