Ask questions and discuss STM32 wireless solutions and their implementation for running Bluetooth LE, Zigbee, LoRaWAN applications.
Most recent activity
Please go and visit our wiki pages where you can find a lot of information on our wireless product families (WB, WBA, WL) and the supported protocols: BLE, Zigbee, Thread, Matter, Lora, ... To begin your technical journey, please start from this top page: https://wiki.st.com/stm32mcu/wiki/Category:Connectivity This top page will guide you to the first steps to develop a wireless application using connectivity protocols on ST wireless microcontrollers. For BLE protocol, please visit: https://wiki.st.com/stm32mcu/wiki/Connectivity:Introduction_to_BLE_with_STM32https://wiki.st.com/stm32mcu/wiki/Connectivity:Introduction_to_Bluetooth_LE_Audio You can find information on BLE Certification, BLE Features, BLE Mesh, BLE Audio, … For Zigbee protocol, please visit: https://wiki.st.com/stm32mcu/wiki/Connectivity:Introduction_to_Zigbee You can find information on Zigbee certification, Zigbee Features, BLE-Zigbee concurrent mode, … For Tread protocol, please visit: https://wiki
Dear all, The X-CUBE-MATTER Expansion Package is now available on our official website following this link MATTER - Matter software expansion for STM32Cube - STMicroelectronics It is a reference implementation for the demonstration of Matter on STM32. It is ready for prototyping a Matter end-device on a reference development platform. Refer to STMicroelectronics Matter wiki articles at https://wiki.st.com/stm32mcu/wiki/Connectivity:Introduction_to_Matter to get started with matter for the supported STM32 platforms. Kind regards, Ouadi
Hi,I have custom PCB with STM32WB5MMG, which has STM32WB55VGY. I want to update FUS and software stuck and I would like to confirm which start address is the correct one. Should it be the one from the column STM32WB5xxG(1M) (as the chip is STM32WB5MMG) or the one from column STM32WB5xxY(640k) (as the MCU is STM32WB55VGY)?
HiI just noticed an error in the STM32WB5MM-DK User Manual V5 UM2825:In “Table 19. ARDUINO® connector pinout” there is the signal PE3 at pin 5 of the CN4 connector.The EXTI3_IRQHandler of my project and the Board Schematic V2 MB1292-D01 say otherwise: Its actually PE4.Just letting you know. I was not sure where to input this information and chose to open this thread to have it placed.Maybe someone else might save some time by finding this.Best regardsManuel
I’m trying to migrate a project from the P NUCLEOWB55 MB1355 board to the P NUCLEOWB55 MB-1293 USB dongle.I retargeted the board in MX & check the pinouts etc, all fine. Opened up the project in CubeIDE & built the project.I then switched the board to BOOT0=0 (SW2) & plug it in & open CubePrgFirst issue, its really hit & miss if Prg detects the board. Most often I get Port: No DFU detected but then sometimes I actually get Port: Port 1 and the board can be connected to. It really appears to be pot luck if Prg decides it can connect.If I do manage to get it to connect, I update the FUS & stack, press the Start Stack button as outlined in a previous question, and continue to upload my *.elf file.Second issue, I get nothing from the BLE, no advertising at all. This project works fine on the MB-1355 board by the way.
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
Hello STM32 Community,I am encountering an issue on an STM32WL project using the ST LoRaWAN Middleware stack. When I enable and call MX_LoRaWAN_Init(), the MCU gets stuck or enters an infinite loop inside modem_supervisor_init() in modem_supervisor_light.c.Environment DetailsMCU: STM32WLE5CCU6Board: RAK3172 ModuleCubeMX / Firmware Package: STM32CubeWL v1.6.0Problem DescriptionWhen calling MX_LoRaWAN_Init(), execution fails inside modem_supervisor_init(). Debugging shows execution stuck in the for loop below : void modem_supervisor_init( void ){ memset( &task_manager, 0, sizeof( stask_manager ) ); for( uint8_t i = 0; i < NUMBER_OF_TASKS * NUMBER_OF_STACKS; i++ ) { task_manager.modem_task[i].priority = TASK_FINISH; task_manager.modem_task[i].id = ( task_id_t ) i; task_manager.modem_task[i].stack_id = 0; task_manager.modem_task[i].updated_locked = false; } ........}What I Have Checked / ObservedClock & Periphera
Hello,ST Customer Support advised me to post this question in the ST Community.I am planning to use a NUCLEO-WL55JC1 (MB1389) as a transmitter in Japan. According to the official ST Japan certification list, this board has Japanese radio certification number 018-210191:https://www.stmcu.jp/technical/hint/no-119/The Japanese certification database shows the following information: Emission designation: G1D Frequencies: 920.6 to 928.0 MHz Channel spacing: 200 kHz, 38 channels Antenna power: 16.0 mW However, the Avnet Japan product page states that the certification applies only to LoRa and Sigfox modulation:https://www.avnet.com/japan/products/product-highlights/stmicroelectronics-nucleo-wl55jc/I need to determine whether certification 018-210191 also covers custom 2-FSK or 2-GFSK transmission.Could an ST employee or someone familiar with the certification documents please clarify the following? Does certification 018-210191 cover 2-FSK or 2-GFSK transmission? If it does, what are
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
Hi everyone,I am working on a project using the STM32WB55RG and would appreciate some guidance on integrating the STM32WB BLE stack into an existing FreeRTOS-based application.Current SetupMy project currently uses:MCU: STM32WB55RG RTOS: FreeRTOS with the CMSIS-RTOS2 API Configuration/code generation: STM32CubeMX An existing firmware application that is already functional and uses multiple FreeRTOS tasks, semaphores, flags, etc.At this stage of the project, changing to another RTOS or converting the application to bare-metal is unfortunately not an option, so I need to integrate BLE into the existing FreeRTOS/CMSIS-RTOS2 architecture.BLE RequirementsI would like the STM32WB55 to support:BLE advertising Another BLE device should be able to connect to the STM32WB55 and retrieve data from it, most likely through a custom GATT service/characteristic.ProblemI enabled BLE using STM32CubeMX and generated the required BLE code.However, I am having problems when initializing the BLE application
Hello ST Community,I am attempting to run the LoRaWAN_End_Node_LBM example project from the STM32CubeWL MCU Firmware Package on a NUCLEO-WL55JC1 board, connecting to a ChirpStack LoRaWAN Network Server.While ChirpStack shows both the Join Request and Join Accept frames, the node fails to join and loops endlessly in a join retry state.Configuration & Keys Updated AppEUI in se-identity.h to match ChirpStack settings. Tested on STM32CubeWL Firmware Package V1.6.0 (and verified same issue on V1.5.0).Environment / Software Versions Application: LoRaWAN_End_Node_LBM (V1.6.0) Middleware (MW) LoRaWAN: V1.1.0 Middleware (MW) Radio: V1.4.0 L2 Spec: V1.0.4 RP Spec: V2-1.0.4Serial Monitor188s692: TX DONE188s739: RX1 LoRa at 4953 ms freq:868300000, DR 4, BW125, rx timeout 16 ms193s827: RX DONE193s827: RP: RX size 33193s828: Process join accept failed with code = 14193s828:Receive a bad packet on RX1 for stack_id = 0 continue with RX2193s828: RX2 LoRa at 895 ms freq:86952500
I’m trying to make the example LoRaWAN_End_Node_LBM] work on my nucleo-wl55jc1.For now i’ve just changed the DevEUI and AppKey in se-identity.h to match my chirpstack configuration.I can see the join request from my object and the join accept answer of the server but here is what i see on the log of the nucleo:LoRaWAN End Node LBMAPPLICATION_VERSION: V1.6.0MW_LORAWAN_VERSION: V1.1.0MW_RADIO_VERSION: V1.4.0L2_SPEC_VERSION: V1.0.4RP_SPEC_VERSION: V2-1.0.4Event received: RESET###### AppKEY: 2B:7E:15:16:28:AE:D2:A6:AB:F7:15:88:09:CF:4F:3C###### NwkKEY: 2B:7E:15:16:28:AE:D2:A6:AB:F7:15:88:09:CF:4F:3C###### DevEUI: CA:FE:BA:BE:DF:70:70:35###### AppEUI: 00:00:00:00:00:00:00:00###### DevAddr: DF:70:70:358s053:Add JOIN task8s053: TX MNG REQ time=00008053, final_time=000107888s055: Next TX on freq 868100000, DR 3 10s782: Payload: 00 00 00 00 00 00 00 00 00 35 70 70 DF BE BA FE CA 76 01 0A F0 D4 25 size: 23 995: TX DONE11s041: RX1 LoRa at 4957 ms freq:868100000, DR 3,
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.
Hello,I'm prototyping a custom board equipped with a WBA23KE and developing its software.Since this custom board doesn't have a 32kHz crystal, I modified the code based on BLE_p2pServer, referencing the description on the following website.LSEクリスタルなしでSTM32WBA上でRFアプリケーションを動かす方法 - stm32mcuHowever, the HAL_RTC_Init() function on line 615 of the attached main.c fails and goes into ErrorHandler().How should I modify the code?
I want to use the 2-wire Direct Test Mode defined in Bluetooth Core Spec Vol. 6 Part F for RF testing of my STM32WBA custom board.I've already tried BLE_TransparentMode. While HCI / ACI commands work, DTM commands don't respond.Is it impossible to control with 2-wire DTM commands in BLE_TransparentMode?Please let me know if there's any way to do this.
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
ContextI'm finalizing a 4-layer FR4 board with an STM32WBA62CIU6 (2.4 GHz BLE), and I'm not 100% sure about the best way to make the Bluetooth matching/tuning easier.I first built a board with a PCB antenna identical to ST's (following the exact shape shown in application note AN5129) and a 5-element Pi network, as shown in one of the circuits in ST's application note AN5948:1I then used a VNA, connecting at the pad where the STM32 would sit, and tuned the Pi network components so that the Pi + antenna would present an impedance of 30 + j2.5 Ω — the output impedance of my chip at 10 dBm (the power I want to use):2My tuning workflow was: measure with the VNA → export the result → load it into the SimSmith "Load" → place components in the simulator to get a sense of which values to use in real life. However, when I placed the real components, the result was quite different from the simulator — so different that I ended up unable to complete the tuning.Current setup / measurementsSta
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 End_Node application that runs on the STM32WL55 but is not running correctly on the STM32WLE55. The code downloads and starts in the STM32WLE55 but it will not Join the gateway. I took a preliminary look the RF spectrum and it looks slightly different on the STM32WLE55 vs the STM32WL55. The firmware is set for USA915. Thanks for help.
ST Community highlights – April to June 2026
Already have an account? Login
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.