Initial STM32WBx5 support.

[rubdos]

I've been toying around with some WB series STMs, which supports concurrent Bluetooth and 802.15.4 comms.

I had been thinking about writing my own async reactor for those MCUs, but it seems like Drone has done most of the work already! This work looks very exciting for me.

This commit adds the STM32WBx5 to the device list and code generator. Feel free to let this hang around until I submit something for drone-cortex-m!

EDIT: Reference manual.

• [x] A nitpick: I think x in Stm32Wbx5 should be in lower case. This will be compatible with the Inflector crate rules. Because Stm32WbX5 would be lower cased to stm32wb_x5.
• [x] Actually test on HW.

[rubdos]

Devices in this series:

• WB55C{C,E,G}: 48 pin
• WB55R{C,E,G}: 68 pin
• WB55V{C,E,G}: 129 pin

the suffix denotes the flash/RAM sizes: 256, 512, 1024 (flash) and 128, 256, 256 (RAM).

I'm wondering what the best method of designating these devices is, but I start to think I should change STM32WBx5 to STM32WB55{C,R,V}x?

[valff]

This is great! I appreciate your effort. Regarding to naming, I think it should be Stm32Wbx5/stm32wbx5. We don't differentiate chip sizes within chip families. RAM and Flash sizes are configured at Drone.toml for each project.

You should also add a variant to the Device enum at src/config.rs. And edit these templates: src/templates/bmp/gdb.gdb.hbs, src/templates/bmp/itm.gdb.hbs, src/templates/bmp/stm32.gdb.hbs. For the last template we need to figure out the initial speed of the MCU. For this the default values of RCC_CR/CFGR registers should be checked first. BTW, do you use Black Magic Probe?

drone-cortex-m doesn't need to be changed. Only drone-stm32-map would need a change, but unfortunately ST hasn't published SVD files for this MCU family. So you will need to manually map desired registers. Or maybe there is a third-party SVD file published somewhere?

[rubdos]

This is great! I appreciate your effort. Regarding to naming, I think it should be Stm32Wbx5/stm32wbx5. We don't differentiate chip sizes within chip families. RAM and Flash sizes are configured at Drone.toml for each project.

Roger that, so it stays as-is then.

You should also add a variant to the Device enum at src/config.rs.

I just found out about that, incoming commit!

And edit these templates: src/templates/bmp/gdb.gdb.hbs, src/templates/bmp/itm.gdb.hbs, src/templates/bmp/stm32.gdb.hbs. For the last template we need to figure out the initial speed of the MCU. For this the default values of RCC_CR/CFGR registers should be checked first.

Roger. I'll read the reference manual carefully for that, since I never changed the default frequency before. I want as far as having a blinking light...

BTW, do you use Black Magic Probe?

Previous experiments were bare-bones with this existing PAC crate, and I used openocd. I'm not sure whether that's easily possible here?

drone-cortex-m doesn't need to be changed. Only drone-stm32-map would need a change, but unfortunately ST hasn't published SVD files for this MCU family. So you will need to manually map desired registers. Or maybe there is a third-party SVD file published somewhere?

The PAC crate above has an svd, and I've pending changes for stm32-map. Incoming PR!

Thanks for your comments :-)

EDIT: for openocd, you need a set of patches, since these new MCUs aren't yet upstream for openocd. If you want, I have a PKGBUILD for a custom openocd build.

[rubdos]

WRT to clock:

RCC_CR:

Reset value: 0x0000 0061 (after POR reset), 0x0000 0160 (after wakeup from Standby reset). (HSEBYP is reset by NRST pad, not reset by wakeup from Standby).

This means that POR turns on the MSI oscillator, and from standby the HSI oscillator gets forced on. MSIRANGE is then 0110, which is 4MHz.

The documentation for RCC_CFGR also seems to indicate the HSI16 clock runs after standby, and the MSI clock at POR.

---

Seems like I can "just" add the device to the list of STM32L4's, as I suspected. Do I need to take action for the post-standby clock mode? Reset, wakeup and shutdown low-power all reset to MSI clock.

[valff]

Roger that, so it stays as-is then.

A nitpick: I think x in Stm32Wbx5 should be in lower case. This will be compatible with the Inflector crate rules. Because Stm32WbX5 would be lower cased to stm32wb_x5.

Previous experiments were bare-bones with this existing PAC crate, and I used openocd. I'm not sure whether that's easily possible here?

Sure, openocd is possible, but drone command doesn't know how to work with it, so you will need to write your own recepies for flashing, debugging and capturing the ITM output in the project-level Justfile. You can use itmsink command directly to parse the ITM output.

The PAC crate above has an svd, and I've pending changes for stm32-map. Incoming PR!

Great! Did you find the SVD file somewhere or created it by yourself?

EDIT: for openocd, you need a set of patches, since these new MCUs aren't yet upstream for openocd. If you want, I have a PKGBUILD for a custom openocd build.

Thanks, but I don't have this MCU currently. I think it's worth to order it now.

Seems like I can "just" add the device to the list of STM32L4's, as I suspected. Do I need to take action for the post-standby clock mode? Reset, wakeup and shutdown low-power all reset to MSI clock.

Great, let's add it to the 4MHz list. For subsequent clock changes in the run-time, the itm::update_prescaler function should be used. This all is needed to maintain a constant baud rate for the SWO pin output. Actually SWO output can be set in Manchester encoding, thus the speed can vary in the run-time, but we've found it as not reliable. And Drone needs a reliable channel for its heap-tracing functionality.

