.UF2 File Format – Flash image

Assembling the image

• Only blocks with correct magic numbers, without the not-main-flash flag and without the file-container flag are written to flash.
• The blocks are grouped by family ID (blocks without one are a group of their own), and each group is its own image.
• Each block’s payload goes to its target address. Blocks that touch make one segment; blocks with a hole between them make two. A hole is reported as a gap, and its size is the number of bytes of flash that the file does not write.
• Where two blocks write the same addresses, the one later in the file wins, as when a board writes them in arrival order. The explorer reports it as an overlap.
• A block written at a lower address than the block before it, in the same family, is counted as out of order. That is normal for some tools and is not a fault.
• When the file holds several families the one with the most data is shown; the choice Family to show picks another.

A real example is Pimoroni’s MicroPython for the Presto, presto-v1.0.0-micropython-with-filesystem.uf2: one family (RP2350_ARM_S), two segments (the firmware from 0x10000000 and a filesystem from 0x10200000) and a gap of 831,488 bytes between them. Another, flash_nuke.uf2, holds two families whose blocks go to the same RAM addresses, one for the RP2040 and one for the “absolute” download used by the RP2350.

Which processor

A UF2 file never says which processor runs its code; only the family ID hints at the chip. The explorer keeps a table of the processor core of each chip family it knows, which is its own table, made from the manufacturers’ chip names as we know them, not data from the file or from the UF2 repository (which lists the families only). It is used for the default of the Processor choice; the choice overrides it. A family that is not in the table is shown as bytes only until a processor is chosen.

The ARM cores map to architecture levels: Cortex-M0 and M0+ to ARMv6-M, M3 to ARMv7-M, M4 and M7 to ARMv7E-M, and the RP2350’s M33 to ARMv8-M Mainline with DSP. The Hazard3 cores of the RP2350 are read as RV32IMAC with the Zcb, Zcmp, Zcmt and Zb* extensions. Families not in the table have no default; the family of the RP2XXX absolute and data downloads (0xe48bff57, 0xe48bff58) hold no code of their own.

The Cortex-M vector table

A Cortex-M processor starts by reading two words from its vector table: the initial stack pointer, then the address of the reset handler. The words after them are the addresses of the other exception handlers; each has its low bit set, the Thumb bit, because a Cortex-M runs Thumb instructions only. After the 16 system words come one word per device interrupt.

The names are from the ARM architecture reference manuals as we know them; the viewer did not read the manuals. The table above is also how the viewer names the words; SecureFault is shown for ARMv8-M Mainline although a core without the Security Extension does not have it.

How many interrupts

The file does not say how many interrupts the chip has, so the explorer shows a number of words you choose: 48 by default (the 16 system words and 32 interrupts). The interrupt controller of a Cortex-M0 and M0+ has room for up to 32 interrupts, that of the larger cores for up to 240; a chip has fewer than its core allows. The words after the real table are code or data, so a larger number shows some of those as handlers. To keep code visible, the table is cut short where the first handler of the 16 system words lies at or after the 64th byte of the table: the words from there on are code, not table. A short table, with the reset handler right behind it, is therefore shown with only the words before the handler (at least 16).

Where the table is

The table is at the start of the image in most Cortex-M firmware. A flash image for the RP2040 is different: its boot ROM copies 256 bytes from the start of flash, checks them with a CRC-32 stored in the last four bytes, and runs them as a second-stage bootloader that sets up the flash for execution in place; the program, with its vector table, follows at 0x10000100. An image that is loaded into RAM, such as flash_nuke.uf2, may start with code instead.

The Vector table choice therefore offers: at the start, 256 bytes after the start, or none. Its default is the first of those two positions (the second first for an RP2040 image in flash) that holds a table the viewer accepts: a stack pointer that is a multiple of 4 between 0x10000000 and 0x3FFFFFFF, a reset handler with the Thumb bit set, and every other handler zero or with the Thumb bit set. If neither does, the default is none. That is a check of the words, not a way of telling code from data, and the choice overrides it. The disassembly then opens at the reset handler, or at the start address you give.

Register and memory names

The viewer names the addresses in the ARMv6-M system region and, for the RP2040, the memory regions and peripheral bases. The names are those of the Raspberry Pi Pico SDK headers (pico-sdk: hardware/regs/m0plus.h and addressmap.h), as read in November 2026. They label an address that a branch or a reference lands on exactly; the viewer does not resolve the addresses that a program builds in registers.

The RP2040 memory regions and peripheral bases are listed in the viewer: XIP_BASE 0x10000000, SRAM_BASE 0x20000000, CLOCKS_BASE 0x40008000, IO_BANK0_BASE 0x40014000, UART0_BASE 0x40034000, TIMER_BASE 0x40054000, SIO_BASE 0xD0000000, PPB_BASE 0xE0000000 and the others. The RP2350 and the other chips have no peripheral names here; only the system region is named for them.

Sources

• microsoft/uf2 – the format and the list of families
• pico-sdk – the register and address names of the RP2040
• SEGGER Knowledge Base: RP2040 – the 256-byte second stage and its CRC
• The RP2040 bootloader – the boot sequence and the vector table after the second stage