• State
  • Locked Locked
  • Replies 21 replies
  • Subscribers 100 subscribers
  • Views 549 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.

AM623: M4F WWDT Callback Not Triggered on First Run, Immediate Callback on Second Run

Michael V
Intellectual 556 points

Part Number: AM623
Other Parts Discussed in Thread: AM625

We are testing the M4F Windowed Watchdog Timer (WWDT) on AM623 by integrating the M4F WDT sample code into the IPC example provided in the MCU+ SDK (IPC communication between Cortex‑A53/Linux and Cortex‑M4F).
 
Observed behavior:
  • After CPU boot, on the first program load and execution of the M4F firmware, the WWDT timeout occurs, but the timeout handling callback is not executed.
  • After stopping, resetting, and reloading the M4F firmware, on the second execution, the WWDT timeout callback is executed immediately after start.
 
Register Observations
RTI register
  • CFG_WDSTATUS
    • 1st run: DWWD (bit5) = 0
    • 2nd run: DWWD (bit5) = 1
ESM registers
1st run
  • CFG_STS (0x04100044) = 1
  • CFG_HI (0x0410002C) = 0x00000000
  • CFG_GRP_ERR_GRP_RAW_J_J / STS_J_J (0x04100440 / 0x04100444) = 0x00000000
2nd run
  • CFG_STS = 0
  • CFG_HI = 0x00000004
  • CFG_GRP_ERR_GRP_RAW_J_J / STS_J_J = 0x00200000
Based on these results, it appears that RTI → ESM notification is occurring, and that the ESM state differs between the first and second firmware execution.
Question: Could you please advise on possible causes for this behavior, particularly whether RTI/ESM status persistence or initialization differences between M4F firmware reloads (via Linux remoteproc) could explain the immediate callback execution on the second run?
 
Environment
  • Device: AM623
  • Cortex‑A53: Linux running
  • Processor SDK (Linux): 11.00.09.04 (2025/04/16)
M4F WWDT configuration
  • Timeout: 5 seconds
  • WindowSize: 100%
  • Reaction: GENERATE_NMI

Thank you for your assistance.

Best regards,

