breakpoint in backup registers

[jpeacock2399]

Posted on June 03, 2013 at 18:56

While tracking down a pointer problem I tried to use GDB to break on any access to the first location in the STM32F407 backup register area (0x40002850), using the ''rwatch 0x40002850'' command to GDB.  Bteween two other breakpoints I see the location change, but no data breakpoint occurs.

Is this a security feature in the STM32, no data breakpoints for backup registers?  Read protection is set to level 0, no protection.   Jack Peacock #backup-registers #data-breakpoint-bitband

[jpeacock2399]

Posted on June 03, 2013 at 20:30

The explanation turns out to be interesting.  It's not a protection issue, the GDB data breakpoint did work.  The catch is all in how the memory address is referenced.  It appears that the data breakpoints in the M3/M4 core do not look at bitband aliasing for the breakpoint location.

My bug was a backup SRAM bitband variable mapped to the wrong address region in the linker, so it aliased the backup register area.  It appears the data breakpoint traps a word access to the direct address, but not a bitband alias reference to single bits.   Jack Peacock

[waclawek.jan]

Posted on June 04, 2013 at 11:40

Thanks for sharing your finding.

> It appears the data breakpoint traps a word access to the direct address, but not a bitband alias reference to single bits. It does not sound unreasonable given the debug unit (DWT) sits in the core, rather than on the bus (i.e. behind the core/bus interface which actually performs the bit-banding); however, I did not find any definitive definitive indication of this in the publicly available ARM documentation. JW