STM32 MCUs Wireless

What is repopulating the security database on the stm32wb55 when it reboots and how do I stop it.   I’m calling aci_gap_clear_security_db() and verifying that the bond list is empty with aci_gap_get_bonded_devices().   When the device reboots, the bond entry that was deleted is back when aci_gap_get_bonded_devices() is called.  What’s going on?

Hello Team,We have manufactured 500 boards using STM32WBA52CGU6. During testing, we tested 50 boards, out of which 5 boards are not advertising BLE, while the remaining 45 boards are working normally.We have attached the schematic and PCB layout screenshots for your reference.Our PCB is a 2-layer board, and we have not followed a controlled 50 Ω impedance for the RF trace. Could this be contributing to the BLE advertising issue on these 5 boards?Could you please review the attached schematic and layout and help us debug this issue? We would also appreciate your guidance on the key parameters or measurements we should checkon the failed boards compared with the working boards.

Hi ST Community,I am designing a custom board with STM32WLE5CCU6 (UFQFPN48 package) for a LoRa application in the 470–510 MHz band.I will use RFO_LP only, with +14 dBm output power and VDD_MCU = 3.3 V.Could you please provide the ZOPT (optimal impedance) for the PA output matching network at 475 MHz for this configuration?AN5457 Appendix A only covers 868/900/915/923 MHz, so I cannot find the data for 475 MHz. If there is any reference design or application note for this frequency, please point me to it.Thank you very much.

Hi all,I'd appreciate some help with a BLE range and stability issue. SetupMCU: STM32WB5MMG module on a custom board Firmware package: STM32Cube FW_WB V1.23.0 BLE wireless stack: v1.16.0, full stack TX power: +1 dBm Connection interval: 10 ms min / 15 ms max. Peripheral latency is 0 and the supervision timeout is 6 s. ATT MTU: 180 Role: peripheral only. The central is a Windows 10/11 PC. PHY: Windows defaults to 2M PHYApplicationThe peripheral sends data to the Windows central over GATT notifications at about 5400 bytes/s (~30 packets/s). ProblemAt short range, the data notifications work correctly. As the distance grows to about 30–40 ft, data notifications start to struggle. At that distance, if the Windows central reads or writes any characteristic, the device goes into an unknown state. For a few seconds it continuously sends unexpected data: the values 0x0839 and 0x08FD repeat every 64 bytes.Often the device recovers within a few seconds and then completes the read/write. Sometime

From the documentation it sounds like the STM32WB vectors to the reset hander when it exits STANDBY and lower power modes, correct? 

I built up an application using STM32CubeMX and FreeRTOS but left BLE disabled. Now, I want to add that connectivity.I went back into CubeMX and turned on BLE with the HeartRate application. The only thing I changed were ASYNC_PRESALER and SYNC_PRESCALER so that the RTC time keeping would be correct.Now, whenever I allow appe_TI_Init() to execute, I get an IPCC_C1_RX_IT interrupt (VECTACTIVE = 0x3C) as soon as osKernelStart() is called. If I comment out the call to appe_TI_Init(), the rest of the code operates as before. Yes, I know that BLE is not running.What have I missed that causes the interrupt when it is not handled?Thanks

Hello, There’s probably a solution, but I haven’t been able to fix it. Could you help me?In the circuits I’ve designed recently, the LSE crystal either doesn’t work at all or its operation is unstable. Generally, when debugging, it gets stuck at the SystemClock_Config(); section and won’t proceed.I’ve designed circuits using different MCUs and have encountered this problem across the board.  In my latest circuit design (4-layer FR-4), I used an STM32WBA54CGU6 MCU and, for the crystal, the ABS07-LR-32.768KHZ-6-1-T recommended in the AN2867 Application Note. I’m using an 8pF C0G 0402 package capacitor as the load capacitor. I also tried a 6.8pF capacitor, but it didn’t work at all. The 8pF capacitor is also unstable. I tried driving it in different modes (LOW, MEDIUM, MEDIUMHIGH, etc.), but it remains unstable. I didn’t adhere perfectly to the layout rules, but I haven’t experienced problems in previous circuits where I followed them even less strictly. I’m trying to keep as few signals

