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

Part Number: AM623

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

  • 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.

  • 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

  • Hello Anil,

    I have sent you the files via private message.

    Please let me know if there are any issues.

    Best regards,

    Michael

  • 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

  • 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

  • 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
  • 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.

  • 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