• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 99 subscribers
  • Views 189 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TDA4VH-Q1: The C71 call stack information obtained by CCS is insufficient

hongyao.jin
Expert 1190 points
Part Number: TDA4VH-Q1
Other Parts Discussed in Thread: TDA4VH

Tool/software:

Hardware: TDA4VH
SDK: 1001 linux + RTOS

CCS:12.4.0

When we debug the C71 program, a crash occurs. However, when we use CCS to obtain the call stack information, only can be seen stopping at secure_soft_reset, and no other information can be seen. How can we see the call stack information before secure_soft_reset?

  • 0
    TI__Expert 6690 points

    Hi,

    I assume you're running the code in No Boot mode. Could you please confirm which build type you're using—Debug or Release?

    Regards,
    Sivadeep

  • 0 in reply to Sivadeep P R
    Expert 1190 points

    hi

    We are using the emmc boot mode because our function requires all the cores to run completely, and the program we built using the debug mode.

    When the program crash, we attach the corresponding core through CCS and then load the corresponding symbol.

    The following picture shows the call stack captured under normal circumstances. We want to be able to see such a call stack as well when the program crashes, rather than just having a crashed message, which is of no help.

  • 0 in reply to Sivadeep P R
    Expert 1190 points

    hi

    This picture captures the crash scene of TC397 through UDE, we can see that the OS has entered the OS_TRAP, but at the same time, we can also see the call stack before entering the OS_TRAP, So we can clearly see that the system crash is caused by the g_test_flag function.Does CCS support this?

  • 0 in reply to hongyao.jin
    TI__Genius 9520 points

    Hi, Hongyao,

    For the scenario you encountered, it will be quite difficult to get the call stack because CCS will do the call stack analysis based on the current PC value and the stack of the task the code belongs to. The real challenge for exception is the trigger of the exception is the interrupt vector and there is no much calling info can obstain.

    Normally, we need to cross check the running log and the corruption position to nail down which task was running before the exception happened. And then to add debug code to further narrow down to figure out the root cause.

    For some cases, the ROV might be helpful. Please refer below links:

    - How to diagnose and debug embedded software program crashes using TI’s ROV debugger

    - FreeRTOS Real-time Object View (ROV)

    Br, Tommy