STM32L562 hard fault in SPI_WaitFifoStateUntilTimeout

[Lyap94]

I am using MX25 NOR flash memory 256Mbit (https://www.mxic.com.tw/en-us/products/NOR-Flash/Serial-NOR-Flash/Pages/spec.aspx?p=MX25L25645G&m=Serial%20NOR%20Flash&n=PM2075#Technical-Documents) and I am mounting a littleFS file system on it. The memory communicates through SPI with an STM32L562 microcontroller. After writting and reading files multiple times (more than 100) I get a hard fault. MX25_CMD.c is provided by the memory manufacturer and calls HAL_SPI_Receive(). It seems that the hard fault occurs in SPI_WaitFifoStateUntilTimeout().

I am really blocked by this issue and I don't know towards which direction to look for solutions. Does anybody have any suggestions?

 

The function calls (from recent to older) before the hard fault:

SPI_WaitFifoStateUntilTimeout() at stm32l5xx_hal_spi.c:3’989 0x80338f6
SPI_EndRxTxTransaction() at stm32l5xx_hal_spi.c:4’101 0x8033ae2
HAL_SPI_TransmitReceive() at stm32l5xx_hal_spi.c:1’535 0x8033566
HAL_SPI_Receive() at stm32l5xx_hal_spi.c:1’020 0x8032f52
GetByte() at MX25_CMD.c:685 0x801980e

[Pavel A.]

The debugger of CubeIDE has a tool called Fault Analyzer. Use it to find the reason of the fault and details. See the CubeIDE user guide.

[Lyap94]

Hi Pavel A. and thanks for your reply.

I used it and the only information it gives is below (Bus, memory management or usage fault (FORCED)

And of course the values of the registers:

 

[Pavel A.]

Not something obvious. Looks more like memory or stack corruption, or lack of error checking. 

[Tesla DeLorean]

>>I am really blocked by this issue and I don't know towards which direction to look for solutions. Does anybody have any suggestions?

Write your own code? Debug the third party code?

Not familiar with Macronix's MX25_CMD.c, where can this be found?

What exactly is faulting? Some pointer access? Look at disassembled code and registers it is using.

0xA5A5A5A5 is that some odd pattern you're using, or a stack fill value.

The 0x020001DF doesn't seem like a valid RAM address and is potentially misaligned. Is this the address within the QUADSPI device you're attempting to access.

Check stack and buffer sizes.

No CODE shown, no indication of what you're attempting, or the code that's calling into the library.

[Lyap94]

The Macronix MX25_CMD library is provided as part of the technical documents of the memory by the manufacturer ((https://www.mxic.com.tw/en-us/products/NOR-Flash/Serial-NOR-Flash/Pages/spec.aspx?p=MX25L25645G&m=Serial%20NOR%20Flash&n=PM2075#Technical-Documents). However, I had to add my own code there - an HAL_SPI_Receive() in the GetByte function for example.

0xA5A5A5A5 is a pattern with which I filled the stack to examine stack overflow. But there's no overflow.

In another attempt the pattern appears even in the PC when hard fault occurs.

Apparently, freeRTOS is checking for stack overflow too with this value in stack_macros.h

#if( ( configCHECK_FOR_STACK_OVERFLOW > 1 ) && ( portSTACK_GROWTH < 0 ) )

	#define taskCHECK_FOR_STACK_OVERFLOW()																\
	{																									\
		const uint32_t * const pulStack = ( uint32_t * ) pxCurrentTCB->pxStack;							\
		const uint32_t ulCheckValue = ( uint32_t ) 0xa5a5a5a5;											\
																										\
		if( ( pulStack[ 0 ] != ulCheckValue ) ||														\
			( pulStack[ 1 ] != ulCheckValue ) ||														\
			( pulStack[ 2 ] != ulCheckValue ) ||														\
			( pulStack[ 3 ] != ulCheckValue ) )															\
		{																								\
			vApplicationStackOverflowHook( ( TaskHandle_t ) pxCurrentTCB, pxCurrentTCB->pcTaskName );	\
		}																								\
	}

#endif /* #if( configCHECK_FOR_STACK_OVERFLOW > 1 ) */
/*-----------------------------------------------------------*/

 

[Pavel A.]

> SPI_WaitFifoStateUntilTimeout() at stm32l5xx_hal_spi.c:3’989 0x80338f6

This is not the latest STM32L5 library. In the latest, function SPI_WaitFifoStateUntilTimeout begins from line 4029.

 

[Lyap94]

Finally, I managed to fix the bug after many days. Since I am using FreeRTOS and multiple tasks the value 0xa5a5a5a5, which is used as a checker of the task's stack by the FreeRTOS, led me to check what's happening with the stack size of the task that is constantly failing. It seems that the task's stack was too small.