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: UART not transmitting during MCU Only mode

Part Number: AM625

Dear support,

I am developing an application on the M4 core that requires me to use UART during MCU Only mode. I noticed that during MCU Only, the MCU_UART0 is not transmitting. I am using an FTDI to capture my UART data.

What I notice is that I can receive characters when both the CPU and M4 are awake. When I put the CPU in MCU Only mode using the commands below, the characters are no longer printed. But when the CPU wakes up from MCU Only mode, the characters resume printing. I also checked with a loop counter to see if the M4 continues to run and it increments during sleep.

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

Could it be a device tree setting not being right? Or perhaps is the MCU UART peripheral not correctly configured?

With kind regards,

Job Meulenbeld


Test code in a separate task:

static void uart_print_char(char c)
{
    UART_Transaction transaction;

    UART_Transaction_init(&transaction);
    transaction.buf   = &c;
    transaction.count = 1U;

    UART_write(gUartHandle[CONFIG_UART0], &transaction);
}

static void Test_Task(void *args){
    while (1)
    {
        GPIO_pinWriteLow(baseAddr, CONFIG_GPIO0_PIN);
        uart_print_char('X');
        vTaskDelay(pdMS_TO_TICKS(1000));

        GPIO_pinWriteHigh(baseAddr, CONFIG_GPIO0_PIN);
        uart_print_char('Y');
        vTaskDelay(pdMS_TO_TICKS(1000));

        gToggleCount++;
    }
}

image.png

  • Hi Job,

    Are you testing this on a TI EVM or custom hardware? If you are using custom hardware, do also see this issue on a TI EVM?

    Can you share your device tree source as well?

    Best Regards,

    Anshu

  • Hi Anshu

    I am working on custom hardware (the Toradex Verdin AM62) and do not have a TI EVM to verify the behavior unfortunately. The relevant parts of my device tree file with respects to the M4 and MCU_UART0 are shown below. Do you perhaps have any references or MCU+ SDK examples that are known to work during MCU Only mode so that I can compare it to our implementation?

    With kind regards,

    Job

    // more /proc/device-tree/bus\@f0000/bus\@4000000/serial\@4a00000/status
    &mcu_uart0 {
    	status = "disabled";
    };
    
    &mcu_m4fss {
    	compatible = "ti,am64-m4fss";
    	mboxes = <&mailbox0_cluster0 &mbox_m4_0>;
    	mbox-names = "tx", "rx";
    	memory-region = <&mcu_m4fss_dma_memory_region>,
    			<&mcu_m4fss_memory_region>;
    	firmware-name = "am62-mcu-m4f0_0-fw";
    	wakeup-source;
    	status = "okay";
    };

  • Hi Anshu,

    After some more digging I have found multiple threads that report the exact same issue that I am facing:
    Thread1

    Thread2

    They both indicate the same behavior: Printing using MCU_UART0 works during normal operation, when entering MCU Only mode the printing stops.

    I am currently working with the following version: MCU+ SDK Version 11.01.00.16.

    Unfortunately I haven't seen a response to these threads that resolve this issue. Do you perhaps have more information about this situation?

  • Hello Job,

    Looks like there were no follow up discussions on those threads. 

    We don't have any additional reference examples besides whats included in the MCU+ SDK. 

    Let me contact the development team and get back to you. My initial thought is the UART buffer might be doing something unexpected.

    Best Regards,

    Anshu

  • Hello Anshu,

    I don't think it is only the UART. I have tested it as well with a toggeling GPIO and also there it stops toggeling even though the M4 keeps running. My thoughts lean more towards the IO isolation that is being performed by the R5 (Device Manager). This IO isolation would make sense for Deep Sleep when the IO's should have a predictable state. This might also happen for the M4, perhaps it also performs this isolation (on accident) during the MCU Only mode which would explain why I see with the GPIO pin being pulled to High state whenever the CPU goes to MCU Only mode.

    I am currently digging into the R5 firmware to try and understand when this behavior of IO isolation is happening, perhaps I can find (and temporarily disable) it to see if that was the issue.

    I am curious what the development team thinks!

    With kind regards,

    Job

  • Hello Anshu,

    I have found the issue! My code did not include the bypass needed for the MCU I/O's. I was basing my project off the example ipc_rpmsg_echo_linux which implements rpmessage, but also MCU only mode with UART wakeup. However, this example does not include the bypass for the I/O pins. The example lpm_mcu_uart_wakeup does contain this. The following struct must be initialized with the pins you want to exclude from the I/O isolation (for me UART and a GPIO pin):

    /* MCU I/Os are isolated in lpm therefore we need to bypass the pins we need */
    static Pinmux_PerCfg_t gPinMuxIsolationBypassCfg[] =
    {
        /* MCU_SPI0_CS1 -> MCU_GPIO0_1 */
        {
            PIN_MCU_SPI0_CS1,
            PIN_MODE(7) |
            PIN_PULL_DISABLE |
            PIN_ISOLATION_BYPASS
        },
    
        /* MCU_UART0 RX */
        {
            PIN_MCU_UART0_RXD,
            PIN_MODE(0) |
            PIN_PULL_DISABLE |
            PIN_INPUT_ENABLE |
            PIN_ISOLATION_BYPASS
        },
    
        /* MCU_UART0 TX */
        {
            PIN_MCU_UART0_TXD,
            PIN_MODE(0) |
            PIN_PULL_DISABLE |
            PIN_ISOLATION_BYPASS
        },
    
        { PINMUX_END, 0U }
    };


    Then before you enter the MCU Only mode you apply this pinmux:

    /* Enable isolation bypass for the pinmux */
    Pinmux_config(gPinMuxIsolationBypassCfg, PINMUX_DOMAIN_ID_MCU);

    Even though there is an explicit example for the LPM, I would recommend adding this to the ipc_rpmsg example as well given that there is limited information available that doing this bypass is required.

    Thank you for your time and patience!

    With kind regards,

    Job Meulenbeld

  • Thanks for sharing the solution Job. I'll close this thread. Feel free to make a new thread for further questions.

    Best Regards,

    Anshu