Search code examples
embeddedatmelstudioatmel-uc3

Atmel Studio: How exacly do data breakpoints trigger?

OK folks. I set a Data Breakpoint in Atmel studio (With ICEmk2-JTag Debugger) and it won't get hit although the value at the address is changed. (I checked it with following breakpoints) Why is this?

The whole purpose of Data breakpoints is to detect a change of the value at the address, or am I misunderstanding something?

To be more specific: I have a Pointer A that points to a value. But the pointer A is changed (not the value it points to!) by a bug I'm trying to hunt down. So, I created a pointer B that points to the address where pointer A is stored and set a Data Breakpoint on Pointer B. Here is the initialization:

#define lastCMDRingBufferSIZE 255

volatile uint8_t lastCMDRingbuffer[lastCMDRingBufferSIZE]; //
volatile uint8_t*lastCMDRingstartPtr = lastCMDRingbuffer; // This is PtrA
volatile uint32_t*ptrToPtr = &lastCMDRingstartPtr; // PtrB

Or another way to put it; Is a databreakpoint triggered if:

  1. the content of the address is written by a array overflow?
  2. the content of the address is interpreted as part of a larger data structure that is somehow written by a rogue pointer? (expl: a 64 bit pointer is dereferenced and written to, as a result a 32bit integer gets overwritten)

Your suspections and advice are highly appreciated :)

Solution

  • The debug hardware I've used that supports break on data access aren't implemented like I think most people would expect them to be. The hardware doesn't monitor the memory at the address and issue a breakpoint if it changes, it monitors the read/write bus of the CPU and breaks if an access happens at the given address (or range of addresses) and of the correct width.

    The end result is you can have some activities not be caught by the hardware. DMA accessing the memory is a big one that you simply cannot catch (unless your SRAM/DRAM interface has the ability to issue a fault like that). Also, if you're accessing the address in the mode which the debug hardware isn't configured for (i.e. doing byte writes when you're looking for word writes--which might be possible if you have a very naive memset/memcpy that does byte accesses)

    My guess is you're doing some byte accesses on the array declared before your pointer and stomping on the pointer by overflowing the array. Even though you set up the word access hardware breakpoint on the pointer, it isn't being caught because you're doing byte accesses.