STM32H7RSx #2081

oclyke commented 2025年02月18日 09:04:33 +01:00 (Migrated from github.com)

Please report unknown device with Designer 0x20 Part ID 0x4850

Hi all. I am developing on a newer ST part. After finding that OpenOCD did not support this MCU I figured I'd give it a try on BMP.

Family: STM32H7RSx
MCU: STM3H7S3x8
Board: Nucleo-H7S3L8
Interface: SWD

I don't really understand all of what it takes to properly config a new target. Maybe I can start with an openocd config and work my way to BMP.

P.s. thanks to all you contributors. Tools like BMP and OpenOCD are so much better to work with than the gimmicky all-in-one IDEs.

`Please report unknown device with Designer 0x20 Part ID 0x4850` Hi all. I am developing on a newer ST part. After finding that OpenOCD did not support this MCU I figured I'd give it a try on BMP. Family: STM32H7RSx MCU: STM3H7S3x8 Board: Nucleo-H7S3L8 Interface: SWD I don't really understand all of what it takes to properly config a new target. Maybe I can start with an openocd config and work my way to BMP. P.s. thanks to all you contributors. Tools like BMP and OpenOCD are so much better to work with than the gimmicky all-in-one IDEs.

dragonmux commented 2025年02月18日 11:26:41 +01:00

Before we can hope to help here:

1. What version of the firmware are you trying to use?
2. Did you try latest main and if so, did you make sure you used a configuration that enables the STM parts?

Regarding being able to use OpenOCD configurations as a basis.. the way that OOCD works is very different. BMD does full automatic discovery and then dispatches to part-specific routines based on what has been discovered. The STM32H7R parts should at least be detected generically and be debuggable on main even if they aren't detected as H7 series parts directly so their Flash gets registered and made rewritable.

Support for these parts should be able to be added to the existing H7 support (src/targets/stm32h7.c), and the target drivers guide documents how the interfaces in question work. You can also use the efforts of other contributors such as zyp as inspiration: https://github.com/zyp/blackmagic/tree/stm32h7rs

Before we can hope to help here: 1) What version of the firmware are you trying to use? 2) Did you try latest `main` and if so, did you make sure you used a configuration that enables the STM parts? Regarding being able to use OpenOCD configurations as a basis.. the way that OOCD works is very different. BMD does full automatic discovery and then dispatches to part-specific routines based on what has been discovered. The STM32H7R parts should at least be detected generically and be debuggable on `main` even if they aren't detected as H7 series parts directly so their Flash gets registered and made rewritable. Support for these parts should be able to be added to the existing H7 support (src/targets/stm32h7.c), and [the target drivers guide](https://black-magic.org/hacking/target-drivers.html) documents how the interfaces in question work. You can also use the efforts of other contributors such as zyp as inspiration: https://github.com/zyp/blackmagic/tree/stm32h7rs

oclyke commented 2025年02月21日 09:20:02 +01:00 (Migrated from github.com)

Thanks dragonmux.

Original report was made with a recent copy of prebuilt firmware.

u@h:~/Desktop/tmp/blackmagic✨ bmputil info
Found: Black Magic Probe v1.10.2
 Serial: 72AE07F3
 Port: 0-1

Thanks to your prompt I built fw from main (v2.0.0-rc1 woo!) and flashed.

u@h:~/Desktop/tmp/blackmagic✨ bmputil flash ./build/blackmagic_native_firmware.elf
Found: Black Magic Probe v1.10.2
 Serial: 72AE07F3
 Port: 0-1
Erasing flash...
Flashing...
 100% |██████████████████████████████████████████████████| 118.63 KiB/118.63 KiB [4.28 KiB/s 28s] [2025年02月20日T21:35:42Z WARN bmputil] Possibly spurious error from OS at the very end of flashing: Black Magic Probe device did not come back online (invalid firmware?)
 Caused by: rusb: Other error
 
Black Magic Probe successfully rebooted into firmware version v2.0.0-rc1-47-g3148437e-dirty
u@h:~/Desktop/tmp/blackmagic✨bmputil info
Found: Black Magic Probe v2.0.0-rc1-47-g3148437e-dirty
 Serial: 72AE07F3
 Port: 0-1

With the new firmware loaded I got the same message as before (ok, expected) and could see that as you suggested the probe seems to have connected to the AP just fine. I suppose your point is that without a positive ID on the device, and corresponding firmware support, it is impossible to perform flash operations.

