So I didn't twig that stm32l4 and stm32h7 were published from this repo from initially reading the README.md, potentially adding the crates.io badges for each device family to the README.md would make it easier to find the crates.io pages (since the search functionality is occasionally lacking).

If there's a consensus on this I was going to tackle some of the documentation and could slip the badges in with the PR 👍

The iopden bit in ahbenr is missing for stm32f0x0 devices. The stm32f030r8 & stm32f030rc both have this port and it's documented in the reference manual.

EDIT:
The usart6en bit in apb2enr is missing as well

I have encountered this in several STM32F4 svd files (not looked at other series): several fields would be named UARTxRST, but their EN counterpart as well as the field's description would say USART, note the S.

There are several legitimate UARTxRST fields (with matching description and EN), and which xs are wrong varies by device. Also I've never written an svd patch, that's why this is not a pull request, but I'd be happy to provide one with a little guidance! What structure would you suggest for the patch? one per x to be included in the device files, or something else?

Hi there again, I think for mac os the sed command sed -i "" is the necessary format. In your newest Makefile from last night, the command sed -i'' (in single quotes) generates errors. Sorry about giving bad information earlier. I do think using -i.tmp is better but it does generate more bloat, and using double-quotes works; there must be a space between -i and the double-quotes, too.

For example: https://docs.rs/stm32f4/0.1.0/stm32f4/

The features added in https://github.com/onur/docs.rs/pull/73 can be used to make docs.rs build the crates with all features enabled:

[package.metadata.docs.rs]
all-features = true

From what I can tell by the reference manual, the STM32H7x3 uses the same ethernet MAC as the STM32F7x9 and company. The SVD is seriously broken in this regard - it lists the DMA-related registers under "Ethernet_MAC" rather than under an "Ethernet_DMA" peripheral, and all of the other registers are missing entirely.

Is the preferred method for fixing an error this egregious to use the normal yaml patching mechanisms? Just seeking input before I put together a PR. :)

edit
Upon further inspection, the peripheral is not the same as the F7x9. The SVD issues still stand, though.

It should be possible to make some simple svd source files and transformation YAMLs and run unit tests on svdpatch with Travis.

Hi there, I use a mac which has a cantankerous version of sed. Also, svd2rust has changed a bit somehow, or at least it is different on mac. svd2rust seems to not need a pipe anymore, but it only creates a lib.rs file now. Thus, I think your Makefile could be changed a bit without causing harm to users of other OSs:

(1) add a '.tmp' after -i flag in the sed command
sed -i.tmp '1,3d;5,11d;13,16d;23s/interrupt/self::interrupt/'
(2) modify the svd2rust line to be three lines:
svd2rust -i $<
mv lib.rs $@
rustfmt $@

Excerpt from a page (http://www.grymoire.com/Unix/Sed.html#uh-62h) on sed:
"The GNU version of sed allows you to use "-i" without an argument. The FreeBSD/Mac OS X does not. You must provide an extension for the FreeBSD/Mac OS X version."

I think it is a good idea to use form to split devices files (stm32f429.rs) into a folder with subfolder for each module.
I can implement it if you want to 😄

CC rust-embedded/cortex-m-rt#117

At the moment none of these crates are published on crates.io, so you must clone this repository and generate them yourself (see below) before you can use them.

This seems outdated, it's actually how I found this fantastic project. ;)

In the STM32L4x2.svd I found that APB1ENR1 contains an USART1EN bit in position 18, which actually (according to the pdf docs) does enable the third USART and should thus be named USART3EN. (The first USART is enabled by the USART1EN bit in position 14 of APB2ENR, which is correct in the svd file).

I'm not sure of the correct approach to fix this, and haven't checked how many other SVD files do contain this mistake, so I'm not going to make a PR myself.

Hi, I am looking at the peripheral register support comparison tables you mentioned here. Unfortunately they don't include the STM32L4 devices, though they are contained in this repository. I'm not sure whether this is the right place to report the issue, but could you update the pages?

Many (all?) members of the STMF4 family share the same Ethernet peripherals but only the STM32F407 includes the peripherals/eth/eth_dma.yaml fixup leading to discrepancies in the names of some fields:

error[E0599]: no method named `pm` found for type `&mut stm32f4::stm32f429::ethernet_dma::dmabmr::W` in the current scope
   --> src/ethernet/mod.rs:149:18
    |
149 |                 .pm().bits(0b01)
    |                  ^^
    |
    = help: did you mean `fpm`?

The fix is probably to include the .yaml in all models of the F4 family? At least those sharing the same RM0090.

I want to merge the CNT_H and CNT_L 16bit field into one 32bit CNT field. I found the _merge but it reduce the name as CNT_. How can I remove the trailing underscore?
I found the _modify and try to update the description of the field, to reflect its meaning and not was as been merged (the CNT_H description). But this doesn't work. The README says that _modify is done first.

"TIM2":
  CNT:
    # Actualy a 32bit register
    _merge:
      - "CNT*"
    _modify:
      "CNT_":
        name: CNT
        description: Counter value
        value: [0, 4294967295]

Would you please help me?

There are some valuable SVD patches in the stm32f103xx crate that could be adapted to the stm32f1 crate. Among other things they add enumerated values for many fields which currently only have a bits() method in stm32f1.

The patches are a plain patch file against the SVD XML files, so converting them to the format used in this project requires some work.

https://github.com/japaric/stm32f103xx/blob/ca6a494e497a2ab7428a81a60d4fd1035d906977/STM32F103xx.patch

I'm building with the 1.30-beta (as we're heading towards Stable Embedded in Rust 2018) and I get a few errors about the following being unsupported:

#![feature(const_fn)]
#![feature(try_from)]
#![cfg_attr(feature = "rt", feature(global_asm))]
#![cfg_attr(feature = "rt", feature(use_extern_macros))]
#![cfg_attr(feature = "rt", feature(used))]

Is there a roadmap for stable support in Rust 2018?

Many SVD files (for example stm32f405.svd) have IC2PCS and ICPCS instead of IC2PSC and IC1PSC (per RM).

The reference manual RM0385 for STM32F75xxx and STM32F74xxx mentions PLLSAION and PLLSAIRDY bits at bit 28 and 29 of the RCC clock control register (RCC_CR). We need those bits to initialize the LCD controller of our stm32f746 discovery board. However, they are missing from both the SVD file and the generated code.

Previously we used the SVD of the AdaCore project, which can be found here: https://github.com/AdaCore/svd2ada/blob/master/CMSIS-SVD/ST/STM32F7x.svd. This file contains the PLLSAI fields, so I maybe they applied custom patches? (I tried to look through the history of that file, but couldn't find any addition of the PLLSAI bits.)

A use case:
On DBG peripheral registers some field are prefixed with the peripheral name (DBG_). I want to remove the prefix to provide better name. Writing all the fields that need patching by hand is not an option. They are numerous, not always present (not a problem as _modify don't bell on absent fields).

Allowing to use regex matches will allow to express this requirements as follow:

DBG:
  "APB1_FZ":
    _modify:
     "DBG_(.*)":
       name: "$1"

It can be used elsewhere specially on H7 family that has so much registers to rename.
What are your feelings about this idea?

Just wondering for the sake of better focusing my efforts, how often is https://stm32.agg.io/rs/ updated and is an update triggered automatically or manually?

Might be worth if it's not automatic setting up travis to force an update on every merge into master.

I am trying to develop additions to the yaml device file for the stm32h7x3 svd, but I am stuck on an inconsistency. As background, in most of STMicro's svd files, there appears to be a preference of adding an "R" or "r" after a bitfield, as that is consistent with the same practice for registers. (This is not a thoroughly confident assertion, it just looks that way from scanning some random svd files.) For example, a bitfield for GPIOA::MODER is usually moder0 .. moder15.

Unfortunately, and in contrast to most other svds, in the stm32h7x3 svd file, that practice is not uniformly followed: I've found it is mode0 .. mode15, ospeed0 .. ospeed15, lck0 .. lck15, and so on. (The trailing r is missing.) However, in the structs the "R" remains. It seems to me that this inconsistency might lead to errors.

I'd like to make it consistent with the other yaml files because then I could include your gpio_v2.yaml common patch. I could then work through the svd and datasheet to see if other common patches can be assimilated. (There seem to be similar problems, outside of the GPIO blocks.)

I wonder if you could add that function to your patch script? It looks to me like modifying fields cannot be done using wildcard matches right now. Otherwise, I am left with manually updating the bitfields. :( The only other approach I can think of is an individually-crafted sed script.

I am currently going through a university lab focusing on the 32L100CDISCOVERY. This board 'helps you to discover the features of the STM32L100 Value Line.' I would be more than happy to contribute to coverage but I do not know how to.

Currently no SVD files appear to be available for this family.

They seem to be copied from an unrelated register. Therefore support for deleting fields in svdpatch is needed before the correct fields can be substituted.

svd2rust does emit a few warnings for most crates, e.g.

WARNING Some(Ident("ccmr1_input")) overlaps with another register block at offset 24. Ignoring.
WARNING Some(Ident("ccmr2_input")) overlaps with another register block at offset 28. Ignoring.
WARNING Some(Ident("ccmr1_input")) overlaps with another register block at offset 24. Ignoring.
WARNING Some(Ident("ccmr2_input")) overlaps with another register block at offset 28. Ignoring.
WARNING Some(Ident("ccmr1_input")) overlaps with another register block at offset 24. Ignoring.
WARNING Some(Ident("ccmr2_input")) overlaps with another register block at offset 28. Ignoring.
WARNING Some(Ident("ccmr1_input")) overlaps with another register block at offset 24. Ignoring.
WARNING Some(Ident("ccmr2_input")) overlaps with another register block at offset 28. Ignoring.
WARNING Some(Ident("ccmr1_input")) overlaps with another register block at offset 24. Ignoring.
WARNING Some(Ident("ccmr1_input")) overlaps with another register block at offset 24. Ignoring.
WARNING Some(Ident("ccmr1_input")) overlaps with another register block at offset 24. Ignoring.
WARNING Some(Ident("fs_grxstsr_host")) overlaps with another register block at offset 28. Ignoring.
WARNING Some(Ident("fs_gnptxfsiz_host")) overlaps with another register block at offset 40. Ignoring.
WARNING Some(Ident("otg_hs_grxstsr_peripheral")) overlaps with another register block at offset 28. Ignoring.
WARNING Some(Ident("otg_hs_grxstsp_peripheral")) overlaps with another register block at offset 32. Ignoring.
WARNING Some(Ident("otg_hs_tx0fsiz_peripheral")) overlaps with another register block at offset 40. Ignoring.

Should we try to fix these via patches, or is it impossible?

peripherals/eth/eth_mac.yaml says:

  MACMIIDR:
    TD: [0, 0xFFFF]

However the RM0090 says the field is support to be called MD. I guess the reason it is called TD is that some other series (or special sibling) call it TD in the documentation but I'm wondering how we want to treat such discrepancies...

It would be great to easily see what got fixed between, e.g., 0.3.2 and 0.4.0 in human-readable form.
Reference: https://keepachangelog.com

I have 2 questions important for me:

• Do you plan to add support such SVD items as clusters and register arrays.
• If answer is yes or maybe. What if I propose to use other, already patched files instead of official as source (stm32svd-compare).
  What I change? My idea is simple. If you enter All folder, you'll see SVD with cutout peripheral contents.
  I compare if they are identical (I use hash for speed up, naming and easy restore). Then I compare differences manually with difftool (meld is better). Most often these are only description differences. But when I fix them, I can see real issues. So I fixed a lot of typos, unify some field/register names and spent a lot of time. But the biggest change is grouping some registers to clusters (like in CAN, DMA, backup registers an other).

To compose a peripheral from multiple common fields, I try to use the _include. But it does not documents the fields.

I declare the common fields on a separate file:

REG:
   FIELD:
      VALUE0: [0, "description"]
      VALUE1: [1, "description"]

Then I declare the peripheral on its file:

PERIPH:
  _include:
     - ../peripherals/periph/common_field.yaml

I had to use ../peripherals/periph/ path otherwise svdpatch complain it doesn't find the stm32-rs/devices/common_field.yaml file.

The actual problem is that the values are not added to the patched svd file.
Do I need to done something different? If not can you help me to made this functionality working.

Thanks.

modm have a lovely repository of slightly-patched C header files extracted from CubeMX here. It's not beyond the realm of imagination that we could automatically compare the C header definitions to the SVDs, and catch incorrectly named, missing, and surplus entries.

The SVD for STM32L4x1,4x2 contains a USB_SRAM "peripheral", and a USB_FS peripheral which derives from the USB_SRAM peripheral. Unfortunately this isn't correct: USB_FS should have all the registers inside USB_SRAM (RM0394 43.6.1), and USB_SRAM should have a collection of different registers (RM0394 43.6.2). However, the USB_SRAM really is just a big block of memory, and isn't strictly partitioned into registers -- it's more a set of descriptors which can start at any offset.

So the SVD should really contain USB_FS with all the registers currently in USB_SRAM, and USB_SRAM should cease to exist at all, or at least be a peripheral with no registers.

Hey,

I know svd2rust 0.14 has only been out for a few days but it would be great if we could get a new version out so that we can try out cortex-rt-rtfm-v4.

Cheers

As mentioned in #9 a couple of interrupts are missing for this MCU:

• ETH (=61)
• ETH_WKUP (=62)
• PVD (=1)
• TIM1_UP_TIM10 (=25)
• TIM1_CC (=27)
• I2C2_EV (=33)
• I2C2_ER (=34)
• SDMMC1 (=49)
• UART4 (=52)
• USART6 (=71)
• I2C3_EV (=72)
• I2C3_ER (=73)
• CRYP (=79)
• UART7 (=82)
• LCD-TFT (88 or 89, don't know which one)
• SAI2 (=91)
• QuadSPI (=92)
• LP Timer1 (=93)
• HDMI-CEC (=94)
• I2C4_EV (=95)
• I2C4_ER (=96)
• SPDIFRX (=97)
• DFSDM1_FLT0 (=99)
• DFSDM1_FLT1 (=100)
• DFSDM1_FLT2 (=101)
• DFSDM1_FLT3 (=102)

Maybe I'm missing something, but why is the USBFSEN bit named usbf? https://stm32l4.stalder.io/stm32l4/stm32l4x2/rcc/apb1enr1/struct.W.html#method.usbf

Is this possibly a sed gone wrong?

Hi, I seem to have found a bug that when not having the rt flag in features, 600 bytes are added in the vector table where each vector is pointing to the DefaultHandler.

I have tested with the following 2 Cargo.toml configurations:

[dependencies]
panic-abort = "*"
cortex-m-rt = "*"
cortex-m = "*"

[dependencies.stm32f4]
version = "0.2.0"
features = ["stm32f405", "rt"]

and

[dependencies]
panic-abort = "*"
cortex-m-rt = "*"
cortex-m = "*"

[dependencies.stm32f4]
version = "0.2.0"
features = ["stm32f405"]

where the later is consistently 600 byte larger.

This was tested on the latest nightly.
Please tell me if there is something more you want me to test or if there is some further information that you need.

On the STM32H7x3 SVD, the FDCAN1,2 peripherals are fine, but CAN_SRAM and CAN_CCU should differ: CAN_CCU contains a bunch of currently undefined registers, and CAN_SRAM shouldn't contain any registers, it's just a big block of memory.

As the title states, bit 18 in APB2EN should be USART3EN, however it is missing.

Hello,

I'm currently developing with the STM32L475 and came across some errors in stm32l4::stm32l4x5::rcc::apb1enr1 with documentation found here: https://docs.rs/stm32l4/0.4.0/stm32l4/stm32l4x5/rcc/apb1enr1/index.html

The field SP3ENR and _SP3ENW should be SPI3ENR and _SPI3ENW. This misspelling trickles over to other usages like when calling spi3en() which errors and suggests sp3en().

Additionally, the field for the bit RTCAPBEN appears to be missing entirely.

I've checked these against Section 6.4.19 of the STM32L4x5/6 reference manual.

The current svd2rust version is 0.13.1. Could you update the crates.io version to the newest svd2rust version to make it compatile with cortex-m-quickstart?

I tried to regenerate the crates myself, but I got a lot of duplicate definitions with name x errors.

I'm a bit confused after today's update. I was previously unaware that this crate had been published on crates.io. It's actually spread across several crates.io packages (stm32f0, stm32f1, etc), but I don't understand the advantage to splitting it up.

In PR #5 I have attempted to automate the crate code generation via a build.rs script which allows the use of any device-specific backend via the corresponding feature flag. The attempt mimmicks the existing architecture, but I discovered very late in the effort that specifying multiple device feature flags prevents the library from compiling. Thus the build.rs script is able to detect this condition and panic with a more helpful error message.

error: symbol DEVICE_PERIPHERALS is already defined
361729 | static mut DEVICE_PERIPHERALS: bool = false;

With that knowledge I'd like to modify the build script to not combine devices under one lib.rs (I think this would also alleviate the need to call sed which likely causes trouble for building on windows). I'm just starting to play in the embedded rust space so I'm unsure if there are plans to try and fix that limitation. Perhaps it could allow dependent projects to build separate binaries for multiple targets, but it feels like feature flags in the dependent project would be a better implementation.

So, I wanted to open up a discussion regarding the direction of the crate's organization. Is there a reason to prefer splitting the packages? Would consolidating under one package using the build.rs dynamic generation be welcomed? I suppose since the packages have already been published to crates.io there's no way to put the genie back in the bottle.

Thanks for your consideration.

I hate to pester you on late on a Sunday night, but I wonder if you can help me a bit more. I am seeing the same errors I referred to in the svd2rust issue that I closed. For example, it seems to me it should be possible to do this:

let p = stm32h7::stm32h7x3::Peripherals::take().unwrap()
let gpiob = p.GPIOB;
gpiob.gpiob_moder.write ( |w| w.mode7.bits(0) );

However, this generates a predictable error: there is no gpiob_moder field within GPIOB (because it is derivedFrom GPIOA, which does have a gpioa_moder field, naturally). What am I missing?

For the F4 series, F410 and F413 both use I2C2 as the RegisterBlock I2CX type. All other F4 devices use I2C3. For reference, F2 uses I2C2, the rest of the ecosystem uses I2C1.

My naive solution would be to mark one of the peripherals as a new base and provide a name of another to strip everything but name, baseAddress, and the interrupts. These would be moved to the new base and the derivedFrom fields of the other instances would get updated accordingly.

This is in reference to an attempt to handle the 3 I2C peripheral instances generically. (See stm32-rs/stm32f4xx-hal#37)

environment:
rustc: 1.30.0-nightly (4591a245c 2018-09-22)
stm32f3 version: 0.2.3
features = ["stm32f302", "rt"]

  = note: rust-lld: error:
          ERROR(cortex-m-rt): The interrupt vectors are missing.
          Possible solutions, from most likely to less likely:
          - Link to a svd2rust generated device crate
          - Disable the 'device' feature of cortex-m-rt to build a generic application (a dependency
          may be enabling it)
          - Supply the interrupt handlers yourself. Check the documentation for details.

A lib I use svd2rust(0.13.1) to generate from STM32F302.svd can be built

Currently no SVD files appear to be available for this family.

I'm trying to build from commit d1ba710 but the generated code is not syntactically correct.

from the stm32f4 directory "cargo build --features stm32f405" results in
error: unexpected close delimiter: }
--> src/stm32f405.rs:466:1
|
466 | }
| ^

error: aborting due to previous error
error: Could not compile stm32f4.

$ rustc --version
rustc 1.27.0-nightly (ad610bed8 2018-04-11)
$ rustfmt --version
0.3.8-nightly (346238f 2018-02-04)
$ svd2rust --version
svd2rust 0.12.0 (0e9f50f 2018-01-15)

If I delete the excessive } I get other compilation errors.

Hi!

The cortex-m-rt is now 0.6.1 which causes link errors when using this library.
Could you update the deps and push to crates.io?

Thanks!

I was writing some test code and I noticed that I could not set GPIO pins to output because there was not output method for the MODER. I would be more than happy to patch it if someone could explain the project structure to me better.

I've tried various things things now but no matter how hard I try I can't get the interrupt!() macro into scope. Is there any example how to achieve that or is this something that hasn't been tested yet?

I'm in the progress of moving my stm32f042-hal crate from my custom peripheral registers crate over to stm32f0 with the features ["rt", "stm32f0x2"] and everything is working fine except for the interrupts macro...

error: cannot find macro `interrupt!` in this scope
  --> examples/led_hal_button_irq.rs:87:1
   |
87 | interrupt!(EXTI0_1, button_press);
   | ^^^^^^^^^

Looking through svdpatch.py it doesn't appear that it's able to handle modifcations to cpu node children.

For example, stm32f303.svd contains

<cpu>... <nvicPrioBits>3</nvicPrioBits>...</cpu>

However, the reference manual (RM0316, Section 14.1.1) states "4 bits of interrupt priority are used"