AT32F405RCT7: Two USB PHYs And One 256K Array

The AT32F405RCT7 is the 64-pin, 256 KB member of Artery’s 216 MHz Cortex-M4F family, and it carries something most parts in this class do not: two USB controllers, each with an on-chip PHY. The high-speed block has 4 KB of dedicated buffer memory; the full-speed block is crystal-less in device mode. A design that uses both ends up with two independent data paths into the same 102 KB SRAM, and that arrangement is the first thing we map before touching the array.

Two Controllers, Two Buffer Pools

Neither USB buffer appears in a flash read. They sit peripheral-side, and their contents at the moment power drops are whatever the last transfer left behind. That matters when a customer asks whether the firmware is complete: a dump of the array gives code and constants, not runtime state, and on this part there are two separate places where runtime state lives.

The SRAM split is worth knowing too. The flash-based part carries 96 KB plus a 6 KB block, and the first 48 KB is parity-checked. Parity does not protect against a read attempt, but it does tell you when a marginal supply has corrupted a capture.

The Twenty Kilobyte Boot Block

Twenty kilobytes of boot memory ship as a bootloader. One configuration step converts that region into ordinary user program and data memory, giving 256 plus 20 KB of usable space. Two boards with the same marking can therefore hold different amounts of code, and a read that stops at 0x08040000 may be stopping one block early.

We ask for the memory map rather than assuming it. When the answer is unknown, the read runs to the top of the boot region and the last 20 KB is flagged as conditional in the report.

Where sLib Can Sit

sLib turns a password-protected range of the array into an execute-only library: instruction fetch works, data reads return 0xFF, and the range is set per sector. On this family it can be placed in main flash or in the boot block, but not in both at once, and it may not include the first sector because the vector table is read as data.

That last rule is the one that decides most jobs. Sector zero and the first four kilobytes stay legible no matter how the library is configured, so the reset vector, the initial stack pointer and the startup code are always available as a sanity anchor.

Sector Arithmetic At 256K

Artery’s rule for the whole AT32F4 line is simple: 256 KB and above uses 2 KB sectors, below that uses 1 KB. Here that means 128 sectors, and the erase/program protection bytes map across them one for one. Reading those bytes, the sLib range registers and the access protection byte tells us the shape of the protection before any content is examined.

Reading Order We Use

Access and erase protection bytes first, then the 96-bit unique ID, then the array in two passes with a comparison between them, then the boot block if it is configured as user memory. The unique ID is not decoration: on a BOM that mixes three AT32 variants, it is how we prove which die the image came from.

Where A Read Fails First

The failure that wastes the most time is a library region that reads as 0xFF. A blank check reports empty flash, the technician concludes the part was erased, and the job is written off. It was never empty; the bus was simply refusing to answer.

The second trap is the permanent one. The ICP tool offers an advanced access protection mode on this series that disables the debug interface and cannot be undone. Once that byte is set, no amount of tooling reopens the port, and the only remaining route is physical.

Delivery

The handover contains the raw binary with the original addresses, a repaired image where ECC or parity errors were corrected, a per-block confidence map, and a short note on which regions were protected and how that was resolved. If the boot block was configured as user memory, both the 256 KB image and the extended image are included so the linker script can be rebuilt either way.

Related reading: reading a protected AT32F405CCT7 covers the 48-pin version of the same die, how program memory differs across MCU families explains why flash behaves unlike OTP, and what bypassing protection actually involves sets out the layers in order. Our service scope lists what we accept.