MSPM0L1306: UART1 idle mode, sysconfig error

Hello ga jo,

What version of SDK and Sysconfig are you using?  If not the latest (SDK = 2.3.0.0.07 and Sysconfig = 1.22.0) then try upgrading first and try again.

It's the latest.
With previous versions of SDK it was possible to work around the problem by activating the extended mode on UART1, because the define is present in the dl_uart_extend.h file.
With the new SDK there is an error if UART1 is configured as extended, which is normal, because it is not available for this UART.
Our workaround therefore does not work anymore.

I do apologize for the delayed response.  Ok, it sounds like you have it working?

Unfortunately not, the SDK being an entry point of our project that we do not manage in configuration management, we prohibit ourselves from applying modifications to it.
In order for the problem to be resolved, the next version of SDK that you will deliver should contain this correction

Ok, I'm working with our SDK team to see what can be done.

In the mean time, instead of having Sysconfig generate the necessary code, have you tried making the calls in main.c after the SYSCFG_DL_init().

For example:

int main(void)
{
    SYSCFG_DL_init();

    /* Configure Interrupts */
    DL_UART_Extend_enableInterrupt(UART_1_INST, DL_UART_EXTEND_INTERRUPT_RX);

    /* Set the address mask and the address to match */
    DL_UART_Extend_setAddressMask(UART_1_INST, 0);
    DL_UART_Extend_setAddress(UART_1_INST, 0);

    DL_UART_Extend_enable(UART_1_INST);

    NVIC_ClearPendingIRQ(UART_0_INST_INT_IRQN);
    NVIC_EnableIRQ(UART_0_INST_INT_IRQN);
    DL_SYSCTL_enableSleepOnExit();

    while (1) {
        __WFI();
    }
}

Thank you

Indeed, it is possible to use the functions directly.
It would be even better to use the defines of dl_uart.h directly since the UART1 is not supposed to be able to be 'Extend'.
But as we have chosen to use and maintain the sysconfig, we do not allow ourselves to mix manual configuration and sysconfig.
Otherwise the sysconfig does not reflect what is really programmed and can lead to code maintenance problems.

Ok - I completely understand.  I'm tracking down when the change in Sysconfig was made and why.  Once we figure this out, if it turns out this was done in error then a fix would be available in next release.  I'll have to find out when that might be.

Our SW team is looking into this.  If they fix this the next SDK release is scheduled for Feb28 2025.  Can you get by with manual method until then?

Thank you. We choose to keep the version 2.00.00.03 with the work arround that we had found until the next version