Hi, I'm having some issues with the STM32WB06 when trying to achieve low power consumption. I hope someone can help me solve these problems. Issue 1: After initializing the Bluetooth protocol stack and enabling automatic connection establishment, it causes the device to fail to enter the low power state (BLE wake-up has been disabled). Is this a normal phenomenon? If not, what are the solutions? Issue 2: Before entering the low power mode, disabling automatic connection establishment allows the device to enter the low power mode normally. However, after waking up, attempting to re-enable automatic connection establishment fails (aci_gap_start_procedure(GAP_AUTO_CONNECTION_ESTABLISHMENT_PROC, LE_1M_PHY_BIT, 0, 0)). What is the solution for this problem?   I look forward to your replies. Thank you very much!

Dear Community,we are writing to report a behaviour observed on the STM32WB5MMG module, and to submit a modification we applied, asking for your assessment of its correctness.Some context on why this matters to us: the product is a battery-powered device, and a primary design goal is to minimise power consumption, hence to maximise the time spent in Stop2. Every exit from Stop2 carries a fixed cost — clock restoration, external oscillator start-up, peripheral re-enabling — which we pay in full even when the wake-up has nothing to do. This is why waking once per second, on a device whose nearest application deadline is tens of seconds away, is a concrete problem for us rather than a cosmetic one.ConfigurationFreeRTOS V10.3.1 in tickless idle (configUSE_TICKLESS_IDLE = 2), tick rate 1000 Hz Low power mode Stop2, CFG_LPM_SUPPORTED = 1 Wake-up from Stop2 through the RTC Wakeup Timer, driven by your HW Timer Server (hw_timerserver.c), as in the BLE_HeartRateFreeRTOS example LSE at 32774 Hz;

We are seeing different SRAM2a availability between STM32WB15CC devices with different silicon/FUS revisions.On our older STM32WB15CC devices (silicon Rev B), the device has FUS version 1.2.2.0. On these devices, BRSD_A is set, so the complete 32 KB SRAM2a region (0x20030000–0x20037FFF) is non-secure and available to CPU1.On newer STM32WB15CC devices (silicon Rev Z), we see FUS version 2.2.0.1. On these devices, the relevant configuration is:BRSD_A = 0 SBRSA_A = 0x1A Secure SRAM2a therefore starts at 0x20036800 SFSA = 0x8C, corresponding to 0x08046000 SBR = 0x1180As a result, only 26 KB of SRAM2a (0x20030000–0x200367FF) appears to be available to CPU1, while the upper 6 KB is secure.There is no wireless stack installed, and our application does not use the wireless stack/CPU2 functionality.Our existing production firmware requires the full 32 KB SRAM2a. Reducing the linker region to 26 KB is therefore not a viable workaround.This has become a production-critical issue for us: our exist

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,The latest version of STM32CubeWL (1.6.0), based on the Semtech LBM stack, does not support FUOTA.What is the recommended solution for a new project that requires FUOTA? Should we use an older version of STM32CubeWL (v1.1) that have FUOTA example code?Do you have an estimated date for when FUOTA will be available in the latest version of STM32CubeWL?Best regards,Mathias

Hello,I'm running the BLE_DataThroughput_Server Application on a NUCLEO-WBA65RI (server, notifying) connected to a NUCLEO-WBA55CG (client, receiving notifications), and I'm seeing a significant throughput regression between STM32CubeWBA v1.7.0 and upper versions, with strictly identical configuration. Setup (identical in both cases):Server: NUCLEO-WBA65RI, BLE_DataThroughput_Server Application, from STM32CubeWBA v1.7.0, v1.8.0, and v1.10.0 Client: NUCLEO-WBA55CG,  BLE_DataThroughput_Client Application, from STM32CubeWBA v1.10.0 Connection interval: 11.25 ms PHY: 2M MTU size : 244 Build configuration: Release I added :const uint8_t a_BLE_rx_pckt_count_and_rx_pckt_len[2] = { 0x07, 0x00 }; /* rx_pckt_count , rx_pckt_len */ aci_hal_write_config_data(CONFIG_DATA_LL_RX_ACL_CTRL_OFFSET, 2, a_BLE_rx_pckt_count_and_rx_pckt_len);as described in the "How to get the best throughput" section of the wiki (rx_pckt_count=7, rx_pckt_len=0) Results:BLE_DataThroughput_Server Application from STM32CubeW

