Making STM32WL55 work with Rust

I recently got my hands on a STM32WL55 development kit (NUCLEO-WL55JC2 to be more precise) and wanted to program it in Rust. Since things did not work out of the box and I had to spend many hours figuring out how to make it work, I thought I document the steps I took to make it work for the next person who bumps into this:

Pre-requisites

Note: The target-gen docs instruct how to run it from the repository but it's not necessary and you can install with cargo install target-gen.

Getting Started

Powering up the board is super easy. Just connect the USB cable to the board and your computer. Now if you're as eager as I was, you'll want to already want to try out the lora-rs examples but if you do that already, you'll get an error:

❯ cargo r --bin lora_p2p_receive
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.07s
     Running `probe-rs run --chip STM32WL55JC target/thumbv7em-none-eabi/debug/lora_p2p_receive`
 WARN probe_rs::probe::stlink: send_jtag_command 242 failed: JtagGetIdcodeError
Error: Connecting to the chip was unsuccessful.

The first thing you'll want to do is to disable security (yeah, I know!). To do that, you'll need to run this script:

write(){
  str=""
  for arg do
    str+=" ${arg}"
  done
  /home/user/STMicroelectronics/STM32Cube/STM32CubeProgrammer/bin/STM32_Programmer_CLI -c port=SWD mode=UR -q -ob "${str}"
}

echo RDP: Read Out protection Level 1
write RDP=0xBB

echo RDP+ESE: Read Out protection Level 0 + Security disabled
write RDP=0xAA ESE=0x0

echo WRP: Write Protection disabled
write WRP1A_STRT=0x7F WRP1A_END=0x0 WRP1B_STRT=0x7F WRP1B_END=0x0

echo ------ User Configuration ------
echo nRST: No reset generated when entering the Stop/Standby/Shutdown modes
write nRST_STOP=0x1 nRST_STDBY=0x1 nRST_SHDW=0x1

echo WDG_SW: Software window/independent watchdogs
write WWDG_SW=0x1 IWDG_SW=0x1

echo IWDG: Independent watchdog counter frozen in Stop/Standby modes
write IWGD_STDBY=0x0 IWDG_STOP=0x0

echo BOOT: CPU1+CPU2 CM0+ Boot lock disabled
write BOOT_LOCK=0x0 C2BOOT_LOCK=0x0

echo ------ Security Configuration ------
echo HDPAD: User Flash hide protection area access disabled
write HDPAD=0x1

echo SPISD: SPI3 security disabled
write SUBGHSPISD=0x1

echo SBRSA: Reset default value of SRAM Start address secure
write SNBRSA=0x1F SBRSA=0x1F

echo SBRV: Reset default value of CPU2 Boot start address
write SBRV=0x8000

Making it all work

Now if you run the example again, you'll get a different error:

❯ cargo r --bin lora_p2p_receive
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.07s
     Running `probe-rs run --chip STM32WL55JC target/thumbv7em-none-eabi/debug/lora_p2p_receive`
Error: The flashing procedure failed for 'target/thumbv7em-none-eabi/debug/lora_p2p_receive'.

Caused by:
    Trying to write flash, but found more than one suitable flash loader algorithim marked as default for NvmRegion { name: Some("BANK_1"), range: 134217728..134479872, cores: ["cm4", "cm0p"], is_alias: false, access: Some(MemoryAccess { read: true, write: false, execute: true, boot: true }) }.

That means you're almost there. You just need to tell probe-rs that all but one flash algorithm are the default. I wish this was as easy as setting a CLI arg but unfortunately you need to a tiny bit more:

❯ target-gen  arm -f "STM32WLxx_DFP"
2025-03-16T12:17:56.163918Z  WARN target_gen::generate: Device STM32WL54CCUx, memory region SRAM1 has no processor name, but this is required for a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.163936Z  WARN target_gen::generate: Device STM32WL54CCUx, memory region SRAM2 has no processor name, but this is required for a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.163938Z  WARN target_gen::generate: Device STM32WL54CCUx, memory region FLASH has no processor name, but this is required for a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.164440Z  WARN target_gen::generate: Device STM32WL54JCIx, memory region SRAM1 has no processor name, but this is required for a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.164443Z  WARN target_gen::generate: Device STM32WL54JCIx, memory region SRAM2 has no processor name, but this is required for a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.164445Z  WARN target_gen::generate: Device STM32WL54JCIx, memory region FLASH has no processor name, but this is required for a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.164948Z  WARN target_gen::generate: Device STM32WL55CCUx, memory region SRAM1 has no processor name, but this is required for a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.164954Z  WARN target_gen::generate: Device STM32WL55CCUx, memory region SRAM2 has no processor name, but this is required for a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.164956Z  WARN target_gen::generate: Device STM32WL55CCUx, memory region FLASH has no processor name, but this is required for a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.165458Z  WARN target_gen::generate: Device STM32WL55JCIx, memory region SRAM1 has no processor name, but this is required for a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.165463Z  WARN target_gen::generate: Device STM32WL55JCIx, memory region SRAM2 has no processor name, but this is required for a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.165465Z  WARN target_gen::generate: Device STM32WL55JCIx, memory region FLASH has no processor name, but this is required for a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.166001Z  WARN target_gen::generate: Device STM32WL5MOCHx, memory region SRAM1 has no processor name, but this is required for a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.166005Z  WARN target_gen::generate: Device STM32WL5MOCHx, memory region SRAM2 has no processor name, but this is required for a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.166007Z  WARN target_gen::generate: Device STM32WL5MOCHx, memory region FLASH has no processor name, but this is required for a multicore device. Assigning memory to all cores!
Generated 1 target definition(s):
    /home/user/lora-rs/STM32WL_Series.yaml