Do you have a separate USB-UART converter? drone utility supports generic UART converters for reading ITM output from the SWO pin.

[rubdos]

Roger that, so it stays as-is then.

A nitpick: I think x in Stm32Wbx5 should be in lower case. This will be compatible with the Inflector crate rules. Because Stm32WbX5 would be lower cased to stm32wb_x5.

Roger.

Previous experiments were bare-bones with this existing PAC crate, and I used openocd. I'm not sure whether that's easily possible here?

Sure, openocd is possible, but drone command doesn't know how to work with it, so you will need to write your own recepies for flashing, debugging and capturing the ITM output in the project-level Justfile. You can use itmsink command directly to parse the ITM output.

I'll have a look at that too!

The PAC crate above has an svd, and I've pending changes for stm32-map. Incoming PR!

Great! Did you find the SVD file somewhere or created it by yourself?

I've found it in that repo, not mine... Probably worth finding out were it comes from: https://github.com/eupn/stm32wb-pac/tree/master/svd

EDIT: for openocd, you need a set of patches, since these new MCUs aren't yet upstream for openocd. If you want, I have a PKGBUILD for a custom openocd build.

Thanks, but I don't have this MCU currently. I think it's worth to order it now.

The nucleo pack comes with two different ones, and seems quite featureful. 40$ iirc, so not too expensive either.

Seems like I can "just" add the device to the list of STM32L4's, as I suspected. Do I need to take action for the post-standby clock mode? Reset, wakeup and shutdown low-power all reset to MSI clock.

Great, let's add it to the 4MHz list. For subsequent clock changes in the run-time, the itm::update_prescaler function should be used. This all is needed to maintain a constant baud rate for the SWO pin output. Actually SWO output can be set in Manchester encoding, thus the speed can vary in the run-time, but we've found it as not reliable. And Drone needs a reliable channel for its heap-tracing functionality.

Do you have a separate USB-UART converter? drone utility supports generic UART converters for reading ITM output from the SWO pin.

I can probably find one in the lab here! I'm gonna pack things up for the weekend now, and have a ton of other stuff to do next week, but this is interesting. I'll finish up the patches maybe tomorrow or during next week!

[rubdos]

wrt the stm32-map: https://github.com/drone-os/drone-stm32-map/pull/2

[valff]

I can probably find one in the lab here! I'm gonna pack things up for the weekend now, and have a ton of other stuff to do next week, but this is interesting. I'll finish up the patches maybe tomorrow or during next week!

Sounds great! I will be on trip next week, and my presence will be restricted to my smartphone. Sorry in advance for my limited availability.

[rubdos]

I have been toying with BMP now. There's the experimental make PROBE_HOST=pc-stlinkv2 that generates src/blackmagic_stlinkv2, which seems to be exactly what I need. There's also a PR for BMP stm32wb55xx support that seems to need a final polish.

In the end, I used openocd, because that had the stm32wb55 support from my previous experiments. I used that to flash the drone-os built firmware. I don't have any ITM feedback now, so I was doing this in the dark.

I changed the root task to illuminate an LED (so it's not in the dark anymore):

    // Set rcc clock
    reg.rcc_ahb2enr.modify(|w| w.set_gpioben());

    reg.gpiob_moder.modify(|w| w.write_moder5(0b01));
    reg.gpiob_otyper.modify(|w| w.clear_ot5());
    reg.gpiob_ospeedr.modify(|w| w.write_ospeedr5(0b00));
    reg.gpiob_pupdr.modify(|w| w.write_pupdr5(0b00));
    reg.gpiob_bsrr.bs5.set_bit();

This is without mapping the registers in stm32-map; I will definitely need some aid there.

So, the code in its current condition is usable as an STM32WB bootstrap!

[valff]

That looks great! I can help you with register mappings on weekends. I will also share an OpenOCD script to display the ITM output.

[valff]

@rubdos Please take a look at this set of tasks for OpenOCD: https://github.com/valff/demo-core-nucleo/blob/master/Justfile

With this you should be able to capture the ITM output (the task is named swo there.)

I'm slightly refactoring drone-stm32-map now. And I will add the STM32WB mapping soon.

[rubdos]

@rubdos Please take a look at this set of tasks for OpenOCD: https://github.com/valff/demo-core-nucleo/blob/master/Justfile

With this you should be able to capture the ITM output (the task is named swo there.)

It's a bit annoying that it depends on dpkg, but I seem to manage it with an AUR PKGBUILD.

just flash seems to just work, so that's really nice! just swo doesn't seem to catch the ITM output just yet, I need to investigate a bit more tonight.

I'm slightly refactoring drone-stm32-map now. And I will add the STM32WB mapping soon.

Nice, let me know where I can help!

[rubdos]

just swo doesn't seem to catch the ITM output just yet, I need to investigate a bit more tonight.

HA, found it. I just had to alter the ITM frequency to the core clock (4MHz)! This is awesome. Now I have println! and I can just flash swo to see the output :-D

[rubdos]

Hi again! My student (@Vanarill) started working on the WB55 Nucleo board. This one and the stm32-map repo got a rebase, and feedback (especially on how to proceed with the peripheral mapping) is mostly appreciated :-)

[rubdos]

We just tested generating a project with drone new --device stm32wbx5 --flash-size 1M --ram-size 192K hello2, and just flash itm worked, albeit we had to push the physical reset button of the device (it's too fast!)

Next up we'll test gdb, but this should be ready for a review at this point. :tada:

[valff]

Thank you for all your work. I already have the WB55 Nucleo board. Will test this soon.

[thvdveld]

I pushed because CoretexM had still a capital M.