Sometimes, it is tempting to take guesses as to what might be happening or make assumptions about the system. Rather than doing either of these things, we'll simply connect our debugger to the system to see what the problem is.

Since SEGGER Ozone is exceptionally good at connecting to a running system without modifying its state, we're able to connect to the hung application without disrupting anything. This allows us to start debugging an application after it's crashed, even if it was previously not running through the debugger. This can come in very handy during product development since it allows us to run the system normally, without constantly starting it from the debugger. Let's learn how to do this:

1. Set up Ozone with the same code that is running on the target. Note that the development board must be connected via USB (see Chapter 6, Debugging Tools for Real-Time Systems, for details). 

2. After that, select Attach to Running Program:

3. Upon attaching and pausing execution, we're greeted with the following screen and are immediately able to make some observations:

Notice the following:

• The LEDs have stopped blinking because we're spending all of our time in an infinite loop because of a failed assertion.
• By looking at the Call Stack, we can see that the offending function is SEGGER_SYSVIEW_RecordSystime, which is apparently making a call to a function called _cbGetTime, which in turn calls xTaskGetTickCountFromISR.
• Reading through the detailed comment above line 760, it sounds like there may be some misconfigured NVIC priority bits.
• The maximum acceptable value of ulMaxPROGROUPValue (which can be seen by hovering over the selected variable) is 1.

Now that we know which assertion failed, it's time to figure out the root cause of why exactly it failed.