STM32 MCUs Wireless

HiI recently received a NUCLEO-WB55RG (the big board, not the USB dongle) and tried installing the demo from the STM32CubeWB repository.I saw that I need to flash the FUS + Stack first which I did. STM32CubeProg reports FUS State: FUS_IDLEFUS Status: FUS_NO_ERRORFUS Version: V2.2.0.0STACK Version: V1.24.0.3STACK Address: 0x80D0000FUS Operator: v3.1.0The files I flashed were:STM32CubeWB-master\Projects\STM32WB_Copro_Wireless_Binaries\STM32WB5x\stm32wb5x_BLE_Stack_full_fw.binSTM32CubeWB-master\Projects\STM32WB_Copro_Wireless_Binaries\STM32WB5x\stm32wb5x_FUS_fw.binAs application I chose the p2pServer applicationSTM32CubeWB-master\Projects\P-NUCLEO-WB55.Nucleo\Applications\BLE\BLE_p2pServer\Binary\BLE_p2pServer_reference.hexWhen I disconnect the SWD Interface and press the reset button I get the following output (nothing else):Wireless Firmware version 1.24.0 Wireless Firmware build 3 FUS version 2.2.0 >>== SHCI_SUB_EVT_CODE_READY >>== SHCI_SUB_EVT_CODE_READY - FUS_FW

Hi, I have 2 questions here for help.1.)We encountered 2 x AAA batteries drained out very fast problem feedback by our customer. In order to resolve this problem I enabled STOP2 mode and added in the following 2 lines of codes in function “APP_Zigbee_NwkForm()” which following exactly the sample project did (Zigbee_OnOff_Client_SED). As the result I can see the battery consumption dropped significantly from mA to uA. However, during the functional test, noticed the device always encountered hardly wake up from the STOP2 mode after multiples times of button pressing action. I cannot find much information about these 2 lines of codes therefore request ST’s expertise to help up. Our production line has stop and waiting for my firmware update in order to resume.  /* Add End device configuration */config.capability &= ~(MCP_ASSOC_CAP_RXONIDLE | MCP_ASSOC_CAP_DEV_TYPE | MCP_ASSOC_CAP_ALT_COORD);config.endDeviceTimeout=ZED_SLEEP_TIME_30S;   2.)I noticed that, after added in these 2 lines

Hi, I have a custom board with a STM32WB55RG and I’m trying to upgrade the Wireless stack (and the FUS firmware) from a user application (and so without using STM32CubeProgrammer).I'm following the Application Note AN5185.The current FUS version is v1.2.0 and I try to upgrade the stm32wb5x_BLE_Stack_full_fw firmware (v1.14.1 or v1.15 or v1.16).I'm able to send the FUS_GET_STATE command and it returns successfully:the response (HCI command complete event packet) is well formatted, Num HCI is 0xFF, Cmd opcode is 0xFC52 (FUS_STATE) and FUS State value is 0x00 (FUS_STATE_IDLE).I'm also able to send the FUS_FW_DELETE commands:Response command opcode is 0xFC55 (FW_DELETE_STATE), status value is 0x00 (Operation started). Before the delete, SFSA was 0xCE and after complete, the SFSA is 0xf4 Read FUS Infos from STM32CubeProgrammer shows valid STACKS version/address before and v0.0.0.0/NA after the delete.→ The communication to the FUS though IPCC looks to work as expected for the get state and

I am using three Nucleo-WL55JC1 boards running software based on the dual-core SubGHz-pingpong example in LoRa mode.The SDK I am using is STM32CubeWL Ver. 1.5.0.The settings used are BW=125 kHz and SF=10.The first board initiates the sequence, transmitting a 16-byte packet every 10 seconds and then switching to receive mode.The second board acts as a receiver and sends a response upon receiving a packet.The third board is receive-only and monitors the communication status. If the second board does not send a response, the first board transmits packet without issues.However, if the second board does send a response, the first board sometimes fails its subsequent transmission, depending on the timing of that response. If the second board responds within approximately 150 ms of receiving the packet, the first board operates correctly.If the second board responds after a longer interval, the first board may fail to transmit the next packet.Observation with a spectrum analyzer shows that th

