Skip to main content
Associate II
June 16, 2025
Solved

External Loader

  • June 16, 2025
  • 1 reply
  • 719 views

Hello all,

I have a custom board with an STM32U5A9 mcu with an external MT25QL128 flash for TouchGFX assets.

I have a working loader for IAR Embedded workbench and I'm trying to port it to work with the STM32CubeProgrammer.

When building as a normal project - that is a minimal cubemx project with just ospi and clocks enabled and with my ospi functions it runs fine, read/write/erase the flash without any issues.

However, when I move it to the loader framework the init function crashes - I believe in a hard fault or some kind. It's difficult to tell for certain since debugging the loader is tricky.

The cube programmer only tells me "Error: Data read failure".

I realized that if I return early from the Init, no error is issued and the flash only read zeros - which makes sense because the ospi is not initialized yet.

Thus I found out that the issue so far is on HAL_OSPI_MspInit function that was generated by cubemx.

This part of the code returns 0:

 __HAL_RCC_OSPIM_CLK_ENABLE();
return 0;
 __HAL_RCC_OSPI1_CLK_ENABLE();

but this code crashes:

 __HAL_RCC_OSPIM_CLK_ENABLE();
 __HAL_RCC_OSPI1_CLK_ENABLE();
return 0;

 the __HAL_RCC_OSPI1_CLK_ENABLE is a macro:

#define __HAL_RCC_OSPI1_CLK_ENABLE() do { \
 __IO uint32_t tmpreg; \
 SET_BIT(RCC->AHB2ENR2, RCC_AHB2ENR2_OCTOSPI1EN); \
 /* Delay after an RCC peripheral clock enabling */ \
 tmpreg = READ_BIT(RCC->AHB2ENR2, RCC_AHB2ENR2_OCTOSPI1EN); \
 UNUSED(tmpreg); \
 } while(0)

And it is the SET_BIT line that's crashing. I don't know why.

It's not access as if I read the RCC->AHB2ENR2 it does not crash, only writing.

Does anyone have an idea what is going on here - or even how to debug this?

On a side note, when developing the IAR EWARM loader I had to increase the stack size for the loader to work, I could not find how to do that in the cubeprogrammer loader either.

Any help is much appreciated

Best answer by RW3562

Hi all,

I found the issue that I was having :)

For some reason the stm32programmer was calling the Init() function multiple times, and on the second run it crashed.

I solved the issue by testing whether the ospi was initialized or not

KeepInCompilation int Init()
{
 if(READ_BIT(OCTOSPI1->CR, OCTOSPI_CR_EN)){
 EnterMemoryMapMode();
 return 1;
 }
 //perform the actual initialization
...
}

1 reply

Tesla DeLorean
Guru
June 17, 2025

Make sure to clear/setup variables completely as no code is called to initialize statics.

For debugging one can use an available UART or other board hardware to output diagnostic  or telemetry data.

Some of STs examples use interrupts and a vector table, so an informative HardFault_Handler might work. Similarly an Error_Handler that outputs file/line data before entering a while(1)

 

Tips, Buy me a coffee, or three.. PayPal VenmoUp vote any posts that you find helpful, it shows what's working..
Tesla DeLorean
Guru
June 17, 2025

Enumerate the pins you're using, I could rebuild one of my loaders.

Tips, Buy me a coffee, or three.. PayPal VenmoUp vote any posts that you find helpful, it shows what's working..
RW3562Author
Associate II
June 17, 2025

Hello,

> Enumerate the pins you're using, I could rebuild one of my loaders.

I'm using OCTOSPI1 in quad spi mode using port2 clk,ncs and io:

CLK: PF4

NCS: PI5

Data0: PI3

Data1: PI2

Data2: PI1

Data3: PF3

Micron memory type w/ device size of 24 .