2

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 :)

anyone
  • 157
  • 7
  • The logic has to be designed to trigger something when an address matches a break/watch. So on a windows/linux type cpu you could just use the mmu to mark an address space as protected, then in the handler for the protection decide if it is the watch address or let it pass through. if on a microcontroller though you either need to have the debugger poll a lot which is not good or have on chip logic support. Perhaps you have neither of those going on or perhaps the debugger has not properly set the watch. – old_timer Apr 12 '17 at 13:27
  • Is this an avr or arm or other? I dont think the AVR can do multi word writes, the arm certainly can but would assume the logic there would be smart enough to trigger on an stm or std if the address being watched was not the address passed but within the multi-word write. – old_timer Apr 12 '17 at 13:29
  • This does not depend so much on Atmel studio or even the ICD, but on what hardware breakpoints that the specific MCU supports. Please clarify which MCU that is used. – Lundin Apr 13 '17 at 13:13

2 Answers2

2

You are not addressing (pun not intended) this in the correct way. If the pointer A is being corrupted, the data breakpoint needs to be set on &A directly; creating a secondary pointer will not do anything useful unless you can set a conditional breakpoint of A != B.

Is a databreakpoint triggered if:

  1. the content of the address is written by a array overflow? the content of the address is interpreted as part of a larger data structure that
  2. 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)

It is triggered when the value at the breakpoint address changes - simple as that; the on-chip debug hardware has no concept of language constructs; the address you need to watch is therefore &A not A or B.

In the context of your actual code if lastCMDRingstartPtr is modified, ptrToPtr will not also change. Simply enter &lastCMDRingstartPtr as the address; then you will get a break when the value of lastCMDRingstartPtr changes.

Clifford
  • 88,407
  • 13
  • 85
  • 165
  • Ok, I set a Databreakpoint on Both and neither of which is being triggered. After more investigation I found out, that PointerB is being corrupted too... I suspect a rogue array write. I was convinced that Databreakpoints set on a pointer variable are watching the Address that pointer is pointing at, not the address the pointer is actuallay located in. So Is this a wrong assumption? – anyone Apr 13 '17 at 07:17
  • I tried another way to investigate without data breakpoints and found the culprit, but I want to finish this for the sake of future generations. Now a following problem arose, for those interested, this is the [link](http://stackoverflow.com/questions/43387873/atmelstudio-uc3c-avr32-framework-objects-in-wrong-place-in-memory) to the new problem. – anyone Apr 13 '17 at 09:04
  • In the on-chip debug it is just an address. How the PC software sets that address may differ - that is what documentation is for; I have never used Atmel Studio, but it seems pretty clear here: http://www.atmel.com/webdoc/atmelstudio/atmelstudio.debugging.databreakpoint.uc3.window.html. If you have a pointer `ptr` and you want to see if the pointer value changes then _location_ is `&ptr`, if you want to know when the data pointed to changes then just `ptr`; but note that case you can only monitor 2 to 4 bytes at the specified address - not an entire array. – Clifford Apr 13 '17 at 10:37
1

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.

Russ Schultz
  • 2,545
  • 20
  • 22