7
31
Fork
You've already forked blackmagic
23

External SPI flash support on STM32H7 #2085

Open
opened 2025年02月24日 23:13:03 +01:00 by dsdve · 2 comments
dsdve commented 2025年02月24日 23:13:03 +01:00 (Migrated from github.com)
Copy link

As of now, it seems that the BMP supports writing to external (memory-mapped) SPI flash only on RP2040 targets. Is it feasible to extend this to other targets, specifically STM32H7 (H730 and H750)?

The existing SFDP code appears generic enough, so it seems like this would primarily involve updating the target-specific code with a new flash region and relevant drivers. Of course there are some complications like

  • not having a single consistent Quad/Octo-SPI peripheral on all H7s,
  • possibly having to support varying flash configurations (e.g. singular or parallel/"dual" modes),
  • almost definitely (?) having to support varying pin configurations

I currently have a workaround in place, but if such support was generally desired, I would like to eventually work on implementing it on the BMP.

Any suggestions and hints would be greatly appreciated! :)

As of now, it seems that the BMP supports writing to external (memory-mapped) SPI flash only on RP2040 targets. Is it feasible to extend this to other targets, specifically STM32H7 (H730 and H750)? The existing SFDP code appears generic enough, so it seems like this would primarily involve updating the target-specific code with a new flash region and relevant drivers. Of course there are some complications like - not having a single consistent Quad/Octo-SPI peripheral on all H7s, - possibly having to support varying flash configurations (e.g. singular or parallel/"dual" modes), - almost definitely (?) having to support varying pin configurations I currently have a workaround in place, but if such support was generally desired, I would like to eventually work on implementing it on the BMP. Any suggestions and hints would be greatly appreciated! :)

This code does work on other targets and is used for interfacing with the i.MXRT SPI Flash, RP2040 and RP2350 SPI Flash, Renesas RZ parts SPI Flash, and the LPC43x0 SPI Flash.

Handling the many possible combinations of SPI peripheral usage on the H7s is the min reason this has not yet been been addressed for those parts - however this should be quite doable as long as you can describe how to operate the SPI peripheral to the BMD SPI interface layer (spi.c) - that will take care of Flash discovery from there.

If you can make the support generic to discovering where the SPI Flash is on a part that has multiple controllers, etc, then this would be quite interesting as this is not the first part that's cropped up where this interest has been shown - the SAMD parts have also had interest shown.

This code does work on other targets and is used for interfacing with the i.MXRT SPI Flash, RP2040 and RP2350 SPI Flash, Renesas RZ parts SPI Flash, and the LPC43x0 SPI Flash. Handling the many possible combinations of SPI peripheral usage on the H7s is the min reason this has not yet been been addressed for those parts - however this should be quite doable as long as you can describe how to operate the SPI peripheral to the BMD SPI interface layer (spi.c) - that will take care of Flash discovery from there. If you can make the support generic to discovering where the SPI Flash is on a part that has multiple controllers, etc, then this would be quite interesting as this is not the first part that's cropped up where this interest has been shown - the SAMD parts have also had interest shown.
dsdve commented 2025年02月25日 18:49:54 +01:00 (Migrated from github.com)
Copy link

I do not think discovering flash without any additional information is feasible, neither in a generic nor in a target specific way. The only way I can see this working is by trying all possible configurations and selecting those that discover something, but this will also cause unwanted (and more or less catastrophic) side effects if the probed pins are otherwise used on the target board.

On the other hand, passing the peripheral/pin configuration should make this rather easy. If there is no other mechanism intended for this, I can see a target-specific command working quite well. The command would set up the peripheral and pins to the point where the SPI interface layer can handle the rest. This is pretty cumbersome though, and not generic at all.

I do not think discovering flash without any additional information is feasible, neither in a generic nor in a target specific way. The only way I can see this working is by trying all possible configurations and selecting those that discover _something_, but this will also cause unwanted (and more or less catastrophic) side effects if the probed pins are otherwise used on the target board. On the other hand, passing the peripheral/pin configuration should make this rather easy. If there is no other mechanism intended for this, I can see a target-specific command working quite well. The command would set up the peripheral and pins to the point where the SPI interface layer can handle the rest. This is pretty cumbersome though, and not generic at all.
Sign in to join this conversation.
No Branch/Tag specified
main
fix/pre-bmp-v3-cross-file-cleanup
feature/bmda-remote-comms
ALTracer/feature/aarch64-ident
feature/better-meson-optimisation-handling
feature/am335x-support
feature/esp32-c3-support
feature/cortex-ar-software-breakpoints
feature/unit-testing
feature/windows-usb-serial-interface-naming
fix/bmp-external-spi
ALTracer/feature/bluepillplus-platform
ALTracer/feature/at32f43x-unrdp
feature/const-correctness
ALTracer/feature/fault_handlers
ALTracer/feature/hazard3-ice40-support
fix/ci-cleanup
ALTracer/fix/gdb-10-12-thread
ALTracer/feature/blackpill-f4-adc
ALTracer/fix/cortex-desc-allocfail-report
ALTracer/feature/spi-perf
ALTracer/feature/calibrate_swd
ALTracer/feature/blank-check
feature/avr
v2.0
v1.9
v1.10
v1.8
v2.1.0-rc1
v2.0.0
v2.0.0-rc2
v2.0.0-rc1
v1.9.3
v1.10.2
v1.10.1
v1.10.0
v1.10.0-rc1
v1.10.0-rc0
v1.9.2
v1.8.3
v1.9.1
v1.9.0
v1.9.0-rc1
v1.9.0-rc0
v1.8.2
v1.8.1
v1.8.0
v1.7.1
v1.7
v1.6.2-rc1
1.6.2-rc0
v1.6.1
v1.6
v1.6-rc1
v1.6-rc0
production_01
production_00
Labels
Clear labels
BMD App
Black Magic Debug App (aka. PC hosted) (not firmware)
BMP Firmware
Black Magic Probe Firmware (not PC hosted software)
Bug
Confirmed bug
Build system
Build system
Can't reproduce
Maintainers can't reproduce this problem
CI
Continuous Integration System
Contribution wanted
User contributions welcome
Documentation
Project documentation
Draft
Work in progress draft
Duplicate
This issue or pull request already exists
Enhancement
General project improvement
Feedback wanted
Requires additional submitter feedback
Foreign Host Board
Non Native hardware to runing Black Magic firmware on
GDB
Issue/PR related to GDB
Good first issue
Good for newcommers
HwIssue Mitigation
Solving or mitigating a Hardware issue in Software
Information Needed
Maintainers need more information
NativeHardware
Official Black Magic Debug Hardware
New Host Board
New hardware to run Black Magic firmware on
New Target
New debug target
Off Topic
Something that does not involve the project in any way
Potential Bug
A potential, unconfirmed or very special circumstance bug
Regression
Bug caused by a regression
User Interest Needed
More user interest required before consideration
User Testing Needed
Looking for user testing reports
Won't fix
Outside of the project scope or works as intended
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
blackmagic-debug/blackmagic#2085
Reference in a new issue
blackmagic-debug/blackmagic
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?