[STM32G0B1] Can't compile quickstart

[cfslpower]

Attempting to clean build the quickstart repository for STM32G0B1 using the thumbv6m-none-eabi toolchain fails with many errors: g0_build_errors.txt.
All I have done is clone the repository, change the toolchain, and alter the feature gates in Cargo.toml to "g0b1" and "g0rt". Cargo seems to be building the library against stm32g0 v0.14.0 and cortex-m v0.7.5.

[David-OConnor]

It looks like there's a PAC error on several G0 models including that one, wherein many registers are missing: (stm32-rs/stm32-rs#548). It was fixed in November: (stm32-rs/stm32-rs#666). but hasn't made it into an stm32-rs release yet. So, will need to wait. The last release was October, so I'd say we're due for a new one...

[David-OConnor]

Fixed with PAC update

[David-OConnor]

Nvm still having a struggle with these variants even after the update. Could probably eliminate certain features or fight through it.

[adamt55]

Is there any way I could provide some help here? I tried compiling the stm32g0-crate with the new SVDs from STM released in march, which compiled fine as far as I could tell when I swapped out the SVD for the G0B1. I then tried to link it to the HAL here, but this resulted in the attached buildlog when running cargo build --features=g0b1,usb --lib. New to embedded, so any pointers appreciated.
build_g0b1.txt

Fixed with PAC update

Forgot to mention: When i checked the STM-RS project, they were still using the 1.3 SVDs in their current 0.15.1 release, I tried to swap them out for version 1.5 but this yielded the result above.

[David-OConnor]

That's an easy fix on the HAL side. Before proceeding with that fix, we'd need to get your new SVD build in a stm32-rs PAC release. Any luck convincing those guys to merge/release?

If you'd like to use a fork of this HAL with your custom built PAC and a path or git dep on it, you'd just need to modify the related feature gate code to excempt the relevant G0 variants from the line that uses DMA as DMA1.

[adamt55]

Thanks for the input. I got the SVD patch in the stm32-rs repo and they build their nightly-repo accordingly (no new release yet though). What do you mean by excempting my variant from the DMA as DMA1 line? I wrote a feature gate that disabled those use statements, but I am still getting the same errors. Could you provide me an example/some documentation I could look up?

[David-OConnor]

I just reread your error log. I didn't realize there were multiple types of error:

error[E0432]: unresolved import `crate::pac::RCC`
  --> /home/lpower/.cargo/registry/src/github.com-1ecc6299db9ec823/stm32-hal2-1.4.6/src/adc.rs:12:17
   |
12 |     pac::{self, RCC},
   |                 ^^^ no `RCC` in `stm32g0b1`

That looks like a critical ommission of the PAC that will need to be patched

20 | use crate::pac::dma as dma_p;
   |     ^^^^^^^^^^^^---^^^^^^^^^
   |     |           |
   |     |           help: a similar name exists in the module: `dma1`
   |     no `dma` in `stm32g0b1`

This is a small change to an import line, but it's no longer relevant due to changes I've been making to the DMA API over the past few days.

error[E0432]: unresolved import `crate::pac::dma`
  --> /home/lpower/.cargo/registry/src/github.com-1ecc6299db9ec823/stm32-hal2-1.4.6/src/gpio.rs:32:5
   |
32 | use crate::pac::dma as dma_p;
   |     ^^^^^^^^^^^^---^^^^^^^^^
   |     |           |
   |     |           help: a similar name exists in the module: `dma1`
   |     no `dma` in `stm32g0b1`

This section of the gpio module etc would need to be modified to accomodate b1:

cfg_if! {
    if #[cfg(all(feature = "g0", not(any(feature = "g0b1", feature = "g0c1"))))] {
        use crate::pac::dma as dma_p;
        use crate::pac::DMA as DMA1;
    } else if #[cfg(feature = "f4")] {} else {
        use crate::pac::dma1 as dma_p;
        use crate::pac::DMA1;
    }
}

These errors were from after your the updated SVD? Then the SVD needs to be patched - specifically to add the RCC register block at minimum. Also, I'm surprised about the other errors, as they show a PAC layout different from the other G0s. Using the YAML patch styles you see in PRs on the stm32-rs repo. This can be a little tricky, but shouldn't be too bad once you figure out the syntax. I'm trying to remember how to do it!

[adamt55]

Thanks for the pointers, I will get into trying to fix this issue this weekend. Yes, the log is from after running it with the current SVDs from ST. I will try and see if I can figure out how to port the mapping of the RCC registers in the STM32-RS PAC for the G0B1 from the G071, since the block diagram from the documentation looks very similar.

Also, I'm surprised about the other errors, as they show a PAC layout different from the other G0s.

Is this a function only of the applied patches or also of the ST provided SVDs? I just noticed that the G0B1.yaml doesn't contain a couple of different "common_patches", which are applied to the G071 for example:

 - ../devices/common_patches/adc/g0.yaml
 - common_patches/usart/g0.yaml
 - ./common_patches/adc/g0_typo.yaml
 - ./common_patches/dma/g0_7ch.yaml

[David-OConnor]

I think it's likely the common patches may fix some or all of the problems. What probably happened is the SVD for all G0s had errors; patches were applied to the stm32-rs repo for other G0 variants, but not these.

[adamt55]

Alright, I tried fixing some stuff on the PAC as well as some stuff on the HAL. I am down to these errors, which I cannot really wrap my head around. It seems something with the DMA is screwed, or maybe I named the fields wrong somehow? Do you have some insights on that maybe?
build.txt

I've opened a PR on the PAC here. I'll open a PR on the changes I've made and maybe you could point me to something there.

[David-OConnor]

Nice work!

Re the DMA stuff: It's likely that the PAC is set up differently for these variants, for one reason or another. For example, this error:

error[E0615]: attempted to take value of method `ch1` on type `D`
   --> src/dma.rs:692:46
    |
692 |                         let ccr = &self.regs.ch1.cr;
    |                                              ^^^ method, not a field

Current code:

                cfg_if! {
                    if #[cfg(any(feature = "f3", feature = "g0"))] {
                        let ccr = &self.regs.ch1.cr;
                    } else {
                        let ccr = &self.regs.ccr1;
                    }
                }

Future code:

                cfg_if! {
                    if #[cfg(any(feature = "f3", feature = "g071, g081 (etc)"))] {
                        let ccr = &self.regs.ch1.cr;
                    } else if #[cfg(feature = "g0b1")] {
                        let ccr = &self.regs.ccr1();
                    else {
                        let ccr = &self.regs.ccr1;
                    }
                }

Of note, the DMA module for variants other than H7 is a bit of a mess due to the way the channels are meched in the PAC. The H7 PAC has nice array fields though.