The ATmega32U4 is the part most people have already touched without knowing it: it is the controller of the Arduino Leonardo and of countless consumer HID boards. Thirty-two kilobytes of ISP flash, 2.5 KB of SRAM and 1 KB of EEPROM give it room for a real protocol stack, which is exactly why recovering locked ATmega32U4 source code is a recurring engagement for us – the firmware inside is usually worth more than the chip by an order of magnitude.
The 4 KB That Changes Everything
Unlike most megaAVR parts, 32U4 units shipped with an external crystal are factory-preprogrammed with a USB bootloader, and on Leonardo-class designs that section occupies the top 4 KB of the array. The HWB pin, sampled during reset, decides whether the core leaves reset into the application or into that bootloader. This matters for recovery work because the bootloader is a second, independent execution context: it can read program memory through LPM regardless of some lock configurations that block the application from reaching boot regions, and it can hand out the application image over USB if the boot lock bits were left permissive. Many boards whose owners were told “the chip is locked, it is lost” are read out in twenty minutes through this path.
Two Independent Lock Gates
Protection on this die is a pair of gates, not one. The classic lock byte – modes 1 through 3, where mode 3 disables further programming and verification over both SPI and JTAG – covers the die as a whole. On top of that, the boot lock bits BLB0 and BLB1 control what the application may read or write in the boot section and what the bootloader may do to the application section. Vendor images frequently enable one gate and not the other, because the vendor needed the bootloader to accept field updates. Mapping the exact combination present on the client’s die is the analytical core of the job; the readout path follows from it.
What The Peripherals Say About The Image
A 32U4 application is rarely trivial. The 12-channel, 10-bit ADC with programmable-gain differential inputs, the high-speed Timer4 running from its own 64 MHz PLL, and the 832-byte USB endpoint RAM all demand careful start-up ordering. When we reconstruct a build environment for a client, the initialisation sequence recovered from the binary – PLL enable before USB attach, ADC reference settle before first conversion – doubles as evidence that the extracted image is complete rather than a partial readout. The 1 KB EEPROM, imaged separately, often holds the gain and offset tables those ADC channels consume at runtime.
Reading The Page Map
The flash array of the 32U4 is organised into pages, and the page map is part of what a recovery report should communicate, not just the byte stream. Read-while-write operation means a field-updated application was written page by page under the supervision of the bootloader, so the image we extract often shows the wear pattern of its own update history: erase counters, alignment gaps where a page was only partially used, and the occasional leftover of an older version in a region the new build never touched. None of that is noise. The alignment tells a rebuild team what the original linker script assumed, and stale fragments sometimes preserve constants or strings that were dropped in the latest revision – useful when a client needs to roll a feature back. We annotate the page map in the report so those decisions stay visible instead of being flattened by a naive binary dump.
The Readout Plan
Entry order is: USB bootloader first, because it is non-invasive and needs nothing but the existing socket; SPI ISP second; JTAG last, since on a 44-lead QFN it may require fine-pitch probe access. Voltage is kept inside the 2.7 to 5.5 V window the family specifies, and the die is never erased during any of these steps. Where the dual-lock configuration blocks every software path, we say so in the report instead of silently returning a blank.
Session And Deliverables
A typical session closes with the 32 KB flash image as Intel HEX, the 1 KB EEPROM file, the decoded fuse and lock table, and a statement of which entry path produced which region. Teams that need to compare against the smaller 44-pin sibling will find the 16 KB variant documented at extract encrypted ATmega16U4 firmware; the 32-pin bridge family counterpart is the ATmega32U2. Quotes are issued from the services desk or via the contact form.