Support for stm32h725/735

[AdminXVII]

Hi,

I'd like for a project to use the stm32h725. It has ECC RAM, something the other stm32h7 boards don't have. Well except for the stm32h747/757, but I'd rather not pay the premium for features I won't use anyway.
I noticed those boards aren't supported by this library.

Is it because nobody has the μControler to test? Or is it because of an incompatibility with the hardware?

If it's because of testing or minor incompatibility I'd be willing to help. I have never worked on a HAL like this though, so if it's ok with you I'd still want instructions about how to proceed.

[hargoniX]

I do not recall any reason for us to specifically exclude stm32h725/735

As to how you could proceed:
You have to make sure stm32h7 the PAC crate supports stm32h725, this does not seem to be the case, at least I cannot see it in this file: https://github.com/stm32-rs/stm32-rs-nightlies/blob/master/stm32h7/Cargo.toml (that is probably the reason we didn't include it yet since the PAC is really the basics of the basics required to get going) The ZIP archive (https://github.com/stm32-rs/stm32-rs/blob/master/svd/vendor/stm32h7_svd.zip) that contains the files we need to create said PAC does unfortunately only have the following SVD files (SVD files are the files we need for the PAC) :

   creating: STM32H7_svd/STM32H7_svd_V1.4/
  inflating: STM32H7_svd/STM32H7_svd_V1.4/STM32H742x.svd
  inflating: STM32H7_svd/STM32H7_svd_V1.4/STM32H743x.svd
  inflating: STM32H7_svd/STM32H7_svd_V1.4/STM32H750x.svd
  inflating: STM32H7_svd/STM32H7_svd_V1.4/STM32H753x.svd
  inflating: STM32H7_svd/STM32H7_svd_V1.4/STM32H7A3x.svd
  inflating: STM32H7_svd/STM32H7_svd_V1.4/STM32H7B3x.svd
  inflating: STM32H7_svd/STM32H7_svd_V1.4/STM32H7x3.svd
  inflating: STM32H7_svd/STM32H7_svd_V1.4/STM32H7x5_CM4.svd
  inflating: STM32H7_svd/STM32H7_svd_V1.4/STM32H7x5_CM7.svd
  inflating: STM32H7_svd/STM32H7_svd_V1.4/STM32H7x7_CM4.svd
  inflating: STM32H7_svd/STM32H7_svd_V1.4/STM32H7x7_CM7.svd

Nothing for stm32h725/735 in sight (STM32H7x5 refers to another series).

This means that Mission 1 would be to find the SVD files for stm32h725/stm32h735. After that you want to integrate those into https://github.com/stm32-rs/stm32-rs. And at that point we can start looking into getting something going with this HAL.

[richardeoin]

We could definitely support these parts in future! But @hargoniX is completely right, these parts need to be supported in the Peripheral Access Crate (PAC) first.

[AdminXVII]

Alright, thanks for the insight, I'll see what I can find.

[mlamoore]

The svd files are provided with ST's firmware packs for a given processor, you can download that easily enough.

The real issue is that ST isn't consistent with their naming/organization, so the stm32-rs project applies patches to the svd files to make them consistent with each other before using svd2rs to generate the PAC.

So the real task here is that patching process. If it lines up closely with some of the other stm32h7 SVD files, it may be as easy as identifying which one and pulling in the right existing patches.

After the PAC supports the processor, I wouldn't expect it to be too hard to get the HAL to support it too (unless ST made some bigger changes or some important app notes about specific things that need to be handled differently). We recently got some PR's to add support for the STM32H7A3, STM32H7B0, and STM32H7B3; you can take a look and see what was involved in adding support for those chips.

[AdminXVII]

Ok so everywhere I look on the ST resources the same svd zip is linked (no new files, no changes which would be related to this μController). Even on the resources for the stm32h735. So I'm inclined to think the STM32H7x5_CM7.svd file does fit?
However I hadn't realized, but this chip seems to be pretty recent (announced September 29th, 2020, and manual's first revision also dating from September 2020). Is ST known to release chips before the SVDs? Could be that the files aren't ready yet.

[richardeoin]

