DA14921 Debugging No stack trace.

Question

Hello, 
 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. 
 Can you suggest any tips to finding the cause of of the assertion? I've tried increasing task stack size just in case the task was failing perhaps but it didn't change the problem. The firmware runs for a period of time and seems to be fine before the failure so it's possible there is a memory allocation problem or something similar as well.

Dennis · Accepted Answer

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.

OV_Renesas · Answer

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

OV_Renesas · Answer

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() ASSERT_ERROR() OS_ASSERT() The Assertions are triggered when the 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: /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_.list ) The executed GDB commands (file: gdb_cmds _. gdb ) The log (dump) of the executed GDB commands (file: gdb_cmds _.log ) The RAM snapshot at the dump time (file: online_memory_snapshot _.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

DA14921 Debugging No stack trace.

Top Replies