SummaryOn an STM32WL5MOC-based LoRaWAN end node, we've measured a consistent ~100 ppm RTC drift on the module's integrated LSE (32.768 kHz) crystal — noticeably outside the commonly quoted ~±20 ppm room-temperature tolerance. We isolated this down to the RTC hardware itself through several independent tests before concluding it's a genuine crystal characteristic (or specific to this device/batch) rather than a software or configuration issue. Posting to ask whether ~100 ppm is within expected variance for this SiP's integrated crystal, or worth escalating further.ConfigurationMCU: STM32WL5MOC (Cortex-M4 side) RTC: RTC_BINARY_MIX mode, PREDIV_A=31, PREDIV_S=1023 (10-bit synchronous prescaler) RTC clock source: LSE — confirmed selected and ready (RCC_FLAG_LSERDY, __HAL_RCC_GET_RTC_SOURCE()) before proceeding; HAL_RTC_MspInit() itself calls Error_Handler() if LSE isn't ready/selected, so normal boot already implies this passed. Application: LoRaWAN Class A end node (US915), periodic uplin

Hello everyone,I'm developing a LoRaWAN end-device based on the STM32WL using the official ST LoRaWAN stack, and I'm facing a reproducible freeze that only happens with ChirpStack, not with TTN.EnvironmentMCU / Board: STM32WL55JC Stack: STM32Cube_FW_WL — APPLICATION V1.3.0, MW_LORAWAN V2.5.0, L2_SPEC V1.0.4, RP_SPEC RP002-1.0.1 Region: AU915 (sub-band 1, channels 0–7 + 64) Activation: OTAA, Class A, unconfirmed uplinks every 30 s Same hardware and same gateway used in both testsProblem On ChirpStack, after the join the device sends only 4–5 uplinks and then freezes permanently: it stops transmitting and never recovers. Current measurement shows the radio stuck at ~14 mA (looks like it stays in RX), while a normal TX peak is ~74 mA.Key observation The freeze always happens right after ChirpStack sends LinkADRReq commands. In my logs, ADR ramps the TX power (PWR 0 → 2 → 5 → 7) on consecutive uplinks, and the device locks up on a frame where both RX1 and RX2 time out. The device answers L

Hi ST community,We are currently evaluating STM32WB05 vs STM32WB09 for an application involving continuous BLE data streaming from multiple sensors, and would appreciate guidance from experts who have worked with STM32WB0 series.The reason we choosing the STMWB05 over STM32WB09 MCU, STM32WB05 MCU comes at a lower cost.In brief our application sensor are2x IMU LSM6DSO sensors (high-frequency sampling)1x magnetometer1x analog force sensorA single BLE connection (no mesh or multi-node), with frequent sync occurring approximately every three minutes.Key Questions1. WB05 vs WB09 for continuous BLE streamingBoth MCUs seem to have similar BLE capabilities (Bluetooth 5.4, 2 Mbps PHY), but:Does WB09 (larger RAM/Flash) provide significant advantage for:Continuous streamingBufferingReducing packet drops?Has anyone faced RAM bottlenecks or BLE throughput instability on WB05, WB09 in such use cases?2. Single-core architecture suitabilityBoth WB05 and WB09 are single-core Cortex-M0+ with radio

I get the following error If i take the code from github shared by ST for Nucleo Lora it compiles. But when i am trying to do some changes by mixing the code from Cube Mx i get the above error. Can anyone please help to resolve the above issue.  

I tried building and flashing the sample project BLE_TransparentMode to verify Direct Test Mode on the Nucleo-WBA25CE1, but it doesn't work properly.When I connect using STM32CubeMonitor-RF, an error pops up and the application terminates.Sending 0x93, 0x94 (TX, 2440 MHz, PRBS9) from the terminal yields no response.Two COM ports appear, but connecting to either one results in the same outcome.How can I enable Direct Test Mode?  

