Troubleshooting "External Loader"

[HispaEmo]

Hi STM32 enthusiasts,

I’m reaching out to the community for advice and guidance on an issue we’re facing while developing an external loader for our custom board. We’ve been working with the STM32H730IBK6Q chip and an external memory MX25LM51245GXDI00, and the hardware setup closely resembles the architecture of the STM32H735G-DK board.

In fact, our software was initially developed and successfully tested on the STM32H735G-DK, and we’re confident in its functionality on that platform. However, moving to our custom board with the STM32H730, we’ve encountered persistent issues with generating a working external loader.

What We’ve Tried So Far:

1. Development on Linux using CubeIDE:

   • We followed several tutorials and used the STM32CubeIDE to generate a .stldr file.
   • This project includes a bootloader that writes a .bin from the SD card and correctly jumps to address 0x90000000.
   • We implemented and debugged the required loader (Dev_Inf.c/h) and linker.ld based on the stm32-external-loader-main repository.

Testing on RAM using CubeIDE showed that both the Init function and external memory mapping worked flawlessly. Additionally, the MassErase function also worked as expected.
Issue:
11:04:17:021 : w ap 0 reg 12 R12 0x00000000
11:04:17:021 : w ap 0 reg 13 SP 0x00000000
11:04:17:021 : w ap 0 reg 14 LR 0x00000000
11:04:17:021 : w ap 0 reg 15 PC 0x240020FD
11:04:17:022 : w ap 0 reg 16 xPSR 0x01000000
11:04:17:022 : w ap 0 reg 17 MSP 0x00000000
11:04:17:022 : w ap 0 reg 18 PSP 0x00000000
11:04:17:022 : run ap 0
11:04:17:022 : halt ap 0
11:04:17:022 : r ap 0 reg 0 R0 0x240049B8
11:04:17:022 : Init function fail
11:04:17:022 : r ap 0 reg 16 xPSR 0x61000003
11:04:17:023 : halt ap 0
11:04:17:023 : w ap 0 reg 15 PC (0x24000000)
11:04:17:023 : w ap 0 reg 17 MSP (0x24000500)

2 . Testing with IAR:

• Using IAR, we generated an external loader for the STM32H735G-DK, and it worked flawlessly:

  • Writing .bin files
  • Erasing external memory
  • Sector erasing
  • All functions performed as expected.

• Since the only theoretical difference between our custom STM32H730 board and the STM32H735G-DK is three GPIO pins, we modified the IAR project for the STM32H735 to match the custom hardware setup. Specifically, we changed the following pin configurations:
  
  /**OCTOSPI1 GPIO Configuration
  PD7 ------> OCTOSPIM_P1_IO7
  PD5 ------> OCTOSPIM_P1_IO5
  PG6 ------> OCTOSPIM_P1_NCS
  PD13 ------> OCTOSPIM_P1_IO3
  PD11 ------> OCTOSPIM_P1_IO0
  PD12 ------> OCTOSPIM_P1_IO1
  PF10 ------> OCTOSPIM_P1_CLK
  PC2 ------> OCTOSPIM_P1_IO2 // change
  PC3 ------> OCTOSPIM_P1_IO6 // change
  PH2 ------> OCTOSPIM_P1_IO4 // change
  PB2 ------> OCTOSPIM_P1_DQS
  
  Issue: Despite these changes, the external loader failed on the custom board.
  
  
  

  Analyzing the Problem:

  • We’ve debugged the Init function extensively in CubeIDE and found it maps the external memory correctly during debugging.
  • However, when running the .stldr file in the STM32CubeProgrammer, we consistently get a timeout.
  • Since we cannot debug the .stldr file in IAR (or at least, we don’t know how to), we resorted to using return statements to pinpoint the failure. Once all Init configurations are passed, the Programmer still times out.

  We’ve carefully reviewed dozens of posts and suggestions from this community (a big shoutout to @Tesla DeLorean  for their excellent insights), but we’re still stuck. The primary challenge is to get the external loader to work seamlessly, especially for debugging the external flash.
  
  

  Questions for the Community:

  1. Why does the Init function work perfectly in CubeIDE debug mode but fail with a timeout in STM32CubeProgrammer? Could it be a hardware initialization issue related to the STM32H730?
  2. Are there known differences in how STM32CubeIDE and IAR handle .stldr generation, particularly for the STM32H730 vs. STM32H735?
  3. How can we debug the external loader on IAR to better understand where the timeout occurs?
  4. Any tips or additional configurations to consider for custom boards using OCTOSPI and the MX25LM51245G memory?

  We’re hoping the collective wisdom of this community can shed light on what we might be missing. Thank you so much for your time and help!

  Best regards
  Emo

[Tesla DeLorean]

For debugging you can either make a test-harness in application space that exercises the functionality, or instrument the code.

You can use any hardware on your board to aid diagnostics, like output to a UART to track dynamic behaviour, and requests passed in.

Repeatedly restarting the RCC / PLL can be problematic if initial conditions are assumed.

The HSI on the H7 runs at 64 MHz, so shoud be sufficient to perform operation on the OSPI without moving to 400 MHz

For timing/timeouts you need to be able to measure time correctly. The STM32 Cube Programmer will timeout on it's end if the loader ends up crashing the MCU, or getting stuck in a while(1) loop indefinitely.