FreeRTOS LPUART driver problem

[Oliver_R]

Hi,

I'm using a RT1176 based board with (currently the older) mcux-sdk, but the problem looks identical in the mcuxsdk (really confusing names!):

The Freertos-LPUART driver (fsl_lpuart_freertos.c) does not call HAL_UartInit (fsl_adapter_lpuart.c) in the LPUART_RTOS_Init function. Instead it calls just LPUART_Init, which is not enough!

The problem is that the field s_UartState (line 719 in fsl_fsl_adapter_lpuart.c) is not written in LPUART_Init which then leads to an assertion if a receive interrupt from the UART occurs:

ASSERT ERROR " NULL != uartHandle ": file "D:\usr\TQM\mcuxsdk\core\components\uart\fsl_adapter_lpuart.c" Line "433" function name "HAL_UartInterruptHandle"

So I wonder, how this driver could ever worked, because the array s_UartState is read for the handle in the interrupt driver (and then it is NULL).

So, did I anything wrong or has this driver a problem? Maybe I have to rewrite the code to use a lower API driver for the LPUARTS?

Thanks and bye,
Oliver

[Pablo_Ramos]

Hi @Oliver_R,

Could you help me with the following question?

Are you using VS Code or MCUXpresso?

If you test with mcuxsdk , does the problem persist?

In VS Code, there is an example project: evkbmimxrt1170_freertos_lpuart_cm7. Could you help me test whether it works with your hardware?

Best Regards,
Pablo

[Oliver_R]

Hello,

I'm using the VSCode plugin with the latest mcux-sdk. We're using a TQMa117xL based board and unfortunately the BSP is not yet ready for mcuxsdk.

This means I can't test it right now with mcuxsdk but in the future we will change to it.

The mentioned example is new, as I can't find it in mcux-sdk? I will check it out.

The assertion happens right after the Init function:

lpuart_rtos_config_t mSerConfig;
lpuart_rtos_handle_t mRtosHandle;
_lpuart_handle       mUartHandle;
mRtosHandle = {};
mUartHandle = {};
mSerConfig             = {};
mSerConfig.srcclk = CLOCK_GetRootClockFreq(kCLOCK_Root_Lpuart9);
mSerConfig.base   = LPUART9;
mSerConfig.baudrate    = aBaudrate;
mSerConfig.parity      = kLPUART_ParityDisabled;
mSerConfig.stopbits    = kLPUART_OneStopBit;
mSerConfig.buffer      = mReadBuf;
mSerConfig.buffer_size = sizeof(mReadBuf);
mSerConfig.enableRxRTS = true;
mSerConfig.enableTxCTS = true;
int status = LPUART_RTOS_Init(&mRtosHandle, &mUartHandle, &mSerConfig);

The code is in a C++ class but I will compare the init code with the example.

Bye,

Oliver

[Oliver_R]

Hi,

in the meantime I discovered, that this is not related only to the FreeRTOS-Uart driver, but also to the underlying lpuart driver.

Unfortunately, I found nothing in the SDK documentation or in the forums to the HAL_Uart-driver

For what reason is the HAL_Uartxxx-API (fsl_adapter_lpuart.c)? Why and when should I use it? There are only two sources in the whole SDK which are using HAL_UartInit at all: fsl_component_serial_port_uart.c and fsl_debug_console.c in the debug_console_lite folder.

The problem I have with this API is that when fsl_adapter_lpuart.c is compiled WITHOUT the define "HAL_UART_TRANSFER_MODE=1" then all lpuart interrupts are defined in this source and then I HAVE to use HAL_UartInit in order to avoid the assertion in the receive IRQ. And as the IRQs are already defined, I have no change to register my own IRQ anymore.

But all UART examples do not set HAL_UART_TRANSFER_MODE=1 and some examples are defining their own IRQs, so I wonder how this could work. I define DEBUG_CONSOLE_TRANSFER_NON_BLOCKING and I'm not using the "utility_debug_console_lite" component.

BTW: What is the difference between "utility_debug_console" and "utility_debug_console_lite"? The SDK documentation is the same for both components?

All of this driver code is very very hard to understand as there is so much preprocessor magic and so few documentation for it.

So I have the impression, that the source "fsl_adapter_lpuart.c" should not be compiled in at all as it defines the lpuart IRQs in an unwanted way which lead to assertions when using other lpuarts than the debug console lpuart.

Bye,
Oliver