After I flashed stack into wrong address,NUCLEO-STM32WB55 connected successfully to stm32CubeProgrammer but warned “Data read failed”.I tried to erase or progarm app & stack,both failed.The OB RDP=0xAA,how to solve it? 15:24:49 : Disconnected from device.15:24:50 : UR connection mode is defined with the SWrst reset mode15:24:50 : ST-LINK SN  : 0667FF50565580668708221415:24:50 : ST-LINK FW  : V2J43M2815:24:50 : Board       : P-NUCLEO-WB5515:24:50 : Voltage     : 3.26V15:24:50 : SWD freq    : 4000 KHz15:24:50 : Connect mode: Normal15:24:50 : Reset mode  : Software reset15:24:50 : Device ID   : 0x49515:24:50 : Revision ID : Rev Y15:24:50 : Debug in Low Power mode enabled.15:24:50 : UPLOADING OPTION BYTES DATA ...15:24:50 :   Bank          : 0x0015:24:50 :   Address       : 0x58004020 15:24:50 :   Size          : 96 Bytes15:24:50 :   Bank          : 0x0115:24:50 :   Address       : 0x58004080 15:24:50 :   Size          : 8 Bytes15:24:50 : UPLOADING ...15:24:50 :   Size          : 4 Byt

RAK3172 + ChirpStack FUOTA: Class-C session confirmed active, but zero radio IRQ activity (no RxDone / RxTimeout / RxError) — multicast fragments never received on one of two identical devicesSummaryI have two identical devices (same firmware, same hardware BOM) running FUOTA over LoRaWAN using a RAK3172 module (STM32WLE5-based, AT-command slave) driven by an STM32H7 host MCU. One device completes FUOTA perfectly every time. The second device — same code, same ChirpStack FUOTA deployment, same gateway — gets all the way to a confirmed Class-C switch and then receives nothing. No fragments, no radio errors, nothing.I’ve isolated this down to the radio IRQ level and would like input from anyone who has hit something similar with RAK3172 / STM32WL Class-C behavior.SetupEnd device MCU: STM32H7 (host), communicating with RAK3172 over UART using AT commands LoRa modem: RAK3172 (STM32WLE5 based), running STM32CubeWL / LoRaMac-node stack LNS: ChirpStack v4.17.0 (self-hosted) FUOTA: ChirpStack

I have an STM32WBA data logging project loosely based on the BLE heart rate project. I sync the RTC via either a BLE message, or NTP from a serial modem. All good; works well and the RTC timestamp ticks along whilst the code is in stop2 sleep. The device is battery-powered, so power is always present. I initialise the RTC in RTC_BINARY_ONLY mode.I track whether the device has received a time sync by stashing a value in one the the backup registers.When the device is reset by a button on the reset line, the RTC gets set to zero. This is not a problem.However, when the device resets by calling NVIC_SystemReset(), the RTC appears to be 4194304 seconds ahead of where it should be. This is 4096 x 1024 seconds. I set the RTC frequency to 1024, so I'm guessing this is something to do with it? My code can handle this after a reset by setting the RTC back by 4096x1024 seconds.What is a more tricky problem is that if the device has been in stop2 mode, and is then woken and reset by&nbs

I’m working with the NUCLEO-WL33CC2 development board and running ST’s CLI demonstration firmware. My goal is to retrieve raw baseband I/Q samples, but I can’t get any I/Q output using the demonstrator commands, specifically IQDump.  If you’ve successfully extracted I/Q from this board using the stock CLI demo, I’d love to know the exact command sequence and any quirks you ran into. Suggestions welcome on required modes, baud rates, or additional steps I might be missing.

Hello, We have a custom board with a STM32WB55VGY MCU on it.Originally, the FUS version that runs on it is 1.2.0 and we would like to upgrade the FUS and flash the latest version of the Wireless stack (BLE stack full) and safe boot.So, using the STM32_Programmer_CLI we run the following commands:STM32_Programmer_CLI -c port=swd -startfus STM32_Programmer_CLI -c port=SWD -r32 0x20010010 1 Read 0x20010010 : 01020000 → FUS version 1.2.0 STM32_Programmer_CLI -c port=SWD -fwupgrade stm32wb5x_FUS_fw.bin 0x080EE000 firstinstall=0 STM32_Programmer_CLI -c port=SWD -r32 0x20010010 1 Read 0x20010010 : 02020000 → FUS version 2.2.0 STM32_Programmer_CLI -c port=SWD -fwupgrade stm32wb5x_Safeboot_fw.bin 0x080F2000 firstinstall=0 STM32_Programmer_CLI -c port=SWD -fwupgrade stm32wb5x_BLE_Stack_full_fw.bin 0x080D0000 firstinstall=0All commands run successfully except for the SafeBoot where it returns the following error:Error: FUS_ERROR_INVALID_OB: Option bytes and UFB values do not match.Error: Old Fi

