• State Resolved
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 5 replies
  • Subscribers 100 subscribers
  • Views 311 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: SDL_WKUP_ESM0 Function

Kevin Peng
Expert 4348 points

Part Number: TDA4VH-Q1

Tool/software:

Hi TI Experts,

Could you please provide some explanation of the function of the below ESM?

SDLR_WKUP_ESM0_ESM_LVL_EVENT_WKUP_PSC0_PSC_MOD_WKLP_MCU_R5_1_CS1_CLKSTOP_REQ_0

The background is customer works normally before using Linux SDK10.1 + RTOS SDK10.1, recently they received our early drop on Linux SDK11 to migrate firstly, and now becomes Linux SDK11 + RTOS SDK10.1. Then they found a problem when their application is running, if they close the R5F1-1 core the system will reset (previously no this issue with Linux SDK10.1 + RTOS SDK10.1). After a lot of deep diving testing, they finally found the root cause about SDLR_WKUP_ESM0_ESM_LVL_EVENT_WKUP_PSC0_PSC_MOD_WKLP_MCU_R5_1_CS1_CLKSTOP_REQ_0. If they disable this ESM error bit, then there will be no problem.

Hence, customer would like to know what is the meaning or function of this ESM error bit? Could you provide some explanation please?

Thanks,

Kevin

  • 0
    TI__Mastermind 49786 points

    Hi Kevin,

    I will look into this ESM interrupt and get back to you.

    Regards,

    Josiitaa 

  • +1
    TI__Mastermind 49786 points

    Hi Kevin, 

    Yes, it is expected that some events will be set after device boot. 

    The SoC connectivity routes events to the ESM that could possibly impact system safety.  But the impact is dependent on the end system usage of the various components.  By default all ESM events are disabled (from generating an ESM event) at device boot so even if an event is set within ESM during device boot, nothing happens as a result.  It is good software practice to clear a pending event in the ESM before first enabling it to generate the Low or High interrupt or the Error output.

     The clockstop events in the MAIN domain are particularly likely to be set at device boot.  These events represent the clockstop request of every LPSC in the MAIN Domain.  After device boot, a large number of the MAIN domain peripherals are disabled by default through their associated LPSCs.  (This reduces power, etc.)  Software needs to enable the LPSCs as needed for the device application.  However, disabling a particular IP may have safety implications therefore the CLKSTOP requests are routed as ESM events. 

    The CLKSTOP_REQ raw events reflect the level output of the CLKSTOP_REQ handshake signal from the LPSC.  They will stay active until the LPSC de-asserts CLKSTOP_REQ (based on the enable state machine).  So even if you clear the event within the ESM, it will just get re-asserted. The steps to clear the clkstop event are as follows:

    Level Event

    1. Clear the Error Event at the Source
    2. Write a 1 to the appropriate bit in the Error Group N Interrupt Enabled Status/Clear Register (Base Address + 0x400 + N*0x20 + 0x04)
      1. This will clear the raw status
      2. If the error event is still asserted (or re-asserted) the raw status will be set back to 1
      3. If there are no error events, the level will de-assert.
      4. NOTE: there is a possible software race condition if software manages to write to the Clear register before the de-asserted level from the source has been synchronized to the ESM clock.  If this is an issue, software may perform a read-back at the source IP before writing the clear register to insure order.

     

    In this case the CLKSTOP_EVENT is not Cleared at the Source until the LPSC state machine changes to an EN state.

    Regards,

    Josiitaa

  • 0 in reply to Josiitaa RL
    TI__Expert 4348 points

    Hi Josiitaa,

    Thanks for the explanation of this ESM error event.

    As currently this ESM will cause the customer board reset. Even if this ESM is expected, customer cannot accept resetting the board everytime MCU1-1 is stopped by Linux command.

    Hence, if we keep enabling this ESM bit, we need guide customer how to control this ESM so that not resetting the board.

    If we disable this ESM bit, we need to give some analysis about the safety impact. Customer will review the safety impact to decide if they could accept disabling this ESM bit.

    Thanks,

    Kevin

  • 0 in reply to Kevin Peng
    TI__Mastermind 49786 points

    Hi Kevin, 

    Yes, TI is discussing this internally. I will get back to you in a few days.

    Regards,

    Josiitaa

  • +1 in reply to Josiitaa RL
    TI__Mastermind 49786 points

    Hi Kevin, 

    Attaching TI's response as per the internal JIRA discussion - 

    "It all depends on customer use-case. Customer needs to assess safety impact based on their safety concept.

    However, either they can skip monitoring of ESM by disabling the event in ESM bitmap or disable this event just before performing the power-off of this mcur5_1 core and enable it again when next time core will be power-up.

    This is something they will need to decide how they want to proceed further based on their use-case."

    JIRA ID - [LCPD-43508] ESM PSC/CLKSTOP event is generated in SDK11 - Texas Instruments JIRA

    Regards,

    Josiitaa