Hello guys. On a WBA55CG  running ThreadX with a custom BLE peripheral application, the device becomes permanently stuck  after a random number of sleep/wake cycles (anywhere from ~10 to ~20+). The CPU stays alive, but the advertising timeout never fires again, so the application never returns to STOP 1 mode. Only a hard reset recovers it.The device wakes from STOP 1 mode from either an interrupt fired from an IMU sensor or the RTC,  advertises for an x amount of seconds and re-enters STOP mode until the next interrupt request is issued. The onboard LED blinks when the board enters Advertisement mode and when it becomes stuck, the led stays permanently on and the device becomes unresponsive.The core part of the app is the following FSM  case APP_MAIN_MSG_SLEEP_READY: MAIN_LOG_INFO("[CPU] All modules idle. Authorizing STOP entry..."); // --- Final pre-sleep housekeeping (only if we are actually meant to sleep) --- if (main_state == MAIN_STATE_PREPARE_SLEEP) { PLT_THREAD_SLEEP(10);

Support request: STM32WL33CC — DEEPSTOP average current rises well above datasheet spec, even within a single uninterrupted dwellPart / packageSTM32WL33CC (custom board, not a Nucleo/eval board).SummaryOn our custom board, DEEPSTOP average current starts near the expected low-µA range on entry but climbs over tens of seconds to a plateau of roughly 360–390 µA — two to three orders of magnitude above the datasheet's Table 13 "Current consumption in DEEPSTOP mode" figures (≈1.2–2.1 µA ICORE across all listed LSI/LSE/RTC/IWDG/LPUART configurations). This is reproducible, happens within a single uninterrupted DEEPSTOP dwell (i.e. it is not an artifact of repeated entry/exit cycling), and we have ruled out every peripheral, sensor, and firmware-level cause we can identify. We'd like ST's input on whether this is a known/expected behavior of the DEEPSTOP power architecture (e.g. an internal analog settling time not captured in the static spec table) or points to a board- or configuration-lev

Hello,I am working on a custom application with BLE OTA on the Nucleo WB55RG. The OTA loader is placed at 0x08000000. My main application is linked to start at 0x08007000.In normal mode, the main application runs an ADC test and continuously prints ADC values. I added a hardware OTA trigger on pin PC2. When PC2 is driven high, the application prepares the BLE OTA request and then calls NVIC_SystemReset(). The OTA request is passed to the loader at the start of SRAM.After this, the OTA loader starts correctly. The loader detects the OTA request from SRAM. The loader erases the application flash area starting from sector 7, corresponding to address 0x08007000. The loader then attempts to initialize the BLE stack and start advertising.The issue is that BLE advertising does not start when entering OTA mode after the NVIC_SystemReset(). Pressing the on-board reset button also does not make BLE advertising start. However, if I completely power cycle the board by removing USB power and reconn

Device: STM32WB55Hi Community,We are receiving HCI_HARDWARE_ERROR_EVENT with code 0x04 from bluetooth full stack (version 1.18 up to 1.24 tested), while advertising and C1 enters STOP1. It happens randomly, and the device becomes sometimes unconnectable after this unless we reset the stack.We are NOT using STM32CubeWB, but followed recommandations found in AN5289 regarding PLL management and entering/leaving STOP1 mode.Any insight on what can cause this and how to fix it properly ?Thanks, 

Dear we working on safety critical application on railway. We are going to workout a FMECA analysis on our solution and I need further documentation on the STM32WLE5. At the begininning of the project we already signed an NDA with STM to get safety plan for another STM MCU. May we talk directly than I will send you a copy of the NDA ? Thanks a lot  

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.