I am really very new to wireless communication but i need to make the project up and working. I have purchased 2 Wio E5 boards, getting confused how to build and make it working. I have gone through two gitshubs STM Repository and the seed studio repository  seedrepository At present i am looking for point to point communication. I found similarities with both the projects for example BSP folders for nucleo and LoraE5mini, i understand is i have to port the code, i tried hard but it is showing compilation errors. Please recommend me how do i proceed in terms of compilation.

Hello,We have designed a custom RF module based on the STM32WL33, and one of ourcustomers is asking us to demonstrate that the RX sensitivity of our modulematches the values published in the datasheet:  - RX sensitivity @ 1% BER:      -132 dBm @ 300 bit/s, 433 MHz, OOK      -128 dBm @ 300 bit/s, 868 MHz, 2(G)FSK      -112 dBm @ 38.4 kbit/s, 868 MHz, 2(G)FSKTo validate this, we would like to reproduce the exact test conditions usingan official ST development board (e.g. NUCLEO-WL33) and theSTM32WL33 GUI, so the result is directly comparable to thedatasheet.In the GUI's "Radio settings" tab we can set: fc, DR (ksps), Fdev (kHz),CHF (channel filter bandwidth, kHz), modulation (OOK/2(G)FSK/4(G)FSK/ASK),Spread Factor, and Pout.Could you please help us with the following:1. What DR / Fdev / CHF / Spread Factor values did ST use internally to   characterize each of the three sensitivity points above? In particular:     - For -132 dBm @ 300 bit/s / 433 MHz / OOK: Under the test conditions of 1

Hello ST Community,I would like to report a bug in the code generated by STM32CubeMX 6.17.0 for the STM32WBA55 with firmware package STM32Cube FW_WBA V1.9.0. Environment- MCU: STM32WBA55CGU6- CubeMX: 6.17.0- Firmware package: STM32Cube FW_WBA V1.9.0- Toolchain: Keil MDK-ARM V5.37- Middleware: STM32_WPAN (BLE Basic stack) Problem descriptionThe application crashes with a HardFault after approximately 2 minutes of operation. The fault is caused by a NULL function pointer call in the generated file `Utilities/tim_serv/STM32_timer.c`, inside `UTIL_TIMER_IRQ_Handler`. Suggested fixAdd a NULL guard before the callback invocation in `UTIL_TIMER_IRQ_Handler`:if( currentExecutionHead->Callback != NULL ) {    currentExecutionHead->Callback(currentExecutionHead->argument);} NoteThis issue appeared after migrating from FW_WBA V1.6.1 to FW_WBA V1.9.0. The same project worked correctly with the previous version.

Hi,I am working on a Matter-over-Thread firmware project on the NUCLEO-WBA65RI / STM32WBA65RIVx, and I am seeing an issue where the Amazon Alexa app does not detect the board during Matter commissioning.My current environment is: Board: NUCLEO-WBA65RI MCU: STM32WBA65 STM32Cube FW_WBA: V1.9.0 X-CUBE-MATTER: V1.6.0 STM32CubeIDE: 1.17.x Commissioner being tested: Amazon Echo 4th Gen, model L4S3RE Matter / connectedhomeip version: v1.3.0 as packaged in X-CUBE-MATTER V1.6.0 The device boots correctly, Thread and Matter initialize, and the commissioning window opens. From UART logs I can confirm: Thread task starts successfully Matter task starts successfully BLE stack initializes successfully Matter BLE advertising starts Matter service UUID 0xFFF6 is present in the advertising payload Manual pairing code and QR payload are generated Fabric count is 0 Commissioning window opens successfully The device is also visible in BLE scanner tools such as nRF Connect. nRF Co

