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.

[Tesla DeLorean · Accepted solution]

STM32H730 / MX25LM51245G

CLK PF10:AF9

NCS PG6:AF10

D0 PD11:AF9

D1 PD12:AF9

D2 PC2:AF9

D3 PD13:AF9

D4 PH2:AF9

D5 PD5:AF10

D6 PC3:AF4

D7 PD7:AF10

DQS PB2:AF10

[HispaEmo]

Thank You, @Tesla DeLorean ! Your Insight Solved It! :raising_hands:

First of all, a huge thank you to @Tesla DeLorean  for the detailed response and the incredibly helpful pin configuration advice. Your expertise and generosity with your time are invaluable to the STM32 community.

The issue indeed boiled down to a misconfiguration during the migration of pins. Specifically, as you pointed out, PC3 was configured with the wrong alternate function:

GPIO_InitStruct.Alternate = GPIO_AF10_OCTOSPIM_P1; // Wrong configuration during migration

After correcting it to:

GPIO_InitStruct.Alternate =  GPIO_AF4_OCTOSPIM_P1; // Correct alternate function

everything worked perfectly! :party_popper:

This was an oversight on our part, and it serves as a crucial lesson for all developers working on pin migrations, especially when dealing with custom boards or transitioning between development kits and production hardware.

Key Takeaway for Other Devs:

When migrating pins, always double-check the alternate function (GPIOx_AFx) for each pin in your GPIO_InitStruct configuration. The datasheet and reference manual should be your best friends during this process! A single mismatch, like in our case, can cause headaches that are difficult to debug.

Once again, thank you for sharing your wisdom, @Tesla DeLorean . Your guidance helped us get the project back on track, and I hope this thread helps others avoid the same pitfall!

Cheers to an amazing community! :rocket:

[Tesla DeLorean]

Thanks, and pin associations are critical and easily mistyped or copied over

Sorry, I'm a bit confused about the fix,

PC3:AF4 is OCTOSPI_P1_IO6

PC3:AF9 is OCTOSPI_P1_IO0

PC3:AF10 is OTG_HS_UPLI_NXT

https://www.st.com/resource/en/datasheet/stm32h730ib.pdf#page=92

DS13315 Rev 4