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.

AM625: AM62x MCU Only mode wrong Host State

Part Number: AM625

Hello,

I have tried and succesfully set my device into MCU only mode before. However, as of late I have been receiving an invalid host state (0x95). If my understanding is correct I should either get a state of 1 or 0 depending on deep sleep or MCU only. Or if the state is wrong I should receive 0xFF.

I have reverted back to the UART example UART MCU ONLY. Also here I receive the host state value 0x95 (149).

I enter MCU only with the following commands:

echo 100000 > /sys/devices/system/cpu/cpu0/power/pm_qos_resume_latency_us
echo mem > /sys/power/state

M4F output:
[LPM UART WAKEUP] Example Application Started...
[LPM UART WAKEUP] Remote Core waiting for messages at end point 13 ... !!!
[LPM UART WAKEUP] Remote Core waiting for messages at end point 14 ... !!!
[LPM UART WAKEUP] Next MCU mode is 149 

What could be going wrong?

With kind regards,

Job Meulenbeld



Additional information:

Processor SDK: 11.00.09

MCU SDK: 11.01.00.16

root@verdin-am62-15599560:~# cat /proc/version
Linux version 6.6.129-7.2.0-devel (oe-user@oe-host) (aarch64-tdx-linux-gcc (GCC) 13.3.0, GNU ld (GNU Binutils) 2.42.0.20240723) #1 SMP PREEMPT Wed Apr  1 11:47:27 UTC 2026

root@verdin-am62-15599560:~# cat /etc/buildinfo 2>/dev/null
-----------------------
Build Configuration:  |
-----------------------
DISTRO = tdx-xwayland
DISTRO_VERSION = 7.2.0-devel-20260416105507+build.0
-----------------------
Layer Revisions:      |
-----------------------
meta-toradex-nxp  = HEAD:2a49ef90cbcce9d8a26e1178aefe10a04065c8b2
meta-freescale    = HEAD:7b6b02d24771690d6a65ec6a1a5bca26d0537945
meta-freescale-3rdparty = HEAD:1dfc65dd2006b51d156be5bcda0e3c72c936ad0a
meta-toradex-ti   = HEAD:dbf615d3235f5d83ce7262b57a4f38e133a9b7c8
meta-arm-toolchain = HEAD:3cadb81ffaa9f03b92e302843cb22a9cd41df34b
meta-arm          = HEAD:3cadb81ffaa9f03b92e302843cb22a9cd41df34b
meta-ti-bsp       = HEAD:5385fb9231e8d48c30ddd965c4cc623a1f004e3e
meta-ti-extras    = HEAD:5385fb9231e8d48c30ddd965c4cc623a1f004e3e
meta-toradex-bsp-common = HEAD:354aebd1796c4ad5eaeee52b8dc768fcc2dad32d
meta-oe           = HEAD:67ad83dd7c2485dae0c90eac345007af6195b84d
meta-filesystems  = HEAD:67ad83dd7c2485dae0c90eac345007af6195b84d
meta-networking   = HEAD:67ad83dd7c2485dae0c90eac345007af6195b84d
meta-multimedia   = HEAD:67ad83dd7c2485dae0c90eac345007af6195b84d
meta-python       = HEAD:67ad83dd7c2485dae0c90eac345007af6195b84d
meta-freescale-distro = HEAD:b9d6a5d9931922558046d230c1f5f4ef6ee72345
meta-toradex-demos = HEAD:b5f15cefa15f1c9ef6aad6f594cb168dd531f3ec
meta-qt5          = HEAD:eb828418264a49b8d00035cb3d7b12fcea3be801
meta-tpm          = HEAD:bc865c5276c2ab4031229916e8d7c20148dfbac3
meta-toradex-distro = HEAD:9b0057cde6f145cbf820db366caebcdf2e435424
meta-poky         = HEAD:afa9ec665d1197d9289a86d30389be0cc037d739
meta              = HEAD:a720df7ad77af1f8b1c00a211c88537e5f23edbc
meta-spark        = main:cf908be824453f79ed4500724317ebeb441086fb
meta-rauc         = HEAD:d63878f20eba7a85ecf53566e7a3377e78bb46ac
meta-lts-mixins   = HEAD:c19b6da5a3afd3c892b3b1b44983e993ac6d5308