Hi ,I generated a new STM32F407 project using STM32CubeMX.However, I cannot find I-CUBE-LRWAN under Software Packs or Middleware for the STM32F407G-DISC1 board.From what I understand, CubeMX only exposes I-CUBE-LRWAN for certain STM32 devices such as:STM32WL series B-L072Z-LRWAN1 Discovery Kit Some STM32L0/L4 examplesbut not for STM32F407.Because of this, I am unsure about the correct integration method.What I have DoneCreated a new STM32F407G-DISC1 project in STM32CubeMX. Configured the required peripherals (SPI, UART, GPIO, RTC, etc.). Added the SX1262 driver from the following repository: https://github.com/Saba-abiri/LORA1262 Identified and copied the required I-CUBE-LRWAN source files into my STM32F407 project. Resolved most of the compilation errors after integrating the middleware. Successfully built the project.Although the project now builds successfully, I am still unsure whether the middleware has been ported correctly because the LoRaWAN stack does not appear to initializ

I am working on STM32WL55 dual core in which the current consumption is as not as expected as according to the datasheet. It is hardcoded for high power only. and the current consumption is coming for +17dBm and +14dBm as expected which is 58mA and 45mA approax but when switching to the +20dBm and +22dBm it is getting capped at 68mA only. It is not going above 68mA at any way. I have hardcoded it to 22dBm but it is still getting capped to 68mA only. I want to do changes in the code in such a way that the current consumption changes. what are the possible reasons of it and what are the functions where the code modification can help in changing the current consumption. Is there that ST has capped it to +18dBm or +17dBM  and will never work above it? void SUBGRF_SetTxParams( uint8_t paSelect, int8_t power, RadioRampTimes_t rampTime ){uint8_t buf[2];int32_t max_power;if (paSelect == RFO_LP){max_power = RBI_GetRFOMaxPowerConfig(RBI_RFO_LP_MAXPOWER);if (power > max_power){power = max_powe

I'm investigating how to change the TX output power for hardware testing.I was able to confirm that the power changes by writing BLE_TransparentMode to the STM32WBA25 and sending the following HCI command via UART.0x01 0x0F 0xFC 0x02 <EnHighPower> <PowerLevel>However, while Table 468 of AN5270 suggests that it can be set up to +6dBm, there appears to be no change in the actual output between setting it to 0dBm and setting it to +6dBm.0x01 0x0F 0xFC 0x02 0x01 0x190x01 0x0F 0xFC 0x02 0x01 0x1FSetting it to a value lower than 0dBm seems to change the output as expected.Is it actually not possible to set it to a value higher than 0dBm?

I have a design with a CR2032 cell connected to VBAT on the STM32WB5MM module. This was set up using CubeMX and there I enabled the LSE.In my code I am able to set the date and time and observe that it increments as expected. However, as soon I power the circuit down and back up the RTC is reset to the default. I have verified that VBAT is 3.1V.I have not yet tried the backup registers.What am I missing?

System: STM32CubeIDE 2.2.0, Win11 Hi there,I am using the STM32WB09 and I am running the BLE Heartrate OTA Example via debugger.There is only one thing I don’t understand:When I create a release version of this example (= hex file) and execute a “run” command in STM32CubeIDE, the program is running until I powercycle the device. Then suddenly there seems to be an old application in Flash?But when I create a new project, execute the same “run” command the program remains also after powercycle.Here’s a log of my run command with the application which will be reverted back after power cycle: ST-LINK SN : 0044004E3137510E33333639ST-LINK FW : V3J17M11Board : STLINK-V3MINIVoltage : 3.30VSWD freq : 8000 KHzConnect mode: hwRstPulseReset mode : Software resetDevice ID : 0x032Revision ID : Rev ADevice name : STM32WB09NVM size : 512 KBytes (default)Device type : MCUDevice CPU : Cortex-M0BL Version : --Opening and parsing file: ST-LINK_GDB_server_a16044.srecMemory Programming ...File : ST-LINK_GDB

Hello, I created a project (BLE_p2pServer) in STM32CubeMX (6.18.0), but it won't build.Unlike other projects, this project has a folder-like icon in the Project Explorer.I created the project using the same procedure as other projects (BLE_TransparentMode, etc.), so do you know why this is happening?Deleting and recreating the project doesn't change the situation. 

I programmed BLE_TransparentMode to perform RF testing on a custom board equipped with an STM32WBA23.I want to transmit unmodulated CW, but I can't find a way to do this using HCI commands.Is there a vendor-specific command to achieve this? Alternatively, methods such as calling an API or modifying registers would also be acceptable.