Finished in 3.191890047s

Now edit this file and change all default: true lines under flash_algorithms to default: false, except for the one under stm32wlxx_cm4 (the core we want to use). Then edit the .cargo/config.toml file as well and change the probe-rs commandline in it, to make use of this chip description file by adding --chip-description-path STM32WL_Series.yaml to it.

At this point everything should work and you should be able to flash and run the lora-rs examples:

❯ cargo r --bin lora_p2p_receive
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.04s
     Running `probe-rs run --chip STM32WLE5JCIx --chip-description-path STM32WL_Series.yaml target/thumbv7em-none-eabi/debug/lora_p2p_receive`
      Erasing ✔ 100% [####################] 140.00 KiB @  61.45 KiB/s (took 2s)
  Programming ✔ 100% [####################] 139.00 KiB @  41.50 KiB/s (took 3s)                                                                                                                                                                                                                                                                                                                                                                  Finished in 5.63s
0.000000 TRACE BDCR ok: 00008200
└─ embassy_stm32::rcc::bd::{impl#3}::init @ /home/user/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/embassy-stm32-0.2.0/src/rcc/bd.rs:216
0.000000 DEBUG rcc: Clocks { hclk1: MaybeHertz(48000000), hclk3: MaybeHertz(48000000), hsi: MaybeHertz(0), lse: MaybeHertz(0), lsi: MaybeHertz(32000), msi: MaybeHertz(4000000), pclk1: MaybeHertz(48000000), pclk1_tim: MaybeHertz(48000000), pclk2: MaybeHertz(48000000), pclk2_tim: MaybeHertz(48000000), pclk3: MaybeHertz(48000000), pll1_p: MaybeHertz(0), pll1_q: MaybeHertz(48000000), rtc: MaybeHertz(32000), sys: MaybeHertz(48000000) }
...

Comments

Post a Comment

Popular posts from this blog

Welcome to the virtual world!

Image
About two months ago I informed  the followers of this blog that I will now be working on SPICE project  for Red Hat . Judging from the questions I was asked after that, I realized that not many people know about SPICE so I thought I write at least one blog entry dedicated to explaining what SPICE is all about. Before I get to SPICE itself, let me first introduce you to the world SPICE lives in. Virtualization and Virtual Machines (VMs) For some reason, I feel that I should leave the definitions to wikipedia  and only quote it so that is what I am going to do: " Virtualization, in computing, is the creation of a virtual (rather than actual) version of something, such as a hardware platform, operating system, a storage device or network resources. " " A virtual machine (VM) is a "completely isolated operating system installation within your normal operating system".Today, this is implemented by either software emulation or hardware virtualization ". V...
Read more

clutter-gst

After I was informed about the existence of ClutterGstVideoSink, I quickly modified my super-video application to make it use that. But as soon as i did that, i stopped getting even the static image. After careful analysis for days, I figured that I was supposed to call gst_bus_add_signal_watch() on the pipeline bus since ClutterGstVideoSink uses messages on the bus combined with signal handlers to render the frames in the application thread. This is obviously a 'dirty' hack; a hack because gst elements are supposed to do all the media processing in the pipeline thread, dirty because gst bus is not meant for media transport. After this realization, I had been working on it from time to time. First I tried to make the actual rendering happen in the gst pipeline thread by using the clutter's thread safety primitives and that worked quite nicely in the end except for one minor problem: The call to clutters rendering thread blocks if it happens after the clutter main loop has b...
Read more

Shame Ubuntu shame

I am no more a fan of Ubuntu. The reason is their recent demonstration of lack of community spirit. Here is the release announcement of Ubuntu hardy alpha6. If you scroll-down you can see the gnome-system-monitor's new cool "Resources" view featured with a nice screenshot. Since Karl-Lattimer worked really hard to make this happen, he asked to be given personal credit on that page. Don't know about others but I see this as a very reasonable thing to ask. The result of this request can be seen in the announcement of hardy beta. They just removed the feature from the announcement. Shame Ubuntu shame. UPDATE: It's interesting how most of the comments that are from people who got pissed without actually caring to understand the main point of this blog entry (which me and Karl-Lattimer tried to emphasize in the comments) are posting as Anonymous. :) Acknowledging the possibility that they might not think comments are worth reading before commenting, let me make it c...
Read more