AM625: M4F cannot enter into ESM interrupt

I am trying to add some debug information, such as reading back the ESM_getStaticRegisters and doing the comparison between EVM and our project.

The ESM_getStaticRegisters are the same. Which other registers can I try to compare?

Hello WZ,

Please try the example below and confirm whether the ESM interrupt is triggered or not.

And, one more point: the ESM always needs to be controlled at one point and not from multiple cores.

If the WKUP_ESM is initially done on multiple cores, like Linux and M4F cores, then there might be a chance the WKUP_ESM bits over writeen by different cores.

Hence, the M4F RTI interrupt is not triggered.

Please let me know the test results.

Regards,

Anil.

/cfs-file/__key/communityserver-discussions-components-files/791/UC2.zip

I tried the example that you provided with the EVM board and our project board.  It cannot get into the ESM callback, and after 20 seconds, I paused the debugger; it still waits for 

isrFlag.

You changed some code, so what is the expected result?

Should it get into the ESM interrupt? 

Last week, I also tried to save the memory and compare the values between the EVM board and our project board.

I used the CCS to connect the M4F core, perform the core reset, and load the program. Use the breakpoint to stop the program in line 285, then save the memory. (Due to the M4F core and RAT, I saved the memory from 0x84100000 for WKUP_ESM0 instance) 

The whole values of WKUP_ESM0 between the EVM board and our project board are the same.

Dear Customer，

   There are two ESM instance In AM62x. One is Main ESM, such as main RTI instance RTI0 RTI1 RTI2 RTI3 RTI15 ESM event will trigger to this instance.  the other is WKUP_ESM0. such as MCU_RTI0 is connected. 

    To mcu_m4f, we can get the interrupt mapping info by file "sdlr_intr_mcu_m4fss0_core0.h". 

#define SDLR_MCU_M4FSS0_CORE0_NVIC_WKUP_ESM0_ESM_INT_CFG_LVL_0 (11U)
#define SDLR_MCU_M4FSS0_CORE0_NVIC_WKUP_ESM0_ESM_INT_HI_LVL_0 (12U)
#define SDLR_MCU_M4FSS0_CORE0_NVIC_WKUP_ESM0_ESM_INT_LOW_LVL_0 (13U)

    From the example, it seems you hope to route main ESM event RTIx to MCU domain? 

     If yes, you need to monitor the EVENT_ESM0_ESM_INT_XX by register 0x4100400 to check the ESM event pass to WKUP ESM or not. if the bit is zero, please check the address 0x4204A0. And feedback here. 

     If the ESM event triggered, please check the M4F NVIC register status. Thanks.

Linjun

uint32_t RTI_devices[RTI_NUM_DEVICES] =
{
TISCI_DEV_MCU_RTI0,
};

No, I just used the MCU_RTI0 in the MCU domain.

Hello WZ,

Please try the change below.

If this still does not work, I can join for a debug call tomorrow after 11AM IST.

The RTI MCU Interrupt is routed to ESM at the 85th bit position.

So, we need to set the 85th bit.

After updating this bit, compile the code, load an example and see if it works or not.

Regards,

Anil.

As I mentioned above, we use the SPL bootflow.

We conducted one test as follows.

Use the AM62B-P1 EVM board with SD boot. All the software is from TI.

https://dr-download.ti.com/software-development/software-development-kit-sdk/MD-PvdSyIiioq/11.01.05.03/tisdk-default-image-am62xx-evm-11.01.05.03.rootfs.wic.xz

When entering the U-Boot, manually load the M4F out file.(sdl_rti_example_uc2_am62x-sk_m4fss0-0_nortos_ti-arm-clang.out)

In this case, the M4F ESM interrupt also cannot enter; it resets. 

So, I guess that U-Boot may do something to block the M4F ESM interrupt. But I do not know how to check.

Maybe to check M4F NVIC registers?

Hello WZ,

    step1:  Check the register 0x4100440  bit21 is 1 or not. if not 1 ,it means the mcu RTI haven't send ESM event.

    step2:  Check NVIC register

                 There are two type ESM interrupt to R4F,  NO.12  is for high priority ESM interrupt , No.13 is for Low priority interrupt. 

                 Please dump the m4F TRM from ARM website, then check the chapter 6.21 , you can find NVIC register mapping info.

                 To interrupt NO. 12, the register 0xE000E100 bit12 should be set to 1.

                                                  the register 0xE000E300 bit12 will be set to 1, if interrupt come. 

             Feedback the status, we will support you in advance.

    Thanks.