I think STM32H7x5_CM7.svd is actually meant for the H745/H755 parts. Hopefully the correct SVD for the stm32h725 would describe some of the new peripherals added in RM0468 (PSSI, OCTOSPI, CORDIC, FMAC..)

I've not heard of it before, but it's certainly possible that ST haven't finished the files yet. It's probably true that the SVDs are lower priority for ST, even though SVD is a standard for ARM microcontrollers.

[richardeoin]

There's still no SVDs available from ST's website, but there are some SVDs available in the CMSIS pack here: https://keilpack.azureedge.net/pack/Keil.STM32H7xx_DFP.2.7.0.pack (can also be accessed from https://developer.arm.com/tools-and-software/embedded/cmsis/cmsis-search)

Unzip -> CMSIS/SVD/STM32H723.svd/CMSIS/SVD/STM32H73x.svd

There's certainly not perfect, but probably no worse than we're used to either. They could be a good starting point for someone wanting to create a PAC for these parts.

[TomDeRybel]

I've noticed that ST has recently released a new SVD for the STM32H7 family.
Link: https://www.st.com/content/st_com/en/search.html#q=stm32H735%20SVD-t=resources-page=1
This file has version 1.6, and includes several new parts, including the H725, H735, H73x.

Personally, I have a board coming-up soon with the STM32H725. I'd like to help, but this is the very first time I'm touching Rust, so I can only do this with a lot of hand-holding.

[hargoniX]

Integrating new SVDs into the stm32-rs eco system isn't too hard per se. Basically we have a repository https://github.com/stm32-rs/stm32-rs that holds all of the PAC crates. PAC stands for Peripheral Access Crate and provides a type abstraction for what C developers would usually directly do with volatile writes to certain addresses.

Basically what this repo does is:

1. Obtain the SVD files, more specifically https://github.com/stm32-rs/stm32-rs/tree/master/svd in here you will find a directory full of ZIP files by STM
2. Next up it applies the YAML based patch format from here https://github.com/stm32-rs/stm32-rs/tree/master/devices and here https://github.com/stm32-rs/stm32-rs/tree/master/peripherals to the extracted SVD files
3. Then it uses https://github.com/rust-embedded/svd2rust/ this tool in order to turn the SVD file into lots of Rust types and methods
4. And finally some formatting tools etc. to "beautify" the code a little bit

It is indeed possible that just adding your new SVD files to the vendor/ directory is already enough, it is most likely the build process will blow up at some point if something else is wrong so you should be able to just go through the README of the stm32-rs repo and try to add the SVD files yourself, then check if it builds.

[mattico]

I've done some work to update to the new SVDs. The good news is that they seem significantly improved over the previous terrible ones. The bad news is that we'll need to remove a lot of the manual patching that has already been done.

[richardeoin]