Michael

  • 0
    TI__Guru 54798 points

    Hello Michael,

    Can you please confirm whether you used MCU ESM or MAIN ESM in the M4F application?

    Is the same ESM enabled in the Linux DTS file as well?

    Is it possible to share the M4F core IPC example with WDT integration code so I can look at the software changes and get back to you easily?

    Regards,

    Anil.

  • 0 in reply to Swargam Anil
    Intellectual 556 points

    Hello Anil,

    My understanding is that the MCU ESM is being used, and it is also enabled in the Linux DTS file.

    I will send you the DTS file as well as a portion of the WDT integration code via private message. 

    Please let me know if anything sticks out to you.

    Thank you, and I look forward to your response.

    Best regards,

    Michael

  • 0 in reply to Michael V
    Intellectual 556 points

    Hello Anil,

    I have sent you the files via private message.

    Please let me know if there are any issues.

    Best regards,

    Michael

  • 0 in reply to Swargam Anil
    Mastermind 7200 points

    Hi Anil,

    I'm Michael's colleague. I'm contacting you because he's temporarily out of the office.
    sorry for rush you. Is there any update? Even just telling me the situation would be helpful.
    If it's difficult to answer in the thread, private chat is also fine.

    Best regards,
    O.H

  • 0 in reply to O.H
    Intellectual 556 points

    Hello Anil,

    I'm back in the office, so I will be taking over again.

    Have you had a chance to review what I provided via private message?

    Please let me know if you need any additional information.

    Thank you,
    Michael

  • 0 in reply to Michael V
    Intellectual 556 points
    Hello Anil,

    I understand that things may be busy on your end; however, we have been waiting for nearly a month for an update on this issue.

    Could you please share the current status?

    Also, let me know if any additional information is required from our side.

    Best regards, Michael
  • 0 in reply to Michael V
    TI__Guru 54798 points

    Hello Michael,

    Can you please confirm if this field is disabled or enabled in the device tree in the kernel?

    I could not find the device status of MCU ESM in the file you shared.

    &mcu_esm {
    status = "disabled";
    };

    Regards,

    Anil.

  • 0 in reply to Swargam Anil
    Intellectual 556 points

    Hello Anil

    I could not find any configuration where this node is set to "disabled", so it should be enabled. It also appears to be recognized correctly in Linux.

    For reference, I have shared the full DTS file via private message.

    Please let me know if you need any additional information. Thank you.

    Best regards,

    Michael

  • 0 in reply to Michael V
    Intellectual 556 points

    Hello Anil,

    Please let me know how things are progressing.

    Thank you,

    Michael

  • 0 in reply to Michael V
    TI__Guru 54798 points

    Hello Michael,


    Please follow the steps below to disable the MCU ESM module and perform testing:

    In the MCU device tree source (DTS) file, the following MCU ESM module is currently enabled. Please comment out these lines:

    /* mcu_esm: esm@4100000 {
    bootph-pre-ram;
    compatible = "ti,j721e-esm";
    reg = <0x00 0x4100000 0x00 0x1000>;
    /* Interrupt sources: esm0_cfg, esm0_hi, esm0_low, mrti0 */
    ti,esm-pins = <0>, <1>, <2>, <85>;
    }; */

    And add the following to disable MCU ESM:

    &mcu_esm {
    status = "disabled";
    };

    Next Steps :
    1. Make the above changes to your DTS file
    2. Rebuild the device tree
    3. Flash the updated image to your device
    4. Perform the testing
    5. Share the test results.

    Regards,

    Anil.

  • 0 in reply to Swargam Anil
    Intellectual 556 points

    Hello Anil,

    Following the steps you provided, the module was commented out and MCU ESM disable code was added, but when building the device tree an error occurred. 

    Therefore, the two following builds were attempted:

    1. mcu_esm module was commented out, and device tree was built
    2. status="disabled" was added to the mcu_esm module and built

    In each case listed above, the originally observed behavior remains unchanged.

    I will provide you each DTS file used in 1. and 2. above for reference.

    Please let me know if you have any ideas or if you need additional info about the error occurring when trying build the device tree after making both of the changes to the DTS file that you recommended.

    Thank you,

    Michael

  • 0 in reply to Michael V
    TI__Guru 54798 points

    Hello Michael,

    What error are you facing after adding the status disable configuration?

    @Bin, can you please help here? The customer needs to ensure that the MCU ESM is enabled on the MCU core side rather than the Linux side.
    They have shared the DTS files with MCU_ESM configuration settings.

    I asked them to add the MCU_ESM disable configuration, but later they reported errors.

    Can you please help?

    They have shared the DTS files in the private chat, and I can share them with you .

    Michael, FYI,  I have routed your query to Linux expert .

    Regards,

    Anil.

  • 0 in reply to Swargam Anil
    TI__Guru**** 180876 points

    To disable MCU_ESM, you need to apply the follow DTS patch to the U-Boot (not kernel).

    diff --git a/arch/arm/dts/k3-am625-r5-sk.dts b/arch/arm/dts/k3-am625-r5-sk.dts
    index 513062c4503b..a1b6ebce363f 100644
    --- a/arch/arm/dts/k3-am625-r5-sk.dts                                  
    +++ b/arch/arm/dts/k3-am625-r5-sk.dts                                  
    @@ -15,3 +15,7 @@                                  
            ti,sci = <&dm_tifs>;                                   
            bootph-all;                                  
     };
    +
    +&mcu_esm {                                  
    +       status = "disabled";                                   
    +};

    Then you will see the following message in U-Boot console log, but it can be ignored, since we disabled mcu_esm.

    esm mcu init failed: -19

    After the mcu_esm is disabled, any main domain esm event won't trigger esm reset. If you still need the main domain esm events to trigger esm reset, please apply the following U-Boot patch too.

    diff --git a/arch/arm/mach-k3/am62x/am625_init.c b/arch/arm/mach-k3/am62x/am625_init.c
    index e821de1e1342..bf4201866810 100644
    --- a/arch/arm/mach-k3/am62x/am625_init.c
    +++ b/arch/arm/mach-k3/am62x/am625_init.c
    @@ -100,13 +100,14 @@ static void ctrl_mmr_unlock(void)
            mmr_unlock(PADCFG_MMR1_BASE, 1);
     }
                                                                               
    +#define CTRLMMR_WKUP_RST_CTRL  (WKUP_CTRL_MMR0_BASE + 0x18170)
     static __maybe_unused void enable_mcu_esm_reset(void)
     {                           
            /* Set CTRLMMR_MCU_RST_CTRL:MCU_ESM_ERROR_RST_EN_Z  to '0' (low active) */
    -       u32 stat = readl(CTRLMMR_MCU_RST_CTRL);
    +       u32 stat = readl(CTRLMMR_WKUP_RST_CTRL);

            stat &= RST_CTRL_ESM_ERROR_RST_EN_Z_MASK;
    -       writel(stat, CTRLMMR_MCU_RST_CTRL);
    +       writel(stat, CTRLMMR_WKUP_RST_CTRL);
     }

  • 0 in reply to Bin Liu
    Intellectual 556 points

    Hi Bin, Anil

    Thank you for your assistance.

    The recommended patch disabling mcu_esm within the U‑Boot DTS was applied; however, the originally observed behavior remains unchanged.

    For reference, I will provide the DTS file converted from the DTB used at runtime via private message.

    Please let me know if you notice any issues or have further recommendations on how to proceed.

    Best regards,

    Michael

  • 0 in reply to Michael V
    Intellectual 556 points

    Hello, 

    Were you able to check the file I sent over? 

    Please let me know if you have any feedback.

    Thank you!

    Michael

  • 0 in reply to Michael V
    Intellectual 556 points

    Hello,

    Could you please provide an update on the current status of this inquiry?

    Thank you,

    Michael

  • 0 in reply to Michael V
    TI__Guru 54798 points

    Hello Michael,

    Now the MCU ESM is initialized in the M4F core and not init in the A53 core Linux.

    When the WDT timeout occurs, the SoC should either get reset or, if you register a callback, the callback should trigger.

    If this is not happening, based on the ESM registers above still , somehow the ESM registers are all zeros and the WDT status is also zero which means that WDT and ESM is not initialized.. 

    Can you confirm whether ESM and WDT initialization happened properly on the first run?

    Can you please share the M4F WDT code so I can review it on my side?

    Regards,

    Anil.

  • 0 in reply to Swargam Anil
    Intellectual 556 points

    Hello Anil,

    Thank you for the respones.

    I will send you the entire ipc_wdt project via private message. 

    As for the ESM and WDT initialization, I will confirm operation and get back to you shortly.

    Thank you for your continued support.

    Best regards,

    Michael

  • 0 in reply to Michael V
    Intellectual 556 points

    Hello Anil,

    Thank you for your continued support.

    Verification and initialization are being conducted based on the AM62x Technical Reference Manual as well as the two threads below:

    In addition, I would like to ask the following:

    1. Regarding the initialization procedure of WDT/ESM, are there any additional references or resources that you could recommend?

    2. We believe that the second execution is working correctly (corresponding to register states (d) and (e)). I will share the following register information via private chat:

      1. ESM register values immediately after CPU startup (before execution)
      2. RTI register values after the first WDT timeout period has elapsed
      3. ESM register values after the first WDT timeout period has elapsed
      4. RTI register values immediately after the second program load and start
      5. ESM register values immediately after the second program load and start

        As mentioned above, the state observed during the second execution (d/e) is not reached during the first program load (b/c).

        Additionally, if there are any reference examples of expected register states for RTI/ESM under correct operation, I would appreciate it if you could share them.

    3. We believe that initialization is implemented correctly, since the expected behavior is observed after reloading and running the program a second time.

      Therefore, we would appreciate your insight into possible reasons why this correct state is not achieved during the first execution.

    Thank you for your support.

    Best regards,

    Michael

  • 0 in reply to Michael V
    TI__Guru 54798 points

    Hello Michael,

    I can provide reply by today for your above queries .

    Regards,

    Anil.

  • 0 in reply to Swargam Anil
    TI__Guru 54798 points

    Hello Michael,

    You are currently only registering the ESM interrupt instead of resetting the SOC.

    Because of this, you need to disable the ESM interrupt inside the ESM callback function to prepare for the next trigger event, which is currently missing from your implementation.

    Required Code Changes:

    Change 1: Clear all bits in the errorpinBitmap inside the ESM callback function as shown below:

    .errorpinBitmap = {0x00000000u, 0x00000000u, 0x00000000u, 0x00000000u},

    Change 2: Disable the Interrupt source in the ESM callback:

    IntrDisable(intSrc);

    Change 3: To trigger an SoC reset instead of just registering an interrupt, you must clear the warm reset control bit by modifying the MMR registers:
     
      /* Reset Ctrl belongs to partition 6 of the CTRL MMR */
         uint32_t     rstPartition = 6U;
         uint32_t    volatile * ctrl_addr

    /* Unlock CONTROL MMR registers */
    SOC_controlModuleUnlockMMR(SOC_DOMAIN_ID_WKUP, rstPartition);

    ctrl_addr = (volatile uint32_t *)(0x43018170);
    *ctrl_addr &= (~(1 << 17));

    /* Lock CONTROL MMR registers */
    SOC_controlModuleLockMMR(SOC_DOMAIN_ID_WKUP, rstPartition);

    Please verify the behavior using the following two test cases:

    Test Case 1 (SoC Reset): Incorporate Change 1 and Change 3. Compile the application and confirm the test results. Every time the WDT (Watchdog Timer) expires, the SoC should perform a hardware reset.

    Test Case 2 (Interrupt Trigger): Incorporate Change 1 and Change 2. Compile the application and confirm the test results. When the WDT expires, the ESM interrupt should triggers.

    Recommendation: My strong suggestion is to proceed with the automatic SoC Reset (Test Case 1) rather than requiring the user to manually trigger a reset by controlling the warm reset bits.

    Please run these tests and share your results.
    Regards,
    Anil.