2019-12-19 05:51 PM
Hi all,
Our team is developing on a custom PCB with STM32L476. And we are testing our CLI robustness, we found out that when we spam the CLI which uses USART2 at baud rate 115200, the program goes into hard fault. Upon investigating with a JLINK debugger, and looking at CFSR, we found we have precise bus fault. And the PC and LP both point to the function uart_irq() in serial_device.c. specifically line 0x080331b8:
if (__HAL_UART_GET_FLAG(huart, UART_FLAG_TXE) != RESET) {
0x080331b4 ldr r3, [sp, #16]
0x080331b6 ldr r3, [r3, #0]
0x080331b8 ldr r3, [r3, #28]
which is accessing USART_TypeDef's ISR attribute. And as the image shown below, R3+#28 is the memory address stored in BFAR.
We've also found a post that might be relevant to this problem we are facing, but it happened on STM32F. And upon looking at USART2's register ISR, we found the ORE flag is tripped. And we are also using mbedOS on top of HAL if that matters.
Does anyone know why this is happening? And if this can be fixed? Thank you all.
2019-12-19 06:02 PM
Suspect memory corruption: the huart structure overwritten, thus the bad UART register address.
-- pa
2019-12-19 06:04 PM
Something is trashing huart->Instance it is being corrupted, perhaps an unbounded buffer write somewhere else. Perhaps huart is wrong, and thus the chain is broken.
Walk back up the code here, and add sanity checks to see when the pointer(s) get broken.
2019-12-20 01:34 PM
So what I found is before the bus fault and hard fault, the memory map of huart->Instance shows
and after the fault, it shows:
which according to visualGDB I am running in visual studio, the memory region is not readable.
2019-12-20 01:43 PM
So got to unwind the pointers, and array, and index