u@h:~/Desktop/tmp/blackmagic✨ gdb
GNU gdb (Arm GNU Toolchain 14.2.Rel1 (Build arm-14.52)) 15.2.90.20241130-git
...
(gdb) tar ext /dev/cu.usbmodem72AE07F31
Remote debugging using /dev/cu.usbmodem72AE07F31
(gdb) mon swd
Target voltage: 3.3V
Please report unknown device with Designer 0x20 Part ID 0x4850
Available Targets:
No. Att Driver
*** 1 Unknown ARM Cortex-M Designer 0x20 Part ID 0x4850 M7
(gdb) 

I started down the path of adding flash support (following zyp's example, and cross-referencing with RM0477) and it generally looked pretty straightforward.

Then there was a crash between my (present) skill ceiling and my (present) time constraints. My application requires flash memory in excess of the 64 KB built in to the STM32H7Rx/7Sx parts. For the time being I have to take an off-ramp.

Leaving this report here to encourage others. The BMP firmware and build system is very nicely maintained and easy to get started with! Go ahead and give it a shot.

(maybe I'll find time to come back and finish the job... I sure would be interested in how to operate the FMC peripheral through the debug probe and gain access to the XSPI memory regions.)

Thanks dragonmux. Original report was made with a recent copy of prebuilt firmware. ```sh u@h:~/Desktop/tmp/blackmagic✨ bmputil info Found: Black Magic Probe v1.10.2 Serial: 72AE07F3 Port: 0-1 ``` Thanks to your prompt I built fw from main (v2.0.0-rc1 woo!) and flashed. ``` u@h:~/Desktop/tmp/blackmagic✨ bmputil flash ./build/blackmagic_native_firmware.elf Found: Black Magic Probe v1.10.2 Serial: 72AE07F3 Port: 0-1 Erasing flash... Flashing... 100% |██████████████████████████████████████████████████| 118.63 KiB/118.63 KiB [4.28 KiB/s 28s] [2025年02月20日T21:35:42Z WARN bmputil] Possibly spurious error from OS at the very end of flashing: Black Magic Probe device did not come back online (invalid firmware?) Caused by: rusb: Other error Black Magic Probe successfully rebooted into firmware version v2.0.0-rc1-47-g3148437e-dirty u@h:~/Desktop/tmp/blackmagic✨bmputil info Found: Black Magic Probe v2.0.0-rc1-47-g3148437e-dirty Serial: 72AE07F3 Port: 0-1 ``` With the new firmware loaded I got the same message as before (ok, expected) and could see that as you suggested the probe seems to have connected to the AP just fine. I suppose your point is that without a positive ID on the device, and corresponding firmware support, it is impossible to perform flash operations. ```sh u@h:~/Desktop/tmp/blackmagic✨ gdb GNU gdb (Arm GNU Toolchain 14.2.Rel1 (Build arm-14.52)) 15.2.90.20241130-git ... (gdb) tar ext /dev/cu.usbmodem72AE07F31 Remote debugging using /dev/cu.usbmodem72AE07F31 (gdb) mon swd Target voltage: 3.3V Please report unknown device with Designer 0x20 Part ID 0x4850 Available Targets: No. Att Driver *** 1 Unknown ARM Cortex-M Designer 0x20 Part ID 0x4850 M7 (gdb) ``` I started down the path of adding flash support (following zyp's example, and cross-referencing with [RM0477](https://www.st.com/resource/en/reference_manual/rm0477-stm32h7rx7sx-armbased-32bit-mcus-stmicroelectronics.pdf)) and it generally looked pretty straightforward. Then there was a crash between my (present) skill ceiling and my (present) time constraints. My application requires flash memory in excess of the 64 KB built in to the STM32H7Rx/7Sx parts. For the time being I have to take an off-ramp. Leaving this report here to encourage others. The BMP firmware and build system is very nicely maintained and easy to get started with! Go ahead and give it a shot. (maybe I'll find time to come back and finish the job... I sure would be interested in how to operate the FMC peripheral through the debug probe and gain access to the XSPI memory regions.)

dragonmux commented 2026年06月22日 09:43:06 +02:00

This has now been addressed by the support merged in #2170 - so closing as complete.

This has now been addressed by the support merged in #2170 - so closing as complete.