Linjun          

I did the change. 

The result is the same as the posted.

It works well on AM62B-P1 EVM board with the bootflow of the secondary bootloader (SBL).AM62x MCU+ SDK: Understanding the bootflow and bootloaders

But it does not enter the M4F ESM interrupt and happens to reset on our project board with 3.1.1.4. Bootflow — Processor SDK AM62x Documentation

Hello WZ,

Can you please confirm the two registers' values below in SBL and SPL boot flow after the M4F runs and the MCURTI start ?

And, also confirms that the MCU_RTI ESM is enabled or disabled in the Linux dts file in your SPL boot flow.

I feel that the Linux core is overwriting these ESM registers because this M4F core is not able to trigger an ESM interrupt.

Here J = 2 ..

Regards,
Anil.

WKUP_ESM0_Register_Value.zipI did the comparison before, in SBL and SPL boot flow after the M4F runs and the MCURTI start.

The whole WKUP_ESM0 register values are the same.

Swargam Anil said:

And, also confirms that the MCU_RTI ESM is enabled or disabled in the Linux dts file in your SPL boot flow.

I am not familiar with the TI Linux development process and related files.  We use the default resources from the TI side.

Could you please let me know where to check that the MCU_RTI ESM is enabled or disabled in the Linux dts file in the default SPL boot flow?

Or can this MCU_RTI ESM be enabled or disabled, checked in the register value in the M4F core?

Hello Linjun,

W Z said:

In this case, the M4F ESM interrupt also cannot enter; it resets.

In this sdl_rti_example_uc2_am62x-sk_m4fss0-0_nortos_ti-arm-clang example, when it cannot enter the M4F ESM interrupt, it resets.

I cannot save the memory or check the register values after the RTI watchdog timeout.

It is quite clear now.  When loading and executing the same M4F sdl_rti_example_uc2_am62x-sk_m4fss0-0_nortos_ti-arm-clang.out, it shows different behaviors.

Case 1: It seems that when booting with SBL flow, somewhere invokes the function to enable WKUP_ESM0 interrupt, but when booting with SPL flow, it does not enable this.

Case 2: When booting with SPL flow, it does some configuration that disables WKUP_ESM0 interrupt.

But I did not find any related information about enabling or disabling the WKUP_ESM0 interrupt. I do not know if this exists.

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/3704.k3_2D00_am625_2D00_sk.dtb

Path : /boot/dtb/ti/.

Regards,

Nihar Potturu

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/2844.k3_2D00_am625_2D00_sk.dtb

Hello WZ,

I have verified the SD boot flow at my side, and I observed that the RTI interrupt is not getting triggered, and instead, the SoC is going into a reset.
I noticed the same behavior during our call today on your setup as well.

To generate the interrupt correctly (instead of a reset), the following two steps need to be followed:
1. Disable the MCS ESM instance in the DTS file (as already shared by Nihar).
2. Disable the reset trigger bit in the CTRL MMR register  after the watchdog timer expires.

After applying the above two changes, I was able to see that the WDT interrupt is successfully triggered on the M4F core and the SoC no longer resets immediately.

Can you please apply the same changes on your side and share your test results/logs for confirmation?

    uint32_t     rstPartition = 6U,baseAddr;
    baseAddr = (uint32_t) AddrTranslateP_getLocalAddr(CSL_MCU_CTRL_MMR0_CFG0_BASE);

    SOC_controlModuleUnlockMMR(SOC_DOMAIN_ID_MCU, rstPartition);

    CSL_REG32_FINS(baseAddr + CSL_MCU_CTRL_MMR_CFG0_RST_CTRL,
                   MCU_CTRL_MMR_CFG0_RST_CTRL_MCU_ESM_ERROR_RST_EN_Z,
                    0x1U);

    SOC_controlModuleLockMMR(SOC_DOMAIN_ID_MCU, rstPartition);

Regards,

Anil.

Follow your suggested steps, and we can get into the ESM callback now.

But we still have the question. Why? In the SPL bootflow, we need to disable the reset trigger bit in the CTRL MMR register.

Is the reset trigger bit in the CTRL MMR register disabled in the default SBL bootflow?