STM32H743: Two Banks, One Address, and a Bit That Swaps Them
May 31st, 2015 | 
Author: Two megabytes of flash sounds like a single larger array. On this part it is two banks of one megabyte each, sitting at consecutive addresses, and there is an option bit whose only job is to exchange which of them answers at the base address. That bit is the reason a dump can be internally consistent, correctly sized, and still mislabelled — and the reason two engineers can disagree about what is in a device while both are right.
The arrangement
The two banks are independent in the ways that matter: they can be erased separately, programmed separately, and read while the other is being written.
| property | bank 1 | bank 2 |
|---|---|---|
| base address, unswapped | the base of the flash region | one megabyte above the base |
| erase granularity | per sector within the bank | per sector within the bank |
| readable while the other is written | yes | yes |
| holds a vector table | if the application starts here | only if something is linked to start here |
The third row is the feature that exists for a reason. Reading one bank while writing the other is what makes a live firmware update safe: the running application executes from one bank while the new image is written into the other, and the switch happens at a reset rather than in the middle of an update.
What the swap bit does
The swap bit does not move data. It changes which bank responds at the base address, which is a different statement, and the difference is exactly where mistakes come from.
| swap bit state | what the CPU sees at the base address | what is physically there |
|---|---|---|
| unswapped | bank 1 | bank 1 |
| swapped | bank 2 | bank 2, at the address bank 1 usually occupies |
Nothing in either bank changes. The mapping changes. A reader who fetches through the CPU address space gets whichever bank the mapping points at, and a reader who addresses a specific bank through the flash controller gets the physical one. Those two reads can return different data from the same part at the same moment, and both are correct answers to different questions.
Three ways a dump goes wrong here
The failure modes are specific and each has a signature.
| what was done | what the image looks like | how to detect it |
|---|---|---|
| read through the CPU, recorded the base address as physical bank 1 | a valid image labelled with the wrong bank | the vector table’s contents match the bank the mapping points at, not the bank named |
| read both banks, ignored the swap bit | two images, either of which might be the running one | both contain plausible vector tables and both look complete |
| read one bank, assumed the other was empty | an image missing half the application | the missing bank is not erased, it holds data |
The second row is the common case on a device that has been through a field update. Both banks hold something, both are structurally valid, and the question is not “which is the firmware” but “which is running”. The swap bit answers that, and the option bytes are where it lives.
Finding the running image without the option bytes
Sometimes the option bytes are unreadable, or the device no longer boots and the mapping is a guess. There are indirect signals.
| signal | where to look | what it indicates |
|---|---|---|
| a reset vector that branches into the bank boundary | the first instructions | an application that knows it may be swapped |
| an update routine that programs the bank it is not executing from | the write path | an A/B design, which means both banks are meaningful |
| a copy of the vector table near the top of a bank | the end of either bank | a bootloader that relocates, common in this arrangement |
| erase counts implied by wear patterns | both banks | which bank has been written more often, usually the update target |
The second row is the strongest, because an A/B update design cannot work without knowing which bank is currently executing, and the code that determines that has to read the mapping. Finding it tells you the design, and the design tells you which bank the customer’s production line considers current.
Why the deliverable has to state the mapping
An image delivered without a statement of bank ownership is ambiguous in a way that only surfaces later. A customer who programs it into the base address may be writing it into the wrong physical bank — which works, until the next update, when the swap bit moves and the device appears to have lost its firmware.
The report should therefore state four things: the swap bit as read, which bank the running application occupies, whether the other bank holds anything, and what happens on the next update given that state.
| item | why it changes what the customer does |
|---|---|
| swap bit as read | decides which physical bank a restore has to target |
| which bank is running | decides which image is the deliverable |
| state of the other bank | decides whether an update will overwrite something wanted |
| next-update behaviour | decides whether the device can be updated in the field at all |
A related reading of the same generation, from the clock and voltage-mode angle, is at STM32H723 heximal extraction. The arrangement where the program is split between two cores rather than two banks is covered in STM32H745 code recovery, and the encrypted external memory case that can sit in front of either bank in STM32H725 heximal recovery. For a smaller member of the family where a single bank makes the same question simpler, STM32F303RE heximal copying covers it.
FAQ
Does the swap bit copy data between banks? No. It changes the address mapping only; both banks retain their contents.
Can both banks hold valid firmware at once? Yes, and on a device that has been updated in the field they usually do.
Which bank does a restore need to target? The physical bank that the mapping points at when the swap bit is in its delivered state, which is why the bit has to be read rather than assumed.
Conclusion
The two megabytes are two independent banks behind one address range, and a single option bit decides which one answers at the base. Reading the image is straightforward; stating which bank it came from, and what the other bank holds, is what turns a dump into something a customer can program without creating a device that loses its firmware at the next update.
Posted in Recover Chip