Thanks for the work on the PAC @mattico, it looks pretty good already! I'd definitely like to collaborate on this, and hopefully it's not too much work to finish off your PR (stm32-rs/stm32-rs#554)

@TomDeRybel Great that you're interested in helping! As well as the work to update the PAC, I'll make a branch on this repo for updates to this HAL. Once the PAC work is done, the HAL branch would be a good place to contribute

[TomDeRybel]

Thanks for the fast responses to all of this!

When I've got my target board ready (about one month from now), I'll start using the PAC/HAL code for my project and report/contribute what I may encounter.

[ElektroVirus]

Hello,

I am glad to find that the support for stm32h735 has been started. However, I would appreciate some assistance.

I have a STM32H735-DK development board, and I'm trying to get the example blinky.rs run on it. I took the branch stm32h725_735_730 and mattico's pull request for the PAC . I configured this HAL library to use the new PAC by adding in this projects Cargo.toml the line stm32h7 = { version = "^0.13.0", path = "../tmp/stm32-rs/stm32h7" }, where the mattico's PACs Cargo.toml is located.

I also had to modify the examples/blinky.rs, since the LEDs are on Port C (pins 2 and 3) on this development board. Replace GPIOE with GPIOC and change pin number accordingly to 2 or 3.

I can compile the examples with a few warnings and no errors by running
cargo build --features=stm32h735,rt --examples
as expected. However, when I'm flashing the binaries to the board with st-util and arm-none-eabi-gdb the LEDs just won't light up.

In first terminal I run the st-util server:
$ st-util

And in second terminal I connect to it to flash the executable to the board.

$ arm-none-eabi-gdb target/thumbv7em-none-eabihf/debug/examples/blinky
(gdb) target extended localhost:4242
(gdb) load
(gdb) continue

And I'm getting some cryptic messages from gdb:

(gdb) target extended localhost:4242 
Remote debugging using localhost:4242 
0x0800b61e in core::ptr::read_volatile<u32> (src=0x58024804) 
   at /rustc/a435b49e86d16e98dcc6595dd471f95e823f41aa/library/core/src/ptr/mod.rs:1051 
1051    /rustc/a435b49e86d16e98dcc6595dd471f95e823f41aa/library/core/src/ptr/mod.rs: No such file or directory.

If I try to step the code, I get more messages like that.

I really don't have a clue why this doesn't work and have been stuck here for days. Needless to say, I'm really frustrated. I'm new to ARM and from Rust I have the amount of knowledge of Rustlings https://github.com/rust-lang/rustlings.

I hope I get this working, I'd be happy to contribute to this project.
Elias

[richardeoin]

Hi Elias!
Very nice that you're trying out the stm32h735 support already. Your Cargo.toml setup sounds correct, as you've found out it requires this change until at least the PAC support is merged into stm32 master.

The cryptic messages from gdb are a known issue. The debugonomicon briefly discusses them in this section, that should help solve your problem and get a working gdb.

For the STM32H735-DK, I suspect you're not setting the power bits for the SMPS correctly. The examples in the HAL should support boards that have an LDO (some Nucleos) as well as boards that have a SMPS (other Nucleos, and larger boards like the STM32H735-DK). Unfortunately even the most basic examples require different power bits, and the H7 itself can't detect how the traces on the board are connected (or at least I don't know how, I wonder if it's possible..)

Therefore in the HAL we currently have some feature flags to help build the examples for each board layout. There's some more documentation in examples/README.md, but in short for the STM32H735-DK you need to build the examples with cargo build --features=stm32h735,rt,example-smps --examples. And you need to power cycle the board for the new power bits to take effect.

Contributions are very welcome, and particularly any documentation that would make things easier for beginners!

[ElektroVirus]

Thank you Richard, I got this working with these tips. :)

[TomDeRybel]

Thanks again for starting the support for the newer H7 processors!

I've done some testing on a ST Nucleo-H743ZI2 board (STM32H743v), because I'm still waiting on parts to complete the H725 prototype. Except for the gotcha of needing svd2rust 0.17.0 to build the crate, this all went well.

The test project uses probe-run with defmt-rtt, and RTIC 0.6.0-alpha4. The test includes GPIO, an external interrupt, and USB. No change in behavior compared to the normal crate, except for one warning that now occurs when building the project:

warning: associated function is never used: `new`
   --> /home/tomr/workspace_RoboCow_Rust/stm32-rs-update-stm32h7/stm32h7/src/generic.rs:162:19
    |
162 |     pub(crate) fn new(bits: U) -> Self {
    |                   ^^^
    |
    = note: `#[warn(dead_code)]` on by default

Another thing that may or may not have to do with the crate is this: I can't get USB interrupts to work on OTG2, which is the USB port that is wired on the Nucleo board I have. Polling USB works for OTG2, but the interrupt never fires. OTG1 does, however, trigger interrupts. (This is the same behavior with the old crate.)

Looking at the crate build results, I notice that in "stm32-rs-update-stm32h7/stm32h7/src/stm32h743v", there is only a directory structure for OTG1, and none for OTG2. This part has both the OTG1 and OTG2 peripherals. Given that everything builds just fine with OTG1 and OTG2 peripherals referenced in the code, this is probably fine?

Anyhow, if this is relevant, I have a bug report on this here: stm32-rs/synopsys-usb-otg#13
The bug report also includes example code that demonstrates the issue.

[maxekman]

Should this issue be closed after #235 was merged?

[richardeoin]

Yes - thanks for the reminder!