Mity CPU Platforms » MitySOM-AM62, MitySOM-AM62A, & MitySOM-AM62P

Hello,

We have a Critical Link development board with an AM62Px SOM (4GB). Currently, we are attempting to validate suspend/resume functionality in DeepSleep and MCU only modes.

Our procedure is as follows, using the prebuilt SDK 11.00.09.04 image hosted on the CL Wiki.

1. Allow the device to boot fully into a clean state
2. run the following commands on the target (in Linux)

echo 100000 > /sys/devices/system/cpu/cpu0/power/pm_qos_resume_latency_us # Per TISDK docs section 3.3.5.5
echo N > /sys/module/printk/parameters/console_suspend # Verbose output
echo mem > /sys/power/state # Enter MCU only mode

The resulting output (from linux) is:

[   54.953764] PM: suspend entry (deep)
[   54.977942] Filesystems sync: 0.020 seconds
[   54.989338] Freezing user space processes
[   54.995818] Freezing user space processes completed (elapsed 0.002 seconds)
[   55.002851] OOM killer disabled.
[   55.006092] Freezing remaining freezable tasks
[   55.011998] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)

At this point, the SOM+Devboard appears to enter a low power state, with an observed ~100mA decrease in current draw at the 12v supply.
The MCU R5F output also indicates this:

[IPC RPMSG ECHO] Next MCU mode is 1
[IPC RPMSG ECHO] Suspend request to MCU-only mode received
[IPC RPMSG ECHO] Press a single key on this terminal to resume the kernel from MCU only mode

At this point both serial connections (linux and MCU R5F) appear to become unresponsive. However, performing this sequence with an XDS110 debug
probe attached to the devboard reveals that the MCU R5F does not freeze, and indeed does respond to user input, but anything that occurs after
the suspend sequence can only be viewed with the XDS110.

Through the XDS110, we see the following (after entering a key on the unresponsive ttyUSB0 terminal):

[IPC RPMSG ECHO] Key pressed. Notifying DM to wakeup main domain

The main system never actually resumes, and the MCU R5F hangs beyond this point. After some time, the SoC resets
itself (possibly due to TIFS watchdog starving?) and the system reboots.

Using the XDS110 to probe the MCU R5F's registers reveals that the function call SOC_triggerMcuLpmWakeup() succeeds in writing the expected 0x00000011
to the CSL_MCU_CTRL_MMR_CFG0_IPC_SET0 register, however nothing indicates that the DM R5F exits WFI and begins the resume sequence. Is there another way
we could force the DM to wake up?

Is this an issue that CriticalLink has encountered previously, and does this mean that DeepSleep/MCU only LPM modes are unsupported on the AM62Px SOMs?
Are we missing a step or modification needed to resume from deep sleep? So far, we have not succeeded in getting the system to resume at all.

Thanks,
Connor