[RESOLVED]UART interrupt conflicts with ethernet? FreeRTOS, LwIP, CubeIDE

[Pavel A.]

A very weird problem here... But Cube-skeptics won't be surprised for sure.

I have a custom board with STM32H753.

Devices in use are several UARTs, FMC, ethernet, I2C, few timers.

FreeRTOS with LwIP.

In main(), just before osKernelStart() I try to read from USART6 in interrupt mode, using HAL_UART_Receive_IT.

But the USART6 interrupt never occurs and HAL_UART_Receive_IT does not receive a single byte.

USART6 is configured in normal async mode, no flow control.

Blocking HAL_UART_Receive() works nicely, so the UART itself is enabled and configured.

The interrupt is enabled in Cube-generated code:

  HAL_NVIC_SetPriority(USART6_IRQn, 6, 0); // tried also priority 0

  HAL_NVIC_EnableIRQ(USART6_IRQn);

When HAL_UART_Receive_IT timeouts, the USART RXNE interrupt in ISR is pending,

but the NVIC bit in IABR (IABR[2] bit 7) is clear!

Then I commented out MX_LWIP_Init call and the USART6 interrupt works as it should.

Why the ethernet & LwIP initialization blocks USART6 interrupt?

I need ETH and USART6 work together in interrupt mode.

-- pa

*** UPDATE***

The trouble is caused by initialization of LwIP (or its freeRTOS tasks?), even without the ETH.

I commented out everything in low_level_init() - and UART6 interrupts still miss.

The project has been generated from .ioc file, by latest CubeIDE and H7 library v 1.6.0, no previous code.

*** UPDATE2***

Generated another project in older CubeMX based on same .ioc but without LwIP and RTOS.

Ethernet and LwIP manually merged from a Cube LwIP example,

in which Ethernet works in polling loop & H7 library V1.5.0.

The generated init code is almost identical.

There UART6 interrupt works fine.

So this looks like 100% software corruption somewhere in LwIP.

[waclawek.jan]

And other relevant USART6 (mainly USART_CR1.RFXNEIE/RXNEIE) and NVIC (mainly ISER and IABR) registers?

JW

[Piranha · Accepted solution]

As lwIP creates a thread and synchronization objects, it's probably the same issue:

https://community.st.com/s/question/0D50X0000C8fHVBSQ2/hali2cgetstate-does-not-work-after-task-creation-and-before-oskernelstart

[Pavel A.]

Jan, Piranha,

Thank you for answers.

For the opinion that it isn't a good idea to accept interrupts before RTOS scheduler enabled because the handler works differently under RTOS: yes of course, I just wanted to check something in a RTOS based project in a simple environment, before entering multitasking.

I thought that before vTaskStartScheduler() call, the environment is same as totally without RTOS, but apparently this is wrong?

I've made another project from the same .ioc, without RTOS, and there the interrupt behavior is normal.

The idea that any RTOS call before scheduler has been activated, returns with interrupts below MAX_SYSCALL_INTERRUPT_PRIORITY masked:

Interesting - but I don't see how this can be true.

xTaskCreate, for example, returns after portENABLE_INTERRUPTS().

That is defined in our Cortex-M port as vPortSetBASEPRI(0), which is "msr basepri, 0".

This means that no interrupt levels are blocked, correct?

Checked BASEPRI and PRIMASK, both remain 0. <<<

What are other means to block interrupt levels, besides of raising BASEPRI? I'm reading CM7 programming manual and don't see any.

*** UPDATE***

Well, the registers view of CubeIDE simply lied in my face! 

I read BASEPRI in code and it indeed equals the MAX_SYSCALL_INTERRUPT_PRIORITY!

So indeed this looks that some RTOS call exited with BASEPRI set to MAX_SYSCALL_INTERRUPT_PRIORITY.

[Piranha]

After such a long time it's better to make a new post/comment/answer.

If CubeIDE lies, check whether the SVD file is correct. Those are just totally full of errors and need a total review, but ST pretends that reporting and fixing those errors one by one is appropriate.