cancel
Showing results for 
Search instead for 
Did you mean: 

HAL Delay function Stalls Code in External QSPI Flash (STM32), Custom Delay Works

vishnu_illikkal
Associate III

I'm working on an STM32 project where I'm jumping to code in external QSPI flash (address 0x90000000) after booting from internal flash. I've configured the QSPI memory-mapped mode correctly, and the jump to the external flash works. The interrupt vector table is set up at the beginning of my external flash memory, and the linker script is configured to place the code in external flash, with VTOR set to the start of external flash memory. The MPU is currently disabled.

When the code is running from external flash, HAL_Delay() causes my program to stall. However, if I replace HAL_Delay() with a simple custom delay loop, the code runs correctly. This strongly indicates that there is an issue with how HAL_Delay() is interacting with the hardware or the HAL itself when the code is running from external memory. I've verified that the clock settings are consistent in both internal and external flash.

I need help in understanding what could be causing HAL_Delay() to cause the code to get stuck, while a custom delay works perfectly. What are the most likely points of failure in my startup code, in how the HAL is initialized, or in any low level settings that might be preventing HAL_Delay() from functioning correctly when code is running in external flash? Any advice would be greatly appreciated.

1 ACCEPTED SOLUTION

Accepted Solutions

@vishnu_illikkal wrote:

HAL_Delay() causes my program to stall. 


Surely, that is the intended operation, and entirely to be expected?

HAL_Delay() is just an inline busy loop.

View solution in original post

5 REPLIES 5

@vishnu_illikkal wrote:

HAL_Delay() causes my program to stall. 


Surely, that is the intended operation, and entirely to be expected?

HAL_Delay() is just an inline busy loop.

So HAL_Delay wont work?
if so what to do to make proper delay?

It "works" insofar that it does what it says on the tin.

It is a blocking delay.

Here's one way to achieve a non-blocking delay:

https://community.st.com/t5/stm32-mcus-embedded-software/non-blocking-programming/m-p/755075/highlight/true#M58191

This is found in many (most? all?)  of ST's examples:

 

@note Care must be taken when using HAL_Delay(), this function provides accurate delay (in milliseconds)
based on variable incremented in SysTick ISR. This implies that if HAL_Delay() is called from
a peripheral ISR process, then the SysTick interrupt must have higher priority (numerically lower)
than the peripheral interrupt. Otherwise the caller ISR process will be blocked.
To change the SysTick interrupt priority you have to use HAL_NVIC_SetPriority() function.

@note The application need to ensure that the SysTick time base is always set to 1 millisecond
to have correct HAL operation.

 

Thanks for the information.

I tried using the FreeRTOS and the osDelay worked.
Also mostly i will be using the OS so I can loose HAL_Delay.