I am designing a custom board using the STM32WL55 in UFBGA73, operating at 433 MHz, and I am currently facing higher-than-expected TX current consumption together with lower RF output power.I would like to know whether ST can provide load-pull data, optimum complex load impedance, or PA matching information at 433 MHz, particularly for approximately 0 dBm and +14 dBm TX power.I have compared my custom board against an STM32WL Nucleo board using the same firmware and RF settings.My measurements so far are:Nucleo board TX current: approximately 65.8 mACustom board TX current: approximately 72 mADifference: approximately 6–7 mA higher on my custom boardConducted RF power measurement on my custom board indicates approximately 10 dB lower output power than expectedMy next step is to measure the impedance presented to the PA at the beginning of the RF matching network and determine whether the PA is seeing the correct load at 433 MHz.Ideally, I would like to compare my measured impedance wit

Ok, a tricky one.  So for services and attributes it's documented that there is 10752 bytes, each service takes up 48 bytes, each attribute 40 bytes, and if you got th number of services and attributes you can compute backwards  BLE_ATT_VALUE_ARRAY_SIZE (after you mapped all characteristics to actual attributes), given the upper limit. Easy enough. (GATT_DB_Size_SRAM_NVM.xlsx) My problem is now BLE_MBLOCK_COUNT. There is this macro:#define BLE_TOTAL_BUFFER_SIZE(n_link, mblocks_count) \ (16 + BLE_FIXED_BUFFER_SIZE_BYTES + \ (BLE_PER_LINK_SIZE_BYTES * (n_link)) + \ ((BLE_MEM_BLOCK_SIZE + 8) * (mblocks_count)))What is the limit for BLE_TOTAL_BUFFER_SIZE ? If that is known, I can compute backwards to get "mblock_count" for a known "n_link". Or is the documented 10752 byte number the limit for "BLE_TOTAL_BUFFER_SIZE()" plus the BLE_NUM_GATT_ATTRIBUTES / BLE_NUM_GATT_SERVICES / BLE_ATT_VALUE_ARRAY_SIZE database size ?

Hello everyone,I am using the X-NUCLEO-WB05KN1 on a NUCLEO-U083RC. I have already read the documentation on the XCube Sofware package and flashed the shield with the SPI.hex firmware. I am testing the Beacon application but when I get to the hci_reset() function it always returns a timeout and the execution does not proceed. I have already tried the 2.1.0 version and the 1.1.0 version of the software package and I got the same problem on both. I have also tried to set the SPI CLK pin with PULL UP configuration as it was noticed on a previous topic but without success. Can anyone help please?Best regards.

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.

Hello ST Community,I am working with STM32WB05 in a custom PCB (new design) and it does not run when power on the PCB. To run it, I have to reset by reset line. If I am debugging, I neither have problem.I had used others microcontroller before (STM32L1, STM32WL55...) and it had never happend. I have check the pollowing points:1-  Power supply. I am using a externa battery with 3-3,5Volts.2- BOOT pin: I think that the problem is the STM32WB05 enter in boot mode but in the datasheet, I can not see any pin to enter it.I have tried to join PA10 to GND by 10K resistor (I see in nucleo manual UM3343 that BOOT0 pin is PA10) but that no work.3-  Clock source: I am using interna clock HSE4- reset line is always high level Any confirmation or guidance would be greatly appreciated.Thank you for your support.

This account only shares restored community content posted by members between May 22 and June 9, 2026, who did not register for the new community.Dear STMicroelectronics Team,We would like to request clarification regarding the delivery schedule of our STM32WL5MOCH6TR orders.As indicated in the attached correspondence and supply reports, we were initially informed that our order would be delivered in June 2026. Based on this commitment, we planned our production schedules, project milestones, and customer deliveries accordingly.However, after requesting an updated status, we were informed that the estimated delivery date had been postponed to February 2027.This change represents an approximately eight-month delay and creates a significant risk for our ongoing projects and contractual commitments, including projects for public institutions.We kindly ask for your support in confirming whether the latest delivery date is accurate and final. If there is indeed a supply constraint that will