Update on dual-core support (#62)

[olback]

An updated version of @richardeoin PR #62 from a year ago.

[noppej]

@richardeoin and @olback ... I am very interested in this functionality. Has there been any conversations about merging this PR? or are their alternative proposals under discussion?

[richardeoin]

There's nothing stopping you using this HAL with both cores already. However, we don't have any opinionated documentation about how you should organise your project (one crate or two, how you should tackle synchronisation and so on). If we had that, and it was aligned with other approaches in the Rust community, then I think we could merge some "official" support for the 2nd core.

[olback]

I feel like there's a few things that needs implementing/documenting before we can "officially" support dual core.

This includes:

• Core communication (See Chapter 11 (HSEM) in RM0399)
• Core1 startup methods (Boot from 0x08100000 or boot from function pointer)
• Proper documentation, best practices
• Peripherals?

I know there's multi-core work going on in rp-rs/rp-hal. We might be able to borrow some of their ideas/concepts.

[cogsandsquigs]

+1 for dual core support. Currently, I need to run code on both stm32h747 m7 and m4 cores, and it's annoyingly difficult to run code on the m4 without dual-core support in this repository. Has anyone made any progress with dual-core support since last year?

[richardeoin]

Sadly I don't know of any recent progress. There was some very nice work done by japaric at one point, but the code is definitely no longer compatible with the current embedded rust ecosystem https://github.com/japaric/lpcxpresso54114/tree/master

Is it possible that rp-hal has a good implementation at this point? They have an example at least. As suggested by @olback it might be possible to borrow some ideas from there :) Their implementation relies on the RP2040 SIO, so it would still be quite some work to use the H7 HSEM instead.

[olback]

I actually looked into this about a month ago but I didn't get anywhere.

It seems that you can't actually boot from any address you want (as i might have alluded to earlier). The address is defined in the option bytes and is set to 0x08100000 by default. This is very different from the rp2040 where you can specify (any?) address you desire.

In this case, the CM4 is closer to it's own entire system. It has it's own reset vector and NVIC. This means that either:

1. You create a new project targeting the CM4 and use some pre-defined channel to communicate.
2. We create a new #[entry_cm4] (?) and allow both cores to be booted from the same project. This might make it tricky tho as all the code would end up in flash bank 0 unless otherwise specified. This might be fine but not always the wanted behavior (might not be a problem since both flash banks are in the D1 domain). EDIT: After some additional thoughts, this alternative might not be possible at all. How would we tell the compiler that this specific entry/function should use another stack address? 🤔

As for the HSEM part, it probably doesn't matter which way we go since it has to work the same for both cases.

Another problem is peripherals. How do we prevent users from initializing the same peripherals in both cores?

While this reply doesn't actually answer any questions, it might give some insight into what's required to make this work.

[olback]

I would love to work on this, but I have a million other side projects that also "needs" work and I've got "real" work as well.

[cogsandsquigs]

I think it would be easiest (as for now) to just expect users to create two separate crates that get flashed the respective memory addresses of the M7 and M4. The only problem with this that I see, as @olback already said, is making sure we have safe access to the peripherals. I think that for an MVP, it should only focus on getting correct code working on both cores (with respective peripherals), and worry about idiomatic project setup and peripheral initialization later -- for now, we can just tell users to be extra careful with their code :$.

IMO, dual-core support should be something that is more actively worked on, seeing as it is becoming more common among chipsets. IDK how much i'll be able to help (as i'm somewhat inexperienced in this field), but I'll try my best (esp. because dual-core support in rust is something that I'm working on at work).

[cogsandsquigs]

Also @olback I don't know if you'd wanna check this out (given that you have other, more important things going on) but when compiling your fork of this library on the dual-core branch with flags defmt, rt, and stm32h747cm4, I get this error:

❯ cargo embed
   Compiling stm32h7xx-hal v0.14.0 (https://github.com/olback/stm32h7xx-hal?branch=dual-core#add94285)
error: could not compile `stm32h7xx-hal` (lib) due to 2 previous errors
error[E0599]: no method named `trbuff` found for mutable reference `&mut stm32h7::stm32h747cm4::dma1::st::cr::W` in the current scope
   --> /Users/admin/.cargo/git/checkouts/stm32h7xx-hal-4e6b39a90b2b6e43/add9428/src/dma/dma.rs:690:30
    |
690 |             .modify(|_, w| w.trbuff().bit(trbuff));
    |                              ^^^^^^ method not found in `&mut W`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0599`.
       Error Failed to run cargo build: exit code = Some(101).

The APIs for the different cores probably don't match up exactly, so unfortunately that's gonna be something that requires some fiddling to get working :/.

[seisyuu-hantatsushi]

❯ cargo embed
   Compiling stm32h7xx-hal v0.14.0 (https://github.com/olback/stm32h7xx-hal?branch=dual-core#add94285)
error: could not compile `stm32h7xx-hal` (lib) due to 2 previous errors
error[E0599]: no method named `trbuff` found for mutable reference `&mut stm32h7::stm32h747cm4::dma1::st::cr::W` in the current scope
   --> /Users/admin/.cargo/git/checkouts/stm32h7xx-hal-4e6b39a90b2b6e43/add9428/src/dma/dma.rs:690:30
    |
690 |             .modify(|_, w| w.trbuff().bit(trbuff));
    |                              ^^^^^^ method not found in `&mut W`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0599`.
       Error Failed to run cargo build: exit code = Some(101).

The APIs for the different cores probably don't match up exactly, so unfortunately that's gonna be something that requires some fiddling to get working :/.

This error is caused by a missing patch in pac(stm32-rs).
I have created pull request stm32-rs/stm32-rs#958.

Nevertheless, there is a divergence between the nightlies of stm32-rs and the current stm32h7xx-hal, so I think a fresh start is needed.

[Flydroid]

Hi,

I would like to ask for some advice to get a project running on just the M4 core of a STM32H747 (on a Portenta H7 board).
The code is working well on the M7 core.
The rust code on the M4 is intented to be a redundancy to an excisting program (not in rust), which is running on the M7 core.

I have read the different pull requests and looked at the dual-core-demo repo by @adamgreig. I know that the memory.x file needs to be correct for the Flash2 adress (0x08100000), which is also the flash location for the M4 binary, but I don't have further experience with linker files (but happy to learn).

Using the arduino examples I'm able to get code running on both cores. The M7 is there booting the M4 core, however I'm not sure if that is always required or a configuration can be set, for them to boot indeviually.

I would be happy to contribute with more testing to the development of the dual core functionality, if someone has some tipps on how to get a simple rust program running on the M4.

[eldruin]

@Flydroid Using both cores in an STM32H745 was done recently in a master thesis by @Goldan32. The thesis contains an interesting discussion of the possibilities in the ecosystem at the moment. The project code is here.

[Flydroid]

@Flydroid Using both cores in an STM32H745 was done recently in a master thesis by @Goldan32. The thesis contains an interesting discussion of the possibilities in the ecosystem at the moment. The project code is here.

@eldruin Thank you for the tip! @Goldan32 your thesis is a treasure trove! Awesome work!
Now I'm thinking I might rewrite my excisting application for the M7 also in rust.
I hope I can come back to you if I have questions and maybe we can push some info back to the stm32h7xx-hal repo on dual-core support.