Conditional watchpoints

[scottm]

I'm looking for some information on how watchpoint conditions are supposed to work in MCUX - there's very little at all on watchpoints in the documentation, and nothing about conditions.  At McuOnEclipse, Erich has an article discussing them a little, but there's no information on how they work.

What I'm hoping to accomplish is to find out when a particular pointer is getting set to NULL.  I can catch writes to it easily enough, but most of the writes are going to be normal and I might have to wait through hours of normal operation to catch the problem.  If I add a condition px == 0, the system runs extremely slowly and gdb crashes when I try to pause it.  I've tried both an LPC-Link2 and a Cyclone ACP.

What I assume  is happening is that the debugger is having to stop and check the memory contents constantly.  The watchpoint itself has to be implemented by a hardware comparator and the manual says as much, but does the hardware support value comparisons or just address matches?  Is there a way I can get this thing to run at a reasonable speed while still checking for nulls?

Thanks,

Scott

[BlackNight]

Hi Scott,

I appologize that I have not covered that topic in details. Mostly because how watchpoints are implemented depends on the hardware, debug connection and capapilities of the used debug probe.

What typically happens is that for a gdb/CDT watchpoint the debugger is setting a hardware comparator (read/write) on that address, as this is the simplest comparator usually availalbe on most hardware. This then triggers on each access (depending on the R/W flag) to stop the debugger. The debugger then evaluates the condition you have specified and this decides if the target continues to run. So if you have many accesses to this varible, it will stop many times the hardware and this is why you see it is going slower. If you are only interested in write accesses, it will help if you do not set the 'read' flag for the watchpoint. But if you have many writes and you are waiting for a given condition, this again will be slow.

For simple conditions an extra 'match value' comparator could be used/linked with the R/W bus access comparator. I have done something this a while back with a K64F and the LPC-Link2, but I have to dig the details out, of this is of any interest?

I hope this helps,

Erich

[scottm]

Hi Erich,

No need to apologize, your blog still has more information on the subject than the user's manual!  If you've got any information on how to set up the comparator that would be great.  Do you remember roughly how it was set up?  Is it all done through gdb commands?  I haven't gotten into the DWT documentation yet.

I'm trying to figure out where my FreeRTOS pxCurrentTCB pointer is getting clobbered, and of course it changes with every context switch so it's a lot of writes.  I've set a canary value adjacent to it and put a watchpoint on that to catch any writes that might be due to stack or buffer overflows but I haven't caught anything yet.  I was able to get some data out of the system last time I got a usage fault and verified that all of the stacks were OK and nothing around pxCurrentTCB seemed to be disturbed.  I'm not sure if the null pxCurrentTCB is a cause or an effect.

I'm getting an INVSTATE usage fault, with PC = 0x100, which is of course an interrupt vector (that I'm not using), but I don't think a vector fetch is happening - I set a read watchpoint on 0x100 and it never trips.  I think the INVSTATE fault is happening when something loads or pops 0x100 onto PC and it doesn't have the thumb bit set.  LR is set to an EXC_RETURN value that indicates it's expecting to return to handler context.  I have breakpoints on my fault handlers so it seems like it must be something in an ISR.  I can sometimes run for 12 hours or more without a fault and when I do get one I've got about a 50% chance of getting any debug data out of it, and that sometimes requires restarting the IDE before an 'attach' will work.

Thanks,

Scott

[BlackNight]

I have put out a tutorial about conditional watchpoints here:

Tutorial: Catching Rogue Memory Accesses with Eclipse and GDB Watchpoints | MCU on Eclipse 

Another article explains how to use hardware for conditional watchpoints with the MCUXpresso IDE:

Tutorial: Catching Rogue Memory Accesses with ARM Watchpoint Comparators and Instruction Trace | MCU... 

I hope this is helpful,

Erich