• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 245 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: ESM Callback Error for TOG Module

Kevin Peng
Expert 3752 points
Part Number: TDA4VH-Q1
Other Parts Discussed in Thread: TDA4VH

Hi TI Experts,

Customer is working on TDA4VH SDK9.1.

They are doing the TOG module initialization on MCU1-1.

However, when they use ESM callback function they found the below error.

The callback function is below.

They also read the ESM register below.

The error information got from the register is below.

Could you help provide some suggestions about what could cause these problems please?

Another question is that, customer does not know the meaning of the STOG index below. We cannot find this information on TRM.

 

Actually the reason why customer did the TOG module initialization is to follow the SDL_SA_0006 requirement in the SDL Safety Manual. They do not know if they have to initialize all of the above STOG instances, or just a part of them is enough.

Please help provide some suggestions on this please, thanks for that!

Kind Regards,

Kevin

  • 0
    TI__Mastermind 40436 points

    Hi Kevin,

    The callback seems to be due to this event -

    #define SDLR_WKUP_ESM0_ESM_LVL_EVENT_WKUP_VDC_INFRA_VBUSP_32B_SRC_SAFEG0_INFRA_SAFEG_TRANS_ERR_LVL_0 (16U)

    which is the TOG event for the WKUP_VDC_INFRA instance. You can refer to the SDL tog_test_app where this instance has been tested and follow the same steps.
    Kevin Peng said:
    They do not know if they have to initialize all of the above STOG instances, or just a part of them is enough.

    TI recommendation is that all instances of the STOG HW modules have S/W implementations of the diagnostics called out in the Safety Manual.  

    STOG Index STOG
    STOG0  VIRT to HWA
    STOG1  AC_CFG ASILB slaves
    STOG2  AC_CFG QM slaves
    STOG3  RC to HC2
    STOG4  RC to HC2
    STOG5  HC_CFG ASILB slaves
    STOG6  RC_CFG ASILB slaves
    STOG7  IPPHY QM slave
    STOG8  IPPHY ASILB slaves
    STOG9  MAIN_INFRA_SAFE_TO_MAIN_INFRA
    STOG10  WKUP to MAIN
    STOG11  MCU to RC MAIN
    STOG12  FSS0
    STOG13  FSS1
    STOG14  MCU_TO_FW
    STOG15  MCU_TO_MAIN_INFRA_SAFE
    STOG  NAVSS PVU CFG
    STOG  NAVSS PVU SRC
    Regards,
    Josiitaa
  • 0
    TI__Expert 3752 points

    Hi Josiitaa,

    Thanks for your reply.

    We have tried SDL tog_test_app for STOG instance from 0 to 15. They all passed except STOG instance 11, it will cause customer system reset. Is this instance working well on your end?

    As for the below statement, could you please help check that just for achieving SDL_SA_0006, it is still recommended to have all of the STOG instances from 0 to 15?

    TI recommendation is that all instances of the STOG HW modules have S/W implementations of the diagnostics called out in the Safety Manual. 

    Thanks a lot!

    Kevin

  • +1 in reply to Kevin Peng
    TI__Mastermind 40436 points

    Hi Kevin,

    Kevin Peng said:
    We have tried SDL tog_test_app for STOG instance from 0 to 15. They all passed except STOG instance 11, it will cause customer system reset. Is this instance working well on your end?

    Which SDK are you testing this on? I have tested it on the latest 9.1 SDK and all the instances pass.

    Kevin Peng said:
    As for the below statement, could you please help check that just for achieving SDL_SA_0006, it is still recommended to have all of the STOG instances from 0 to 15?

    Yes, the recommendation is to test all instances to achieve safety coverage.

    Regards,

    Josiitaa

  • 0 in reply to Josiitaa RL
    TI__Expert 3752 points

    Hi Josiitaa,

    Customer finally found out that the instance 11 problem is due to their own setup problem. So all the instances could pass now.

    Thanks,

    Kevin