• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 31 subscribers
  • Views 304 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.

AWR2944: Bootloader_runSelfCpu failed to jump in SBL

Allen35065
Expert 4005 points
Part Number: AWR2944

Tool/software:

Hi expert,

SensorTech update their SBL from SDK 4.4.1.2 (awr294x_09_00_00_15) to SDK 4.6.1.2 (awr294x_09_02_00_15), and their application is still on SDK 4.4.1.2.

And they find Bootloader_runSelfCpu in the end of SBL is not able to jump to application sometimes.  According to the function as below, it should not return from this function but we saw it returned. The issue possibility is quite low (0.1% ~ 1%).

int32_t Bootloader_runSelfCpu(Bootloader_Handle handle, Bootloader_BootImageInfo *bootImageInfo)
{
    int32_t status = SystemP_SUCCESS;

    DebugP_logInfo("All done, reseting self ...\r\n\n");
    status = Bootloader_socCpuResetReleaseSelf();
    /* control will not reach here */

    return status;
}
I saw there is similar case in e2e forum as below.
Could you please check this question and provide any comments if you have?
Thank you.
Regards,
Allen
  • 0
    TI__Mastermind 35255 points

    Hello Allen,

    Is this debugger connected or not connected experiment?

    Regards,
    Saswat Kumar

  • 0 in reply to Saswat Kumar
    TI__Expert 4005 points

    Hi Saswat,

    According to SensorTech tests this issue is not related to debugger. 

    At first they did not use debugger and found SBL hung in the production tests after they upgrade the SBL in flash. And it can be reproduced on each board.

    Then they tried to connect debugger and they can still reproduce this issue. They tried to single step and found problem in Bootloader_runSelfCpu. 

    Regards,

    Allen

  • 0 in reply to Allen35065
    TI__Mastermind 35255 points

    Hello Allen,

    These kind of issues due to its nature is hard to debug.
    As suggested in the e2e can you try to add the code 2 times to see if it is helping?

    Regards,
    Saswat Kumar

  • 0 in reply to Saswat Kumar
    TI__Expert 4005 points

    Hi Saswat,

    For SensorTech, it's OK for them to use SDK 4.4 SBL in production. But they need to know (Also request by can OEM XPeng) what may be the root cause because of several reasons.

    1. They are not sure if there is any possibility to have this issue in SDK 4.4 on the mass production 2944 radars.

    2. For 2E44 or 2E44P (ECO) in the near future, they are going to use SDK 4.6 or 4.7. They need to know root cause to avoid this happen.

    3. Not sure if there is still hung up when using 2 times Bootloader_runSelfCpu. Maybe there is still very low possibility.

    Could you please check with team about two questions?

    1. Does TI have long-time reset tests on the SBL with TI demo? Is there any similar issue observed? How many times of reset tests was done?

    2. We compared  the difference between SDK 4.6 and SDK 4.4. The differences is

           a. CLANG version (2.1->3.2)

           b. R5 image download timing in SBL is changed.  (SensorTech moved download timing as what TI did in SDK4.4 and no issue was seen).

       Can you find possible root cause according to the difference?

    Thank you.

    Regards,

    Allen

  • 0 in reply to Allen35065
    TI__Mastermind 35255 points

    Hello Allen,

    In our Reset tests we have never caught this issue. This is always observed by customers and most of the times this is because of the debugger attachment not because of functional break of code.

    One of the things they can check is if there is any code difference between the functions:

    SOC_rcmR5PowerOnReset
    SOC_rcmR5TriggerReset

    In the trigger reset is this instruction code retained:
    #if defined(__ARM_ARCH_7R__)
        __wfi();
    #endif

    We need to identify what are the differences then.

    But to your initial questions, in our reset tests this issue was never caught. and we have run over the weekend(48+ hours). In this test we have looped over the SBL and application in a warm reset continuously and the device is functioning as expected. 

    Regards,
    Saswat Kumar