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.

TMDS64EVM: AM6442: MCU+SDK ESM0 Interrupts

Part Number: TMDS64EVM
Other Parts Discussed in Thread: AM6442

Using the MCU+SDK library provided by your company,
interrupts generated in the AM6442's ESM0 (main domain) are passed to MCU_ESM0 (MCU domain), and the M core processes the interrupt handler.
A problem has been found in the library used at that time.
1. Our Question and Request
- Are the source code error and workaround we describe below correct?
- We need an official version with the error corrected. When will you be able to issue it?
2. What We Want to Do
- We want to create a handler that uses the M core to handle interrupts generated in ESM0 (main domain) (for example, DED interrupts during DDRSDRAM reads).
- We want to distinguish interrupts from ESM0 (main domain) from interrupts from MCU_ESM0 (MCU domain) and process them differently.
3. Our Test Environment
- We will use your evaluation board, TMDS64GSEVM (AM6442).
- For the M core software, we are using your provided MCU+SDK 11.00.00.15.
- For the A core software, we are using your provided PROCESSOR-SDK-LINUX-AM64X 09_00_00_03.
4. Unexpected Phenomenon
- The user-created handler function is being called twice, but the value of the esmInstType argument in the first handler function appears to be incorrect.
  It should be 2 (SDL_ESM_INST_MAIN_ESM0), but it is being returned as 1 (SDL_ESM_INST_MCU_ESM0).
5. Suspected Source Code Error
- Library: ${MCU_PLUS_SDK_PATH}/source/sdl/lib/sdl.am64x.m4f.ti-arm-clang.debug.lib
- Source File: ${MCU_PLUS_SDK_PATH}/source/sdl/esm/v0/v0_0/sdl_esm_priv.c
- Function: void SDL_ESM_loInterruptHandler (void *arg)
- Description: Line 313
  SDL_ESM_interruptHandler((uint32_t)base_addr, ESM_INTR_PRIORITY_LEVEL_LOW, arg);
6. Our Hypothesis
- We believe this is a simple error in the source code.
- Correction Example: We believe it should be written as in line 270.
  SDL_ESM_interruptHandler((uint32_t)base_addr, ESM_INTR_PRIORITY_LEVEL_LOW, (void *)esm_inst);
7. Our Current Workaround
- Currently, MCU_ESM0 interrupts are unnecessary.
  In the future, MCU_ESM0 interrupts will also be handled.
- Therefore, the first call to the user-defined handler is assumed to be an indirect notification from ESM0.
  The domain in which the interrupt occurred, esmInstType, is invalid information and is ignored.
  The interrupt source, intSrc, is used because it indicates the interrupt source within ESM0.
- The second call to the user-defined handler is ignored.

  • Hello ,

    I am routing your query to ESM experts; however, you may get delayed replies due to the year-end holidays.

    Regards,

    Anil.

  • Hi Anil,

    Happy New Year. Since we are now in the new year, it would be appreciated if we can receive your response soon.

    Thanks and regards,

    Hideaki

  • Hello Anli,

    I hope this message finds you well. we would like to kindly follow up regarding the matter above. We have resumed work as of January 5 and are currently waiting for your response.

    Thank you for your attention, and we look forward to your reply.

    Best regards,
    Goki

  • Hello Goki-san,

    Apologies for the delay here. The thread initially got wrongly assigned and then got lost in the new year break. 

    I understand the issue you are seeing and I agree that it seems to be a simple error in the SDL_ESM_loInterruptHandler API. The change you made makes sense and I will create a JIRA internally to get it fixed in the next release of MCU+SDK.

    Regards,

    Nihar Potturu

  • Hello Nihar-san,

    Thank you for your reply.

    The change you made makes sense and I will create a JIRA internally to get it fixed in the next release of MCU+SDK.

    When will the next release of MCU+SDK be released?

    - Currently, MCU_ESM0 interrupts are unnecessary.
      In the future, MCU_ESM0 interrupts will also be handled.
    - Therefore, the first call to the user-defined handler is assumed to be an indirect notification from ESM0.
      The domain in which the interrupt occurred, esmInstType, is invalid information and is ignored.
      The interrupt source, intSrc, is used because it indicates the interrupt source within ESM0.
    - The second call to the user-defined handler is ignored.

    We have already recognized that the workaround we presented in our previous email is insufficient.
    The reason is that if two soft errors occur almost simultaneously due to Core A reading two locations, the rule that the user-defined handler is called twice for each soft error is incorrect.

    So we would appreciate it if you would release the fixed version.

    Best regards,
    Goki

  • Hi Goki-san,

    This fix will be included in the 12.0 release tentatively scheduled for the end of March 2026.

    Regards,

    Nihar Potturu

  • Hello Nihar-san,

    Thank you for your reply. Appologize for delayed resoponse.

    We understood.

    Please close this matter.

    Best regards,
    Goki