Projects with STM32H7S3x8 / STM32H7S7x8

[intector]

Hello,

STMicroelectronics got a new MCU series, the “600 MHz bootflash MCU”. It’s an impressive device that blurs the lines between the MCU and MPU. I bought the NUCLEO-STM32H7S3L8 board to test those new devices, and they’re working well, and it’s pretty simple to get started with the STM32CubeIDE.

I’ve been using VisualGDB for several years, and it has become my favorite tool for developing software for embedded systems. Unfortunately, there’s not a lot of documentation about the use of STM32H7S3x8 / STM32H7S7x8 MCUs, and I was wondering if anyone had a chance to work with those in VisualGDB. It would be interesting to know if there is a way to create a project in VisualGDB that contains the Appli and the Boot parts(similar to the STM32CubeIDE).

For now, I have to use the STM32CubeIDE to create and flash the “Boot” project with the “ExtMemLoader,” and then I can use VisualGDB to work on the “Appli” project. That works OK, but it’s somewhat cumbersome. Please let me know if there’s a better solution.

 

never forget:
“Always be yourself.
Unless you can be a pirate.
Then always be a pirate.”

 

[support]

Hi,

We are aware of the new STM32H7S series and have the BSP based on the official SDK from STM32, however have not tried the hardware on our side yet.

If you would like to replicate the 2-project structure from STM32CubeIDE, we would advise using the Advanced CMake Project Subsystem to create the bootloader + application projects separately, and then manually combine them into the same project by editing CMakeLists.txt. Specifically you would need to:

• Move the find_bsp() statement from the second project into the first one, adding an ALIAS parameter (e.g. BSP2)
• Move the add_bsp_based_executable() statement as well, setting BSP_ALIAS to match the second BSP.

You can also just create 2 separate MSBuild projects and have them in the same solution (right-click on Solution node -> Add -> Existing Project).

We do not have the hardware yet to give exact advice on replicating the ExtMemLoader logic (we will be publishing a tutorial in a couple of weeks), however, you can try checking what exactly does the STM32CubeIDE do in this mode. If it’s running OpenOCD with some special arguments, or executing the STM32CubeProg, we can help you configure VisualGDB to match that.

[intector]

Hello,

I’ll try this and let you know the results.

[intector]

Hey,

Did you have a chance to test the STM32H7S/R series MCU?

[support]

Hi,

Yes, we recently managed to get it working. Had to manually change an option byte per this thread, and use the STM32CubeProgrammer to load the external memory, but after all the manual configuration, it works now. We’ll publish a detailed tutorial in the next couple of days.

[intector]

Hey,
That’s excellent news. Just in time, I finished my new board with an STM32H7R3L8H6H. I’m looking forward to your tutorial.

 

Great job, guys, and never forget:

“Always be yourself.
Unless you can be a pirate.
Then always be a pirate.”

 

[support]

Hi,

OK, good news! ST has finally released the source code for the STM32H7R/S support in OpenOCD, so we merged it with our fork, enabling faster Live Memory and other features on these devices.

We have also published an updated BSP that includes the external memory manager and a few other STM32H7R/S-specific libraries as easy-to-use frameworks.

We have published a tutorial on a bootloader project and another one for the main application. Programming the latter requires installing the STM32CubeProgrammer tool, however now that OpenOCD support is properly merged, you can try creating an OpenOCD plugin for the external memory if you want to avoid external dependencies (we may eventually publish another tutorial on that, but not currently).

[intector]

Hey Guys,

Thank you for this great tutorial. I finally can get away from that awful STM32CubeIDE with its annoying STM32CubeMX code generation.

I’m working on a project for which I designed the PCB. It uses the STM32H7R3L8H6H MCU, an 8GByte EMMC08G-MV28, a 32MByte MX25UW25645GXDI00, and a 32MByte APS256XXN-OBR, among other peripherals. I’ve attached some pictures of it.

I have the memory working at 200 MHz, but it was a project. The STM32Cube_FW_H7RS_V1.1.0 package contains several errors regarding the XSPI drivers, and the documentation isn’t updated either.

 

Again, thank you for your support, and keep in mind:

“Always be yourself. Unless you can be a pirate. Then always be a pirate.”

• This reply was modified 1 month, 3 weeks ago by intector.

Attachments:

You must be logged in to view attached files.

[support]

Hi,

You can try reporting it to ST. Our packages are directly based on their SDKs, so any fixes they make in the subsequent versions will be automatically included in our BSPs as well.

[intector]

Hello Support,

I upgraded my VisualGDB to custom to follow your tutorials. I’m trying to get my board running by following your tutorials. Unfortunately, I can’t see any values when I stop on breakpoints. I also tested a NUCLEO-STM32H7S3L8 board but ran into the same problems. What could be the problem?

 

[support]

Sorry, doesn’t look like any known issue. Please consider attaching a screenshot illustrating the problem along with the GDB log.

[intector]

Hello,

Thank you for the fast reply to my question.

Here are some more details on my issue:

1. I used a board with a STM32H7R3L8H6H MCU
2. To create the test project, I used STM32H7S78-DK –> Template_XSIP –> Boot
3. It places the __disable_irq() function, calling the Error_Handler function. This gets red underlined because it can’t find the declaration. In STM32CubeIDE it uses the declartion in cmsis_gcc.h. In VisualGDB, it doesn’t offer this file as a solution. The screenshot __disable_irq_error.jpg shows the location in the main.c file where this function is called. The screenshot cmsis_selection.png shows the files that VisualGDB offers.
4. The screenshot no_values01.jpg shows the variables without values during debugging.

Please check the attached files for more information.

 

I tried a test with the USB-CDC example for the NUCLEO-STM32H7S3L8, which you used in your tutorial, and this doesn’t have this issue. The variables have values in that case.

 

 

 

Attachments:

You must be logged in to view attached files.

[support]

Hi,

Thanks for the screenshots. With the variable values it looks like conflict between the bootloader symbols and application symbols (both have the same variable defined at different places). We have added another step to the application tutorial showing how to avoid it by disabling bootloader symbols and debugging only the application.

The second error is caused by a workaround that is no longer required with the latest GCC. We have fixed it in our development branch, and you can apply it on your side by removing these lines from %VISUALGDB_DIR%\gcc_compat.h:

#ifdef __ARM_EABI__
#define __LDREXW(expr) *(expr)
#define __STREXW(expr, val) expr
#endif

[intector]

Hello,

Thank you for the excellent support. It works like a charm.

[Author]

Posts