• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 30 subscribers
  • Views 321 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.

TMS570LS0432: SL DemoApp sys_startup and SL_Init_ResetReason

Patroklos Anagnostou1
Prodigy 240 points
Part Number: TMS570LS0432

I am trying to understand the expected startup sequence of the safety library's demoapp (NoOS) for TMS570LS0432:

  • When attempting to debug the app, the reset reason is returned as RESET_TYPE_DEBUG which seems to skip the SL_SelfTest_STC(STC_COMPARE_SELFCHECK,...)
  • If the execution is restarted using the CPU reset buttons of CCS IDE, the reset reason is no longer RESET_TYPE_DEBUG and the self test function is called, leading to some exception handler. Trying to port the demoapp startup sequence to our project, I more specifically notice that the execution remains in an endless loop inside _SL_Kickoff_STC_execution().

I suppose that having a debugger connected messes up with the CPU reset and in that case the IDE restart buttons should not be used? Could you point me to a specific part of the documentation?

  • 0
    TI__Guru**** 197126 points

    Hello,

    1. You are right. If the reset reason is WDRST, it doesn't perform STC selftest.

    2. The CPU reset from CCS IDE will not set any bit of SYSESR. So the RESET type should be RESET_TYPE_DEBUG. If you click "SYSTEM RESET" from CCS IDE, the SYSESY value will be 0x2008 (external reset and debug reset).    

  • 0 in reply to QJ Wang
    Prodigy 240 points

    Indeed, I see the same button can perform either CPU RESET or SYSTEM RESET using the small arrow next to it. The CPU RESET leaves SYSESR with 0x0 while the SYSTEM RESET sets it to 0x2008 as you suggested. Thank you