DA14921 Debugging No stack trace.

Hi Dennis,

Thank you for posting your question online.

Dennis said:

I'm using SDK10.1.4.104 with e2studio and the development board for testing.  I have a program that will stop working due to an ASSERT_WARNING and is stuck in the do {} while(1) loop for that macro.  Normally, if I just place an assert_warning in my code, the debugger will stop and you can see what the problem was to address it.  In this specific case though, there is no stack trace.

On my side I set an ASSERT_WARNING(0) on a UART task I had created.
I downloaded the project and let it run with debugger attached.
When I paused the project I could see the following screen:

1) As you can see it is being stuck inside the assert_warning function.
This can be seen on the top left corner as well on Thread #1. 

2) On the bottom tabs of your screen, you can click on Registers--> General Registers to check the Cortex M33 Registers.

3)On the end of the left Debug window you can see the UART1 Task which the ASSERT_WARNING was placed.

4) You can also find on the right top corner the Breakpoints tab and the IO Registers. 
You can use the IO Registers while debugging Peripheral blocks and always by following the Datasheet.

Please also make sure you have checked the Configure DA1459x e2 studio Debugger.


In order for all the above to work as expected you just need to check that dg_configIMAGE_SETUP  is set to DEVELOPMENT_MODE

If I am not mistaken, this macro is set to DEVELOPMENT_MODE by default for all of our examples. 
When you have finished development you can undefine that macro to save up some memory.

Best regards,
OV_Renesas

Thank you for the reply.  I'm having trouble seeing in your picture where you placed the assert in your code. I see the last stack item in port.c but didn't you place the code in main.c? 

For me, I get even less stack trace when this problem occurs:

I see the assert in thread 1 and also thread 7 but there just isn't any useful information as to what is causing it as far as I can tell.  I noticed the debugger console does print a line in free_rtos/timers.c when I click on the earlier stack elements in thread 7.  They're all the same though.

Near as I can tell thread 7 is my uart receiver thread since I can see my UART sending thread (thread 2) and none of the other threads have any uart rx stack.  But It's still unclear what actually is causing the assert.

Hi Dennis,

Thank you for the reply.
Please check the Registers tab.
Check the LR and PC registers and then refer on your map file ( should be on the Debug folder) to see where exactly they point to.

Best Regards,
OV_Renesas

I'm probably missing something.  The PC is just showing the assert warning location still.

But I'm  unsure how to figure out how it got there... I'll look more into the LR register and see if I can determine anything...

In this case the LR is just pointing to one past the PC which doesn't seem to make sense.  Maybe that is part of the issue why the IDE isn't showing a stack trace.

Sometimes when more frames are shown in the thread list, but no stack info, the registers tab contains the following:

Hi Dennis,

Thank you for the reply. 
Let me try to share some insights on how to Debug on the DA1459x family.
Basic Debugging:
Breakpoints:
A breakpoint stops the code execution when the PC [Program Counter] reach the point in the source code placed the BKPT.
In an M33 there can be up to 8 breakpoints.
If set more than 8, then only after the first 8 will be ignored.
Assertions:
Assertions are pieces of code that stop the code execution if the passed condition is false.
They are inserted through Macros and can be implemented within the Macros or as functions.
The Assertion Types in SDK10 are:

• ASSERT_WARNING(<condition>)
• ASSERT_ERROR(<condition>)
• OS_ASSERT(<condition>)

The Assertions are triggered when the <condition> is evaluated to false.

When an Assertion is triggered, the following actions take place:

• Disable the interrupts.
• Freeze the Watchdog (WD).
• Execute a while(1)

When (#define dg_configIMAGE_SETUP DEVELOPMENT_MODE) then the Assertions are fully implemented as described and all are equivalent to each-other.When (#define dg_configIMAGE_SETUP PRODUCTION_MODE) then the ASSERT_WARNING() and OS_ASSERT() are implementing only the condition passed. The code, WD and Interrupts are not stopped/disabled.

The ASSERT_ERROR() is disabling interrupts and throws a breakpoint exception using __BKPT(2); which will lead to system reboot

Watchdog and Fault Handlers:
The DA1459x implements:
A HW Watchdog (details can be found on the Datasheet)
The 4 ARM Fault Handlers for:
1) Hard Fault
2) Memory Fault
3) Bus Fault
4) Usage Fault
One ARM Debugging Exception Handler: Debug Monitor

From the Watchdog and Fault Handlers we can get the Register information.
The LR points at the code address where the execution would resume. It is valid only if the code is executing a block from a Jump/Branch command like a function call. 
The PC points at the code address in execution when the exception happened.
Note: The CFSR, HFSR, MMAR, BFAR registers contain also useful information for the HardFault root cause analysis

Note2: You can find online multiple Tutorials/Application Notes on how to debug on ARM Cortex M

Collecting Debugging Information:
In the SDK10 bundle there are some Python scripts enabling anyone to attach to a device with problem (e.g. in a HardFault) and get a snapshot of the whole system.
The launchers for collecting the debug information are part of the python_scripts project and they are integrated into e2 Studio.

The collect debug information Launcher need from the user only to point at the chip Registers XML file in: <SDK10>/config/embsys/Dialog_Semiconductor/The collected information is saved in subfolder with the timestamp of the capture under: /utilities/python_scripts/collect_debug_info/debug_dumps

NOTE: Depending on the version of the SDK10 used might be needed to have also installed the Python 2.7 on the PC running the debug collection information script. In Windows it is expected to have Python 2.7

• Each dump will contain the following information:
• The list of symbols (file: symbols_<timestamp>.list)
• The executed GDB commands (file: gdb_cmds_<timestamp>.gdb)
• The log (dump) of the executed GDB commands (file: gdb_cmds_<timestamp>.log)
• The RAM snapshot at the dump time (file: online_memory_snapshot_<timestamp>.ihex)
• The application .elf file
• The application .map file

There is a very nice README.md file in the folder python_scripts/collect_debug_info/doc/ explaining the content and gives instructions how to use the dump.

I hope this could be helpful.

Best regards,
OV_Renesas

Thank you for this information.  I will see if I can use the python scripts or additional registers to gain more information to the cause of the assert.

I'm afraid running the collect_debug_info script hasn't yielded any new information pertaining to the stack trace of the current task.  It dumped the same thing I see in the editor window where the assertion has no stack trace beyond _sbrk_r(). 

All the hardware faults listed on the Fault Status page are 0.

Would it help to share the info collected by the debug script?

FYI I compiled my image with PRODUCTION_MODE instead of DEVELOPMENT mode to change the behavior of the ASSERT_ERROR.  After reproducing the issue, I was able to get a stack trace and determine the cause is that a malloc failed.  I must have a memory leak or just need more heap space.  It's unclear why the debugger won't show the stack trace when this problem occurs but I can work around it easily enough with PRODUCTION_MODE for now.

Hi Dennis,


Thank you for the reply and glad you were able to solve the issue.
Please check this example as well:ble-sdk10-da1459x-examples/helpers/armv8_fault_handling_example at main · renesas/ble-sdk10-da1459x-examples

Best regards,
OV_Renesas