port custom stm32h750 external flash loader stldr to a openocd config file

[JCuna.1]

Hi, I recently create a external flash loader for a custom board with stm32h750. I can use correctly the stldr file in stm32cubeprogrammer. However, I am planning to use openocd on a raspberry pi with stlinks in order to flash mcu in my boards and also the external flash.

I have checking openocd stm32 branch in github and there is a file located in https://github.com/STMicroelectronics/OpenOCD/blob/openocd-cubeide-r4/tcl/board/stm32h7x_dual_qspi.cfg which contains the external flash loader configuration for stm32h7, but this is a custom code for openocd.

So I am not sure if I need to port my stldr file to this config openocd, or there is another simple way.

Any suggestion to do that?

[Tesla DeLorean]

This looks more like a debugger script to bring up the pins and QS​PI interface, enabling the memory mapped read of the 0x90000000 address space.

[Andreas Bolsch]

That's quite correct. The stmqspi driver (for QSPI/OctoSPI interface) needs the pins to be set up and memory mapped mode. From the settings for this mode the drivers infers the register settings for indirect read/write. No additional setup is required except maybe configuration of the external flash (if e.g. QSPI mode is to be enabled in the external flash chip, block protection to be disabled etc.). All program logic of an external loader is already contained in the stmqspi driver within OpenOCD - no need to add/change anything there.

[Tesla DeLorean]

Would need to work on the BK2 settings, and Winbond, etc

        # PC11:AF9 PB2:AF9 PE7:AF10 PE8:AF10 PE9:AF10 PE10:AF10
 
        # PORT B: PB2:AF9
        mmw 0x58020400 0x00000020 0x00000010 ;# MODER
        mmw 0x58020408 0x00000020 0x00000010 ;# OSPEEDR
        mmw 0x58020420 0x00000900 0x00000600 ;# AFRL
        # PORT C: PC11:AF9
        mmw 0x58020800 0x00800000 0x00400000 ;# MODER
        mmw 0x58020808 0x00800000 0x00400000 ;# OSPEEDR
        mmw 0x5802080C 0x00400000 0x00800000 ;# PUPDR
        mmw 0x58020824 0x00009000 0x00006000 ;# AFRH
        # PORT E: PE7:AF10 PE8:AF10 PE9:AF10 PE10:AF10
        mmw 0x58021000 0x002A8000 0x00154000 ;# MODER
        mmw 0x58021008 0x002A8000 0x00154000 ;# OSPEEDR
        mmw 0x58021020 0xA0000000 0x50000000 ;# AFRL
        mmw 0x58021024 0x00000AAA 0x00000555 ;# AFRH

[JCuna.1]

This means, it is not appropriate config file to flash MCU internal flash and also load extra data in an external flash memory ?​

[JCuna.1]

In order to create stldr file, I created a project with functions to work with my external flash memory? This means that I need to port this functions to openocd script code? Looks like direct manipulation in registers. I still wondering if there is simple way to achieve this.

Also, if I want to use my stldr file in stm32cibeide in order to add data in external flash memory, this will arise the same issue if I use openocd.​

[Tesla DeLorean]

What's I'm sensing from Andreas' explanation is this is a "starting point" it deals with a lot of the board level plumbing, allowing the debugger to see the memory from a breakpoint/execution perspective AND something a more generalized loader can take and run with. ie the device is in a state where simple QSPI / OSPI command interactions could probe the memory IC via the JEDEC ID, and the use the appropriate ERASE, WRITE PAGE command

The STLDR tries to do everything in one bite, this scripting approach allows for the problem to be broken down into smaller, solvable pieces, it separates the WINBOND, MICRON, MACRONIX level programming sequences, from the how the custom board was wired up, or the STM32 it uses..

[Tesla DeLorean]

Define simple..

The script here brings up the RCC, GPIO and then the QSPI, it much the same ways as code in your app would do, but with more of a low level PEEK, POKE, RMW approach.

The MMW command indicates a peripheral/memory address with an OR and AND (Bit Set, Bit Clear) set of parameters.

This is how Debugger Scripts have worked for decades, in Keil these are .INI files, and bring up external hardware, pins and interfaces, in much the same way as is expected by SystemInit() as it is called prior to initializing the statics or constructors, etc.

The debugger knows about the MCU, it has no understanding of what's attached beyond that, and there are millions of possibilities that Keil, IAR or ST aren't going to personally solve for everyone.

Andreas is saying is to use the script to bring up the QSPI (Step#1), and then use a more generic loader within the OCD stack to do the programming (Step#2). Thus dispensing with a custom STLDR or FLM

I generated the GPIO configuration mechanically, its the approach to take if you're likely to do it more than once..

[Tesla DeLorean]

Some other pin configurations based on my list of encountered usage, cut-n-paste out appropriate subsection.

https://github.com/cturvey/stm32extldr/blob/main/h7_qspi_pin.cfg

[Andreas Bolsch]

Regarding the GPIO setup: As it's a bit cumbersome to do this manually, there is a perl script which comes with OpenOCD sources, contrib/loaders/flash/stmqspi/gpio_conf_stm32.pl

There are some GPIO config samples, e.g. for for the various Disco-Boards and description in this file. So what's left to be done manually is the register settings for the QSPI interface for memory mapped mode (and maybe clock tree setup). But this could be copied from one of the configs for the Disco-Boards, the H750-Disco might fit.

And to emphasize it again: No separate loader required, once the config brings up memory mapped read mode properly, everything else should work, too. In case the flash chip requires some special setup, this could be done interactively by 'stmqspi cmd' command, see OpenOCD docs.