Have you looked at erratum E14 in the datasheet?
A RP2040 UF2 file consists of 256-byte pages of data, each marked to be written at a certain address by
the UF2 bootloader. A flash-binary UF2 is one of these for which every 256-byte page is marked to be
written at a 256-byte-aligned address in flash.
When writing flash, an entire 4kB flash sector must be erased at a time before any pages within that
sector can be (re-)written. The UF2 bootloader does not require the flash-binary UF2 to include data for all
pages within a sector. In that case the whole sector will first be erased, any present pages will be written,
and the rest of the 4kB sector will be left undefined.
This mechanism works as expected when the partially-filled sector is at the end of the binary, which is of
course commonplace, as a binary does not need to be a multiple of 4kB long.
If however, the partially-filled sector occurs at the start of the binary (i.e. the binary is not aligned on a 4kB
page) or if a partially-filled sector appears in the middle of the binary (i.e. the binary is sparse/noncontiguous), then the UF2 file may be written incorrectly.
Note that the vast majority of UF2s generated by the SDK are indeed aligned on a 4kB boundary and
contiguous, however it is possible for the SDK to produce a misaligned or non-contiguous binary by
modifying the linker scripts, or putting extreme alignment requirements on static data. It is also possible
that other languages or tools might produce binaries that are not 4kB-aligned or contiguous.
Statistics: Posted by arg001 — Tue Aug 06, 2024 6:36 pm
