External Loader file not working

[PYada.1]

I am using STM32L562, we have replaced MX25LM51245G with, IS25LP128F external flash.

We have integrated its driver and it is working fine. But we want to flash binary using STM32_Programmer_CLI.exe and or STM32Cube programer.

For that, I have tried to develop it's loader using the below repository

https://github.com/STMicroelectronics/stm32-external-loader/tree/main

I have done the following changes in the "MX25LM51245G_STM32L562E-DK" project

Removed related Flies and added IS25LP128F files

I am able to compile it sucessfully.

Changed Dev_Inf.c file as below

struct StorageInfo const StorageInfo = {

#endif

  "ISI25LP_STM32L562E-DK", // Device Name + EVAL Borad name

  NOR_FLASH,               // Device Type

  0x90000000,             // Device Start Address

  0x1000000,            // Device Size in 64 MBytes

  0x1000,               // Programming Page Size 4096 Bytes

  0xFF,                 // Initial Content of Erased Memory

// Specify Size and Address of Sectors (view example below)

  0x00000100, 0x00010000,        // Sector Num : 1024 ,Sector Size: 64 KBytes

  0x00000000, 0x00000000,    

}; 

The driver files are working fine, we have tested IS25LP128F standalone which is working fine as expected.

@Frantz LEFRERE​, Can you please help to identify the issue?  Any steps we are missing?

[Frantz LEFRERE]

Please have a look in this mooc done by my colleague Jiri

https://www.st.com/content/st_com/en/support/learning/stm32-education/stm32-moocs/external_QSPI_loader.html

If this doesn't help, please describe the issue observed.

[DarkMeans]

Did you ever figure out the issues?  I am running into similar ones, it would be nice to learn from your post.

[Tesla DeLorean]

External Loaders are harder to debug. You can instrument internally using USART to output debug / telemetry, using whatever hardware is on your board. Build a prototype or fixture in application space that can call and stress your loader in a situation you can use a debugger.

The MACRONIX part here is OCTOSPI, the ISSI part is QUADSPI, the command and configuration can be entirely different.

ST uses Memory Mapping for Reading. Watch your Init() path as you'll need to reclaim/recover the device into a usable mode to send commands to it. With the HAL you'll need to use the HAL_QSPI/OSPI_Abort functions to exit Memory Mapping. The memories typically don't have an async reset, so you must contend with that too.

External Loaders really shouldn't be using Interrupts, Vector Tables, main(), etc.

They are loaded into RAM by the tools, don't expect normal static initialization to work the way it does with startup.s

[DarkMeans]

Yup, I'm learning that the hard way.

When I have data written in the chip, it seems to work, but the first few hundred bytes (and it's variable) seem to be responded to as 0x88's, which makes me think that I/O3 is pulled high while other things are high-impedence, and then eventually the chip properly responds.

I've debugged everything individually with a debugger and there it's working, but I can't tell if that's just because I don't have the proper initialization of the chip or not.  It does work with the application we have, but having access to download/upload data to our on-board FLASH would be incredibly helpful.

[Tesla DeLorean]

More indicative of the command not being accepted, and not being in 4-pin mode