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.

TDA4VM: A POK module failure cannot trigger an ESM interrupt

Part Number: TDA4VM

hello!

version :SDK8.6

When a wrong TRIM value is set to CTRLMMR WKUP POK CTRL reg, CTRLMMRWKUP POK STAT reg can check the POK error, but ESM can't check it and generate an interrupt event

We need the interruption of the ESM to inform the error status of the POK.

Please help to investigate.

  • Hi,

    Is the issue being reported that, when POK sees an error, that the error is not being propagated to the ESM?

    If yes, has the SDL POK example code been tried/referenced?

    If the issue being reported is something different, please advise. 

    Regards,

    kb

  • Thank you very much for your answer. It is OK for me to run this demo, but there is still a problem

    We need to monitor the following dozens of POKs at the same time, and we inject these dozens of POKs into the fault at a time, but only one ESM interruption feedback will be received each time, Please help to investigate.

     Below are the POK ID values
      SDL_POK_VDDA_PMIC_IN_ID is:       0
      SDL_POK_VDD_CORE_UV_ID is:        1
      SDL_POK_VDDSHV_WKUP_GEN_UV_ID is: 2
      SDL_POK_VDD_CPU_UV_ID is:         3
      SDL_POK_VDDR_MCU_UV_ID is:        4
      SDL_POK_VMON_EXT_UV_ID is:        5
      SDL_POK_VDD_MCU_OV_ID is:         6
      SDL_POK_VDDR_CORE_UV_ID is:       7
      SDL_POK_VDDSHV_WKUP_GEN_OV_ID is: 8
      SDL_POK_VDD_CORE_OV_ID is:        9
      SDL_POK_VDDR_MCU_OV_ID is:        10
      SDL_POK_VDD_CPU_OV_ID is:         11
      SDL_POK_VDDR_CORE_OV_ID is:       12
      SDL_POK_VMON_EXT_OV_ID is:        13
    
  • psdkra/sdl/sdl_docs/userguide/j721e/release_notes/j721e/release_notes_01_00_01.html

    The sdk8.6 releasenote mentioned the POK exception issue, I don't know if it is related to the current issue.

    I hope you can help me confirm this problem
  • Hi,

    In your testing, if each of the SDL_POK_*_ID's is tested individually, does a different ESM event trigger the interrupt handler?

    Is issue being reported:

    • when testing in parallel, the same ESM event is firing each time, regardless of which POK is being tested,
    • when testing in parallel, the correct ESM event is firing (ie different POK ESM events are seen), but other POK ESM events are lost.

    Will check with team on know issues, and respond on that by EOD 09/28

    Thanks, 

    kb

  • In your testing, if each of the SDL_POK_*_ID's is tested individually, does a different ESM event trigger the interrupt handler?

    --> yes, If we test each POK individually, different ESM events will be fired

    when testing in parallel, the same ESM event is firing each time, regardless of which POK is being tested,

    when testing in parallel, the correct ESM event is firing (ie different POK ESM events are seen), but other POK ESM events are lost.

    --> it seems that, when testing in parallel, If one of the ESM events has been fired, the others are lost and only one can be fired

  • Hi,

    TI will review code path.

    In parallel could you please check if the setup/teardown logic of each individual test, when being run in "parallel", could be potentially impacting each other.

    Thanks,

    kb

  • SDL_POK_VDDSHV_WKUP_GEN_UV_ID,
    SDL_POK_VDDR_MCU_UV_ID,
    SDL_POK_VDD_CORE_UV_ID,
    SDL_POK_VDD_CPU_UV_ID,
    SDL_POK_VMON_EXT_UV_ID,
    SDL_POK_VDDR_CORE_UV_ID,
    SDL_POK_VDD_MCU_OV_ID,
    SDL_POK_VDDSHV_WKUP_GEN_OV_ID,
    SDL_POK_VDDR_MCU_OV_ID,
    SDL_POK_VDD_CORE_OV_ID,
    SDL_POK_VDD_CPU_OV_ID,
    SDL_POK_VMON_EXT_OV_ID,
    SDL_POK_VDDR_CORE_OV_ID,
    What are the normal Trim values for these routes? What should the Trim value be at the time of failure?

  • Summary of existing problems of POK:
    1, we carried out some tests: in the case of UV, the trim value is set to the lowest 0, read the corresponding status register, the result shows that the voltage value is abnormal, so we think that the status register can not be used normally now, there seems to be a similar problem before, link: e2e.ti.com/.../tda4vm-pok-under-voltage-fault h=e2e-sitesearch&keymatch=POK%252525252520TRIM#
    2, if we inject all UVs and OVs into the fault at the same time, the ESM interrupt will only respond to one of them and none of the rest
    3, Now the status register is not available, we can not determine what the normal trim value is, through what channel can we get the trim value?

  • Hi,

    Could you please post further details on (3), not clear on what concern is.

    Thanks,

    kb

  • Hi,

    Sorry, because we are going to test, we need the normal trim value and the wrong trim value for injection failure.

  • Hi,

    Regarding #2, when you run the tests in parallel, are you seeing the ESM error status bits being set for every condition?

    ESM interrupt will only respond to one of them

    By this statement, you mean that you are receiving a callback only for one event?

    Regards,

    Josiitaa

  • Hi,

    Yes, there is no problem with the ESM setup.
    We inject the fault in all of them, and only receive the callback for the first event that injected the fault.

  • Hi,

    The ESM aggregates events and errors from throughout the device to one location. When the faults have been injected, if the ESM has been setup correctly, you should be able to see the corresponding bits set in the ESM_RAW_j register, for all of the events that have been triggered.

    It is expected that you receive only one callback as there is only one central callback function for all the ESM events. In your case of triggering multiple events in parallel, you could modify the callback to read the ESM register to check for any pending interrupt bits that may be present, and attend to them on a priority basis configured by you.

    Regards,

    Josiitaa