How to find where RXNEIE is reset to 0

Pascal Bodin · ‎2022-02-15

Hello,

I'm debuging some legacy code for an STM32L476RG MCU. USART2 is enabled, and used as an UART, with DMA for TX, and one interrupt per received character. I'm using STM32CubeIDE 1.8.0.

Each time a character is received, the HAL_UART_RxCpltCallback function is called. Received character is handed over to the application, and the RX interruption is re-enabled by a call to HAL_UART_Receive_IT.

I observed the following behavior: after the reception of a specific sequence of characters, the reception does not work anymore. Using the debugger, I found the reason for this: RXNEIE bit was reset to 0. But I was not able to find why this bit was reset to 0. I tried to place a watchpoint on USART2's CR1 register, with a condition on RXNEIE bit. GDB server allows me to do this, but the condition is not taken into account (more generally: condition and ignore count do not work with GDB server). OpenOCD does not allow me to do this (Error: can't add write watchpoint at 0x40004401, resource not available) (but condition and ignore count do work on variables).

What could I do to find the origin of the reset?

Guenael Cadier · ‎2022-02-15

Hello @Pascal Bodin

If you are using HAL_UART_Receive_IT() API, RXNEIE bit is expected to be reset when reception is considered as completed (expected nb of data has been received, then Rx complete callback is executed).

From your description (callback executed on each received character), i understand your are using HAL_UART_Receive_IT() with nb of expected data = 1, right ?

Each callback execution restarts next reception.

If yes, is there any chance that rx complete callback does not call again HAL_UART_Receive_IT() API ?

Pascal Bodin · ‎2022-02-15

Hello @Guenael Cadier,

Thanks for your reply. Yes, the application context is exactly what you describe: number of expected byte is set to 1.

I spent quite a lot of time checking the existing source code handling RX, and specifically what you bring to the fore, but I have not been able to find a context where HAL_UART_Receive_IT would not be called again :(

I'm suspecting a RAM corruption coming from another part of the application, because when I remove the call to a function that uses a large buffer, the problem disappears. I checked stack and RAM usages, but they are far from the limits. So it could be that some pointer gets corrupted at some time, and one of the side effects would be that RXNEIE is reset. The problem is to find the origin of this corruption. That's why I tried to set a watchpoint on CR1. But this does not seem to be supported :(

Pascal Bodin · ‎2022-02-16

I found the origin of the problem. It is explained in this question: https://community.st.com/s/question/0D53W00001MzInoSAF/problem-with-trace-utility-in-icubelrwan.