• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 100 subscribers
  • Views 555 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

[FAQ] TDA4VM: Debugging remote core firmware using CCS

Karan Saxena
Guru* 75222 points
Part Number: TDA4VM

I am booting remote cores (R5F) from u-boot which run along side Linux (on A72) in my system. I want to debug the remote core firmware by stepping through the source code and modifying / viewing registers and memory. How can I do this?

I have done this with standalone R5F applications when I load them also from CCS, here I am loading from u-boot but still want the same level of debug capabilities.

  • +1
    TI__Guru* 75222 points

    Steps

    1. Call the below mentioned function as one of the first things in main() of the firmware.

    /* Global volatile variable */
volatile uint32_t ccs_halt_flag = 0xDEADBEEF;

void startup_wait_for_emulator(void)
{
    /* Loop forever */
    while(ccs_halt_flag);
}

void main()
{
    startup_wait_for_emulator();
    ...
    ...
    ...
    ...
}

    2. Rebuild the firmware and load this modified firmware to load from u-boot.

    3. Boot Linux on the board, at this point the remote core firmware will be loaded but it will keep on busy waiting in the while() loop.

    4. Connect CCS, without loading any GEL files and just attach to the core running the firmware.

    5. Load symbols for the applications and then go to expressions tab and add "ccs_halt_flag". Modify the value of the variable from 0xDEADBEEF to 0x0 and step through.

    5. You can now source code debugging now.

    Things to take care

    1. The above mentioned method will not work for MCU domain R5F on TDA4 as MCU R5F (MCU1_0) runs Device Manager (RM/PM services) and hence if MCU1_0 is in a busy waiting loop, not even Linux will boot.

    2. In case the firmware you are trying to debug has some dependency on another firmware or vice-versa then you will need to take care of how you synchronize execution.

    3. In case the ccs_halt_flag is optimized and you are not able to see that in the expressions tab, then go to the registers and find for 0xDEADBEEF and change that to 0x0. This is where initializing with a known pattern helps.

    Regards,

    Karan