Pause Counter component when in step-by-step debugging

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
ricardoquesada
Level 4
Level 4
First solution authored 50 sign-ins 25 replies posted

Hi,

I'm using the Counter component (UDB - 32-bits).  I'm using this component to measure time.

So, when I'm doing step-by-step debugging, I'd like it to paused. 

What I noticed is that the Counter keeps updating even if the program is paused while I'm debugging it.

 

Is it possible to do that? Perhaps it is a simple as pausing the Clock that drives it... but how to do that? Thanks!

0 Likes
1 Solution

The short answer is no.

The longer answer is that the design elements are hardware.  Even when you debug stop, the processor CPU clock is still running.  Every hardware unit in your design that runs off the clock is still operating also.

A temporary solution(that I have used) is to have an  interrupt service routine handle my main "timer" (which is usually a millisecond timer).

Unfortunately, when you single step, the ISR is executed in the background, so that does not always help.

I have put specialized "breakpoint" code in my firmware while debugging.

if (condition) then disable timer, increment throwaway variable endif

Put a breakpoint on the increment variable.   You can then single step through your code with the counter non functional.  I have used that pattern for hard to catch ephemeral issues.

 

 

View solution in original post

0 Likes
6 Replies
Len_CONSULTRON
Level 9
Level 9
Beta tester 500 solutions authored 1000 replies posted

ricardo,

There is no practical way to pause the UDB HW counter when you pause in the debugger.

Len
"Engineering is an Art. The Art of Compromise."
0 Likes
ricardoquesada
Level 4
Level 4
First solution authored 50 sign-ins 25 replies posted

Thanks Len.

Let me ask you a more generic question then:  is there a way to pause any hardware component (the clock or whatever is needed to pause them) when we are in a breakpoint and/or step-by-step debugging?

 

Thanks!

0 Likes

The short answer is no.

The longer answer is that the design elements are hardware.  Even when you debug stop, the processor CPU clock is still running.  Every hardware unit in your design that runs off the clock is still operating also.

A temporary solution(that I have used) is to have an  interrupt service routine handle my main "timer" (which is usually a millisecond timer).

Unfortunately, when you single step, the ISR is executed in the background, so that does not always help.

I have put specialized "breakpoint" code in my firmware while debugging.

if (condition) then disable timer, increment throwaway variable endif

Put a breakpoint on the increment variable.   You can then single step through your code with the counter non functional.  I have used that pattern for hard to catch ephemeral issues.

 

 

0 Likes

Thanks WaMa. It makes sense.

Perhaps in an ideal world we could have something like the following:

- Context: I'm using a Sync + Counter components and described in the "Counter component" example.

- Let's assume that Sync has an "enable / disable" feature that can be toggled by writing to a certain register (or have a "Chip enabled" pin, what when it is High it is enabled).

- Let's assume that GDB has an API that allows you to invoke/run some code when a breakpoint is triggered and when you continue with the breakpoint.

 

So with that into account, when the breakpoint gets triggered, it will invoke our script that will just disable "Sync" by writing "0" to a certain register. The script is responsible for saving / restoring all the modified states .

And when we continue / leave the breakpoing, we just enable Sync again by writing "1" to the register (and we save/restore the modified states as well).

0 Likes

ricardo,

The 'beauty' of an excellent HW state machine (like a UDB counter component) is that it can be made to operate with virtually NO CPU or, if needed, NO DMA intervention.  This allows for maximum operation even if the CPU or DMA is high busy doing other things.

The Debugger is a great feature but does rely on the CPU to do it work.  A 'pause' in the debugger diverts the CPU to an 'interrupt-like' routine to implement the debugging functions.  However, I'm not aware of any HW signal available during debugging that can be used to signal HW state machines in your application to halt.  Note:  There are at least 2 SWD pins used for the debugging serial protocol.  Maybe someone monitoring this thread might think of a way to use any of these signals as a HW halt signal for other HW state machines.

Here is a suggestion that might come close to give you what you are looking for:

  • Use a GPIO as an input with a switch.  The CY8CKIT-059 uses P2.2 as a port pin assigned to a switch.  (See schematic below)

Len_CONSULTRON_2-1635344366162.png

 

  • Use the Debouncer/TFF output to connect the "HW_halt" to your other HW state machines that you need to 'halt'
  • Create a ISR with a single command in it.  ExL
    /***************************************************************************************/
    CY_ISR(Debugger_stop_isr)
    {
    volatile uint8 i = 0;
    }​
  • Start the ISR in main() => isr_Debugger_stop_Start(&Debugger_stop_isr);
  • On the single command place a Breakpoint.
    Len_CONSULTRON_3-1635344779269.png

     

  • Run the application with the debugger.  
  • When you what to pause the debugger, press the switch assigned to the HW "Halt".
  • This will trigger the "HW_halt" to the HW state machines downstream of the signal
  • It will also cause the debugger to stop at the breakpoint in the special ISR you created.
  • To exit from the 'pause', you need to "Run" (F5) and then press the switch again to toggle the "Halt" signal off.

The above 'kludge' is should work (I have not tested it). In general it would be better to find other debugging techniques that don't require halting the HW state machines.

Here are two methods I find useful:

Method #1: UART debug data

If the data being analyzed is relatively slow I use  the UART to dump diagnostic data about the current state of the HW at assigned events.

This allows for more complete info but it takes time to push to the terminal.

Method #2: Framing signals

If the HW events needed to monitor occur frequently and quickly, I use framing pulses using GPIO pins and then viewed on a scope.  I can also push parallel data out ports.

Framing and data port pushes can take as little as a few useconds.

 

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

Thanks for the detailed answer Len.

Although I'm looking for an automated solution. I'd like to avoid pressing a switch (or similar)... that's error prone.

Other MCU, like the STM32 has Timers that are auto-paused when the debugging is on (IIRC the 32-bit TIM2 timer supports it).

0 Likes