STM32U5G9: External Loader Created but not Working

[RenjithGopan]

Hi @stm32 

I have a STM32U5G9 chip connected to a NOR_FLASH Memory MX25UM51245G using OctoSPI. I created an External Loader for the setup, but unable to read/write using the stm32 programmer. The custom driver I developed for the particular flash is proved to work with the same hardware setup, so i can confirm that the bridging between the working driver and the STM2Programmer is somewhat missing.

Steps I Followed to create the Loader are:

1) Created a CubeMx project for stm32U5 with OctoSPI enabled in my case.

2) Manually copied the loader files from the link https://github.com/STMicroelectronics/stm32-external-loader/tree/contrib/Loader_Files and also integrated my custom driver for the particular NOR_FLASH. The driver is tested and verified separately,So it works.

3) In the build configurations, pasted the command cmd.exe /C copy /Y "${BuildArtifactFileBaseName}.elf" "..\${BuildArtifactFileBaseName}.stldr" to create stldr.

After further debugging, i came to the conclusion that the functions Init, Read,Write in the Loader_Src.c are not being called. I had similar problems for the STM32G0 but defining the RAM start address as 0x20000004 and aligning the Vector table to 0x20000000 | 0x200 resolved the issue. The similar fix doesnot help me here. 

I would appreciate anyone's help in this if someone already know the problem and how to resolve it. Also, i couldnot see any documentation regarding how the 4bytes for STM32Cubeprogrammer BL to be assigned or how to align the vector table for a particular STM32 chip series. 

I am also attaching my linker.ld, Dev_Inf.c/.h files, startup and the Loader_Src.c file for clearer picture.  Please note that the Init ,Read and Write functions are properly loaded in the RAM by investigating the Build Analyser in the STM32CubeIDE. I am also attaching a screenshot of that.

Thanks,

Renjith Gopan

[RenjithGopan]

@Tesla DeLorean ,

Hello Tesla, 

I could see you have created most of the external loaders and your solution for my previous problem with STM32G0 helped to resolve, have you ever had this issue before. It would be a great help if you have a work around or solution for my problem.

Thanks,

Renjith

[RenjithGopan]

Sorry , i missed to provide my linker.ld file. Please also find it attached here.

[Tesla DeLorean]

The U5x parts do use the 0x20000004 RAM basis

[RenjithGopan]

Hi @Tesla DeLorean ,

Thanks, i believe something is wrong and still no luck in the Init, Read and writr functions getting fired.

Do anyone already have a working structure of the STM32U5 external project in CubeIDE

If Tesla have any structure already or some suggestions, it would be of great help.

[Tesla DeLorean]

What memory (MX25UM51245G) and pins are you using on the U5A9?

You'd need to check symbols with objdump or review the .MAP file. The placement of the Init() entry-point should not be impacted by the presence or placement of the vectors. Your only dependency really would be the SysTick/HAL_Delay for the timeouts.

The linker script doesn't look bad, I'd expect the G0 one to be same as that needed for the U5. The vectors come in via the startup.s, so perhaps make a dependency there so it pulls it in. Or KEEP (Reset_Handler)

Perhaps use

extern uint32_t *g_pfnVectors;

SCB->VTOR = (uint32_t)&g_pfnVectors[0];

TBH It looks like the vectors come in, so I'd assume it's the Init() that explicitly fails or times out.

Gather a level 3 Log of the interaction from the PC side, and perhaps instrument via an available UART 

[RenjithGopan]

Hi @Tesla DeLorean ,

I am using MX25UM51245G and the pins

PA1 -> OCTOSPIM_P1_DQS 

PC0 -> OCTOSPIM_P1_IO7 , PC1 -> OCTOSPIM_P1_IO4 ,  PC2 -> OCTOSPIM_P1_IO5, PC3 -> OCTOSPIM_P1_IO6

PF6 ->  OCTOSPIM_P1_IO3, PF7 ->  OCTOSPIM_P1_IO2, PF8 ->  OCTOSPIM_P1_IO0, PF9 ->  OCTOSPIM_P1_IO1, PF10->  OCTOSPIM_P1_CLK

PA2 -> OCTOSPIM_P1_NCS  

Also, i just reviewed the .map file and the Init, Read, Write functions are properly placed in one of the valid RAM address. I am also attaching the .map file here.Please also find the level 3 log.

In the log, what i observed is the stack pointer placement is at 0x00000000 , but i would expect to be in the highest address of the SRAM1 which in this case should be 0x202f0000. But the .map file correctly places the _estack in that address properly. Please correct me if my understanding about the log is wrong as i am a beginner in this field.

Best Regards,

Renjith Gopan.

[Tesla DeLorean]

The Init() times out. So something crashing, or locking, perhaps because now VTOR is some place else. Make something simpler, that doesn't call other functions, perhaps return earlier until you work out how deep it gets before failing.

Looks to be loading at 0x30000004 rather than 0x20000004, doesn't seem consistent with the examples I looked at, but only matters if you have absolute dependencies, like vectors.

Using v2.15 ? Perhaps use something newer.

[RenjithGopan]

Hi @Tesla DeLorean ,

Thanks for helping me out.

After looking at the logs properly, and some debugging, one of the clock configuration functions caused the Init function to timeout. So, the Init function is properly triggered and the registers are set properly according to the STM32U5 programming manual.

After much more testing out, I notice that the loading PC with address 0x30000004 is expected as I can see from the memory organisation of the STM32U5 that, both the address corresponds to the same SRAM. More clearly, 0x20000004 is the non secure and 0x30000004 is the non secure callable. 

However, now when I was trying to read the memory mapped address 0x90000000, by observing the logs " 10:37:21:500 : r ap 0 @0x30003D80 0x00000400 bytes Data 0x00000000" , I think it is trying to read an address 0x30003D80. I am not sure where this address comes from, Looks like Cube Programmer itself overwrites the address. Please find the full logs of that.

I was using v2.15 but now updated to the latest now.

Kind Regards,

Renjith Gopan

[Tesla DeLorean · Accepted solution]

I'll take a look.

Typically for NOR_FLASH type the programmer expects to use Memory Mapped so the SWD/JTAG can inspect directly, and not use Read(). Whereas for SPI_FLASH the Read() and Write() methods are used.

When using Write() STM32 Cube Programmer uses the remaining RAM, not used by the loader, to create a Ping-Pong Buffer, the SWD/JTAG writes into this buffer, and then calls Write(). These buffers can be 10's of KB. This is one of the reasons I prefer to make the loaders small and compact.