STM32f303 Imprecise data access error (debugging hard faults)

[ccvelandres]

I am encountering a consistent hard fault (CFSR.IMPRECISERR with HFSR.FORCED bit set) on my program with FreeRTOS v10. I can fully reproduce the fault everytime and same conditions so I'm sure this can be fixed. Just need to know what causes it.

Specifically on HAL_SPI_TRANSMIT_DMA (stm32f3xx_hal_spi.c line 1571).

if ((hspi->Init.DataSize <= SPI_DATASIZE_8BIT) && (hspi->hdmatx->Init.MemDataAlignment == DMA_MDATAALIGN_HALFWORD))

On reading some other articles, It seems like the stack frame is not related to the cause of stack frame since the write was buffered. Then from the documentation for ARM Cortex M4, there's the Auxiliary Control Register with the DISDEFWBUF when set to 1, will diable the write buffering and turn imprecise faults to precise faults. But I can't find the register on my device.

Question is, how can I find the cause of the fault without being able to disable the write buffering? Or does anybody have any idea what the problem is?

[ccvelandres]

Found the cause! Turns out one of the libraries I'm using was using a static buffer at 0x2000DAD0 to 0x2000DB34 (size 100 bytes). And it was having a buffer overflow which then causes to overwrite the hspi1 struct. Increasing the size of the buffer fixed the problem.

Thanks so much for the inputs! I'm just thinking, how would one better detect buffer overflows like these ones? Especially if the memory was dynamically allocated?

[Ozone]

I don't know (understand ?) all circumstances. Especially what you mean with "dynamically allocated".

Make sure stack sizes are appropriate for your application.

> Turns out one of the libraries I'm using was using a static buffer at 0x2000DAD0 to 0x2000DB34 (size 100 bytes). And it was having a buffer overflow...

If the library code made out-of-boundary array accesses, it is buggy. Your hspi instace variable might just have been neighboring on the stack.

[waclawek.jan]

Thanks for coming back with the solution. Please choose your post as Best, so that the thread is marked as resolved.

> how would one better detect buffer overflows like these ones?

Using a different programming language...

C is inherently prone to programmer errors like these. It's basic premise was, everything is allowed and it's the programmer's responsibility no to shoot himself into foot. It's anticipated that the programmer will exercise extreme care, and/or will write every check necessary. This did not work out well in practice as witnessed by the innumerous bugs in the wild...

.. but that's life, programming languages are not chosen primarily based on their type safety.

JW

[ccvelandres]

> ... Especially what you mean with "dynamically allocated".

Just a hypothetical situation where the buffer is dynamically allocated and also the other buffer getting overwritten is dynamically allocated in the heap. How would you catch instances of buffer overflow? Of course, prevention is key, but what if it was a big library you imported was causing this?

> If the library code made out-of-boundary array accesses, it is buggy

Yeah.. I'll inform the developer regarding this