Support for STM32H723ZG CPU

[DonMilne]

I’m currently playing with a Nucleo-144 dev board containing an STM32H723ZG MCU.  I’ve been checking out the extent of VisualGDB support, and in fact it seems pretty good. I’m able to compile and link the LEDblink demo project and it runs. I’ve only hit two problems.

(1) In the project creation wizard I’m given the option to run from SRAM or FLASH.  If I choose SRAM then I get a zero byte flash. I have not investigated. I expected the flash size to be the same, but the startup code would include a section to copy user code from flash to SRAM.  It would be nice to run from SRAM to take advantage of the larger internal SRAM and core clock speed.

(2) I can’t flash or debug this device. I get an error from OpenOCD say “Error: this device has a single bank only”. This error seems to come from the stm32h7x.c module which is part of openocd. This module has comments to the effect that 7xx devices have two banks of flash. In fact I believe the stm32h723zg only has one 1024KB bank – but unless the software was trying to flash a non-existing second bank then I don’t understand why it would produce this error. I don’t see any indication in the linker script that it’s trying to use a second flash bank (flash base address is the usual 0x8000000).

I find that I can still take the binary and flash it using STM32CubeProgrammer, and the firmware from (2) itself works fine, so it’s inconvenient – especially not being able to debug, but not terminal.

All of this is just a heads up since you might start getting more of this: ST recently emailed their customers about this eval board, in fact that’s why I bought one.

[support]

Hi,

The SRAM option works the same for all devices – places all code and data into SRAM. This allows testing out the code without programming the FLASH memory, that could be faster in some times.

If you wish to copy the code from FLASH to RAM, you would need to handle it manually. VisualGDB does not have any special GUI setting for it. If you need a quick example or an explanation how to do it, feel free to reach out to our sales email for a quote.

The OpenOCD support for new devices is usually introduced a few months after a device has been released. ST shares it with the OpenOCD developers, they push it into the master branch, and our build system picks it up. Until then, there are a few options to use the device:

• Select “do not program FLASH” in VisualGDB Debug Settings and use the STM32CubeProgrammer as a custom pre-debug step
• Use Segger J-Link that usually supports new devices earlier
• Try selecting the ST fork of OpenOCD in the VisualGDB Debug Settings
• If the patches for the new device are in review, you can manually apply them to OpenOCD and rebuild it

[DonMilne]

Thanks for the suggestions. I’ll wait until support for this newish CPU is more widespread. I just wanted to check that I wasn’t missing something.

Btw the Nucleo dev boards have a built in STLink USB debug interface, so using Segger j-link would be less convenient.

[MrZANE]

Regarding using J-link on the STM32H723ZG  nucleo board:

Many of STs STM32 dev. boards can have their STLink debugger CPU reprogrammed with j-link firmware.

This is supported by segger:

https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/

Don’t know if your specific board is supported, but it might be worth checking out

[Author]

Posts