root@verdin-am62-15599560:~# cat /etc/os-release
ID=tdx-xwayland
NAME="TDX Wayland with XWayland"
VERSION="7.2.0-devel-20251204100250+build.0 (scarthgap)"
VERSION_ID=7.2.0-devel-20251204100250-build.0
VERSION_CODENAME="scarthgap"
PRETTY_NAME="TDX Wayland with XWayland 7.2.0-devel-20251204100250+build.0 (scarthgap)"
CPE_NAME="cpe:/o:openembedded:tdx-xwayland:7.2.0-devel-20251204100250+build.0"
root@verdin-am62-15599560:~# cat /etc/version
2018030912345

  • Hello Job,

    The versions you mentioned don't line up.

    Linux SDK 11.0 uses Linux kernel 6.12.17: https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/11_00_09_04/exports/docs/devices/AM62X/linux/Release_Specific_Release_Notes.html#release-11-00-09-04

    Then you mentioned you are using MCU+ SDK: 11.01.

    Please be aware that we don't test nor recommend mixing and matching SDK components from different versions. If you choose to do this, then there's very limited support that TI can provide. We recommend using the latest SDK possible with all components from the same SDK version.

    Since Mode 149 is an invalid mode (I would be expecting a 1/0 since the MCU core needs to be either on or off), it should have hit the default case statement and the suspend would be canceled: https://github.com/TexasInstruments/mcupsdk-core-k3/blob/k3_main/examples/lpm/lpm_mcu_uart_wakeup/lpm_mcu_uart_wakeup.c#L435

    Does the logs indicate that the suspend was canceled or is it just empty after 'Next MCU mode' is printed?

    Best Regards,

    Anshu 

  • We Thought it would be something like a processor / mcu SDK miss-match,

    But we had it working on this project previously.
    We are using Yocto Scarthgap hence that is why the processor SDK version is what it is.
    the yocto release that we use is 'scarthgap' because that was the latest long term support release when we started this project.

    We expected it to return from suspend as indicated by the default case, but rather then that what happened was that the board seems to hang and after a few minutes the watchdog seems to be triggered, since the board resets and then subsequently boots rather than returning from suspend and dropping me in the prompt/console again.

    If I understand the info on the pages linked by you correctly,
    Then for Processor SDK  11.00.09 we need to use MCU SDK version 10.01.00.
    10.01.00 is the version for the MCU SDK linked to on the Processor SDK pages for 11.00.09

    This is how I checked in yocto which Processor SDK Version I had:

    developer@sparkDev:~/System/SparkSystem/build/deploy/sdk$ bitbake -e virtual/kernel | grep "^PV"
    PV="6.6.84+git"
    developer@sparkDev:~/System/SparkSystem/build/deploy/sdk$ bitbake -e ti-dm-fw | grep "^PV\|^SRC_URI"
    PV="11.00.09"
    SRC_URI="git://git.ti.com/git/processor-firmware/ti-linux-firmware.git;protocol=https;branch=ti-linux-firmware"



  • Hello,

    Are you pulling directly from upstream? There are a few remote proc drivers issues from the upstream version which could explain whats going on with the host version. Can you try whats included in our SDK? 

    For the version matching, the first two sections of the version number should match. For example, Linux SDK version 11.00.09.04 and MCU+ SDK version 11.00.00.16 go together.

    Best Regards,

    Anshu

  • So we found a Reason it doesn't work,

    We are working with toradex SOMs and it turns out our code works on one and not the other.
    Where it works it gives the correct mode and returns from MCU only mode, while the non working gives 149 and either hangs or restarts due to the watchdog.

    We compared both modules they have The Same Processor chip.
    So it seems to be a hardware issue more then that it is software.

    here is the topic we made on the toradex forums:
    https://community.toradex.com/t/same-som-mcu-only-problem/30418/5

    From what I gather both SOMs have the same Processor, the markings on the chip don't differ.
    Do you have any ideas what could be the problem then?
    Could it be some kind of voltage issue, or some other problem?

  • We resolved the issue,

    Turns out the bootloader was to blame, we had an old u-boot version which was loading an old DM WKUP R5F firmware version, and due to this we had the communication issues, even when the Processor SDK version and MCU+ SDK version matched. 

  • Thanks Robert for the update. This thread will be closed and any follow up questions, make a new thread. 

    Best Regards,

    Anshu