Full Firmware Package for the STM32WB series: HAL+LL drivers, CMSIS, BSP, MW, plus a set of Projects


STM32CubeWB MCU Firmware Package

latest tag

STM32Cube is an STMicroelectronics original initiative to ease developers' life by reducing efforts, time and cost.

STM32Cube covers the overall STM32 products portfolio. It includes a comprehensive embedded software platform delivered for each STM32 series.

  • The CMSIS modules (core and device) corresponding to the ARM(tm) core implemented in this STM32 product.
  • The STM32 HAL-LL drivers, an abstraction layer offering a set of APIs ensuring maximized portability across the STM32 portfolio.
  • The BSP drivers of each evaluation, demonstration or nucleo board provided for this STM32 series.
  • A consistent set of middleware libraries such as RTOS, USB, FatFS, graphics, touch sensing library...
  • A full set of software projects (basic examples, applications, and demonstrations) for each board provided for this STM32 series.

The STM32CubeWB MCU Package projects are directly running on the STM32WB series boards. You can find in each Projects/Board name directories a set of software projects (Applications/Demonstration/Examples).

Release note

Details about the content of this release are available in the release note here.

Boards available


Caution : The issues and the pull-requests are strictly limited to submit problems or suggestions related to the software delivered in this repository.

For any other question related to the product, the hardware performance or characteristics, the tools, the environment, you can submit it to the ST Community on the STM32 MCUs related page.

  • How to use STM32WB BLE event callbacks?

    How to use STM32WB BLE event callbacks?

    The STM32CubeWB libraries contain a file which specifies the BLE event callback functions: STM32CubeWB/Middlewares/ST/STM32_WPAN/ble/core/auto/ble_events.c which is great: I'd rather use this than the switch/case statements. This is also mentioned in PM0271 revision 2 section 4.4: BLE stack events and event callbacks. including sample usage.

    However when I try to use the callbacks, they don't work.

    I've tried adding a simple trace to see if the event ever gets triggered but I don't see any messages (both with and without the __WEAK attribute):

    __WEAK void hci_le_connection_complete_event(
    	uint8_t Status,
    	uint16_t Connection_Handle,
    	uint8_t Role,
    	uint8_t Peer_Address_Type,
    	const uint8_t* Peer_Address,
    	uint16_t Conn_Interval,
    	uint16_t Conn_Latency,
    	uint16_t Supervision_Timeout,
    	uint8_t Master_Clock_Accuracy
    	Debug_print("hci_le_connection_complete_event called!");

    But in my switch/case events I do get the EVT_LE_CONN_COMPLETE event triggering.

    I'm using the latest firmware package available today: v1.10.0 The firmware version loaded via STM32CubeProgrammer is: V2J37M26 Also want to mention that I'm using the P-NUCLEO-WB55 development board.

    Is there additional (or alternative) setup I need to perform? Or does it only work with a specific version of the BLE binaries loaded onto the co-processor? Do I need to modify the assembly startup_stm32wb55rgvx.s file to make the callbacks work?

    question cube mx mw ble 
    opened by Daniel-Khodabakhsh 11
  • svc_ctl.c is missing a definition of __weak

    svc_ctl.c is missing a definition of __weak

    The svc_ctl.c is depending on a compiler specified include to provide the __weak definition. The .c file should include either #include "stm32wbxx_hal_def.h", or using the CMSIS provided __WEAK definition via "cmsis_compiler.h". Without modifying this file (or the compiler include directives), you end up with:

         Middlewares/ST/STM32_WPAN/ble/svc/Src/svc_ctl.c:71:7: error: expected ';' before 'void'
           71 | __weak void DIS_Init( void )
              |       ^~~~~
              |       ;
        Middlewares/ST/STM32_WPAN/ble/svc/Src/svc_ctl.c:75:7: error: expected ';' before 'void'
           75 | __weak void EDS_STM_Init( void )
              |       ^~~~~
              |       ;
    bug internal bug tracker bsp 
    opened by tim-nordell-nimbelink 9
  • P-NUCLEO-WB55.Nucleo\Examples\ADC\ADC_SingleConversion_TriggerTimer_DMA is fake

    P-NUCLEO-WB55.Nucleo\Examples\ADC\ADC_SingleConversion_TriggerTimer_DMA is fake

    Caution The Issues are strictly limited for the reporting of problem encountered with the software provided in this project. For any other problem related to the STM32 product, the performance, the hardware characteristics and boards, the tools the environment in general, please post a topic in the ST Community/STM32 MCUs forum.

    Describe the set-up

    • The board (either ST RPN reference or your custom board).
    • IDE or at least the compiler and its version.

    Describe the bug Like the title, this example is fake. It is supposed to use TIM2 triggering ADC conversion via DMA, but the truth is this is a ADC software trigger ADC DMA continuous conversion. They are very much the different. If you remove TIM2 totally, ADC DMA is still running. So this example is totally fake. Yet this example is very important as many users need A timer to trigger ADC in certain period. Please correct this example. Thanks.

    How To Reproduce

    1. Indicate the global behavior of your application project.

    2. The modules that you suspect to be the cause of the problem (Driver, BSP, MW ...).

    3. The use case that generates the problem.

    4. How we can reproduce the problem.

    Additional context If you have a first analysis or patch correction, thank you to share your proposal.

    Screenshots If applicable, add screenshots to help explain your problem.

    bug internal bug tracker projects 
    opened by LockeKK 8
  • Code stuck in infinite loop if HW_TS is not initialized quickly enough after the RTC using STM32_WPAN

    Code stuck in infinite loop if HW_TS is not initialized quickly enough after the RTC using STM32_WPAN


    P-NUCLEO-WB55-Nucleo as well as custom board using STM32WB55VG IDE STM32CubeIDE and STM32CubeMX firmware STM32Cube_FW_WB_V1.13.1

    Bug Description

    When using the STM_WPAN middleware, if the Hardware Time Server (HW_TS) is not initialized quickly enough after the RTC initialization (via MX_RTC_Init()), the code might get stuck in an infinite loop in the HW_TS_RTC_Wakeup_Handler() function (file hw_timeserver.c:565).


    At startup, the code hangs completely

    Suspected modules: STM32_WPAN middleware, in particular the implementation of the time server.

    This is due to the fact that the MX_RTC_Init initializes the RTC and enables the RTC Wakeup interrupt but the hardware server not being already initialized, the first wakeup interrupt will call the HW_TS_RTC_Wakeup_Handler. However, the pointer phrtc is still set to 0x00. Subsequent calls to the various __HAL_RTC** functions in the interrupt handler will write in an unknown location, causing these calls to be useless. We will then end up near the end of the function where the code waits for the RTC to signal that the Wakeup Timer is stopped. However, because phrtc is still set to 0x00, the WUTWF will never read as something else than RESET, turning line 565 to an infinite loop:


    In order to reproduce the bug: Generate some default code with CubeMX. You need to activate the radio module. The configuration I used when encountering the bug was using BLE in server mode (server profile, with only Custom P2P server enabled, no debug option selected). Do not forget to enable the HSEM and IPCC with their respective interrupts enabled. The RTC also needs to be enabled in order for the STM32_WPAN module to work. I enabled the generation of the wakeup interrupt in CubeMX. If running the code as-is, it should be working properly. However, if we add a task long enough between the RTC initialization and the MX_APPE_Init() call, the code will hang in the previously identified location. I tested it with a task composed of a 1ms delay (using HAL_Delay(1) added in block /* USER CODE BEGIN 2 */) and the code hang as expected (verified with the project compiled in debug mode).

    Identified solutions

    Several solutions are possible:

    • One could simply ask CubeMX not to enable the wakeup interrupt of the RTC and then reimplement the RTC Wakeup handler in user code. Because the STM32_WPAN code (re-)configures the required parameters of the RTC as needed, this do work. However I think this is not the best solution because there is still a possibility for a user to encounter this bug if said user did not read this post. Also the possibility for some part of the code to rely upon an uninitialized pointer gives m the chills and prevents me from sleeping at night.

    • One could avoid the possibility to insert code between the RTC initialization and the BLE initialization. This however reduces the flexibility of the generated code and should be avoided. Also, see the end of the previous solution.

    • I believe the real solution should be to avoid using an uninitialised pointer. This can be done by modifying the macro definition of HAL_RTCEx_WakeUpTimerIRQHandler(...) in app_conf.h:407.

      #define HAL_RTCEx_WakeUpTimerIRQHandler(...)  HW_TS_RTC_Wakeup_Handler( )

      would then become

      #define HAL_RTCEx_WakeUpTimerIRQHandler(__HANDLE__)  HW_TS_RTC_Wakeup_Handler(__HANDLE__)

      This also requires the following changes :

      • In file hw_if.c:197
        void HW_TS_RTC_Wakeup_Handler(void);


        void HW_TS_RTC_Wakeup_Handler(RTC_HandleTypeDef* hrtc);
      • and in file hw_timeserver.c:486:
        void HW_TS_RTC_Wakeup_Handler(void)


        void HW_TS_RTC_Wakeup_Handler(RTC_HandleTypeDef* hrtc)
      • All the calls to functions using phrtc as argument would also require to be changed to use the new hrtc (not show here for the sake of clarity). This is to me the best solution even though it might require some more thinking. Because the WB series is a contains only one RTC, there is little to no risk that we get the wrong handle in any call to the HW_TS functions. I do not see the use to having several RTCs in a same device but hey, you never know what the future will be.

    Additional information

    • On my custom PCB on which most of the exploration was done, the CM4 core runs at 64MHz and the debug probe used is a J-Link EDU. Te code was mostly running in debug mode so this might somewhat change the timings involved.
    • I found this bug because I needed to initialize a shell before the BLE gets initialized but after the USART1 got initialized.
    • I would gladly propose a pull-request implementing the changes but I could not figure out the location of the file responsible for the generation of the app_conf.h file. I tried to bring the change to all the projects contained in this repository but the generated file stayed the same.

    I will now be listening to your comments about this whole thing which took me too much time to discover than I am willing to admit!

    EDIT: corrected some file names

    enhancement cube mx internal bug tracker st community 
    opened by mdiepart 6
  • NULL dereference inside BLE_Beacon examples when invoking hci_le_set_scan_response_data(...)

    NULL dereference inside BLE_Beacon examples when invoking hci_le_set_scan_response_data(...)

    API being invoked that does the dereference:

    $ git grep hci_le_set_scan_response_data Projects/
    Projects/P-NUCLEO-WB55.Nucleo/Applications/BLE/BLE_Beacon/STM32_WPAN/App/eddystone_tlm_service.c:  hci_le_set_scan_response_data(0, NULL);
    Projects/P-NUCLEO-WB55.Nucleo/Applications/BLE/BLE_Beacon/STM32_WPAN/App/eddystone_uid_service.c:  hci_le_set_scan_response_data(0, NULL);
    Projects/P-NUCLEO-WB55.Nucleo/Applications/BLE/BLE_Beacon/STM32_WPAN/App/eddystone_url_service.c:  hci_le_set_scan_response_data(0, NULL);
    Projects/P-NUCLEO-WB55.Nucleo/Applications/BLE/BLE_Beacon/STM32_WPAN/App/ibeacon_service.c:  hci_le_set_scan_response_data(0, NULL);

    hci_le_set_scan_response_data(...) implementation:

    tBleStatus hci_le_set_scan_response_data( uint8_t Scan_Response_Data_Length,
                                              const uint8_t* Scan_Response_Data )
      struct hci_request rq;
      uint8_t cmd_buffer[BLE_CMD_MAX_PARAM_LEN];
      hci_le_set_scan_response_data_cp0 *cp0 = (hci_le_set_scan_response_data_cp0*)(cmd_buffer);
      tBleStatus status = 0;
      int index_input = 0;
      cp0->Scan_Response_Data_Length = Scan_Response_Data_Length;
      index_input += 1;
      Osal_MemCpy( (void*)&cp0->Scan_Response_Data, (const void*)Scan_Response_Data, 31 );
      index_input += 31;
      Osal_MemSet( &rq, 0, sizeof(rq) );
      rq.ogf = 0x08;
      rq.ocf = 0x009;
      rq.cparam = cmd_buffer;
      rq.clen = index_input;
      rq.rparam = &status;
      rq.rlen = 1;
      if ( hci_send_req(&rq, FALSE) < 0 )
        return BLE_STATUS_TIMEOUT;
      return status;

    You can see Osal_MemCpy(...) is invoked with the passed in data structure even when it's NULL, such as in the BLE_Beacon example code. The hci_le_set_scan_response_data(...) implementation probably should do:

      Osal_MemSet( (void*)&cp0->Scan_Response_Data, 31);
      Osal_MemCpy( (void*)&cp0->Scan_Response_Data, (const void*)Scan_Response_Data, Scan_Response_Data_Length <= 31 ? Scan_Response_Data_Length : 31);

    instead of assuming it can read 31 bytes from the source. The function implementation as-is could cause a bus fault, too, depending on where the source data is located in memory if it was less than 31 bytes originally for someone who isn't adding a NULL/sized 0 data entry.

    invalid projects mw ble 
    opened by tim-nordell-nimbelink 6
  • v1.2.0 stm32wb5x_FUS_fw.bin version is not reported correctly and fails to upgrade

    v1.2.0 stm32wb5x_FUS_fw.bin version is not reported correctly and fails to upgrade

    STM32WB55RE (512K) CubeProgrammer v2.7.0 stm32wb5x_FUS_fw.bin (v1.2.0)

    CubeProgrammer will not upgrade latest STM32WB5x FUS v1.2.0 from latest 1.11.1 pack. The Selected File version is being shown as FUS V-1.-1.-1 If we try to run the upgrade with this file, the log reports

    Could not execute firmware upgrade command, Impossible to install FUS V1.0.1 on 256/512KB Flash Parts

    Also tried downloading the 1.11.1 patch software pack from ST website and it has the same problem.


    v1.11.0 pack stm32wb5x_FUS_fw.bin (v1.1.2) version is reported correctly and upgrades fine.

    tools ble 
    opened by EZIMM 5
  • RSSI integer signedness mismatch from documentation to implementation

    RSSI integer signedness mismatch from documentation to implementation


    In this section of code: https://github.com/STMicroelectronics/STM32CubeWB/blob/24ba9f167a82143a0a4fa8772cd4466070bcdb82/Middlewares/ST/STM32_WPAN/ble/core/auto/ble_types.h#L237-L244

    The documentation states it's a signed integer, but the structure implements an unsigned integer. This is repeated once in this same source file:


    And there are these, too, without documentations stating if they're signed or unsigned, but presumably they should match:

    https://github.com/STMicroelectronics/STM32CubeWB/blob/24ba9f167a82143a0a4fa8772cd4466070bcdb82/Middlewares/ST/STM32_WPAN/ble/core/auto/ble_types.h#L436 https://github.com/STMicroelectronics/STM32CubeWB/blob/24ba9f167a82143a0a4fa8772cd4466070bcdb82/Middlewares/ST/STM32_WPAN/ble/core/auto/ble_types.h#L2432

    bug question internal bug tracker mw ble 
    opened by tim-nordell-nimbelink 5
  • DeviceInfoTable incomplete/not matching documentation

    DeviceInfoTable incomplete/not matching documentation

    The DeviceInfo table defined in mbox_def.h does not match the documentation (AN5185).


    typedef PACKED_STRUCT {
    uint32_t TableState;
    uint8_t Reserved;
    uint8_t LastFusState;
    uint8_t LastWirelessState;
    uint8_t WirelessStackType;
    MB_SafeBootInfoTable_t SafeBootInfoTable;
    FusInfoTable_t FusInfoTable;
    MB_WirelessFwInfoTable_t WirelessFwInfoTable;
    } DeviceInfoTable_t;

    Also the referenced FusInfoTable does not match the documentation (MB_FusInfoTable_t), it has an excessive field. Correct:

    typedef PACKED_STRUCT {
    uint32_t Version;
    uint32_t MemorySize;
    } FusInfoTable_t;

    Due to the missing/additional fields, the offsets do not match the documentation anymore, so wrong values are read when accessing the struct members.

    Also the method SHCI_GetWirelessFwInfo which uses the DeviceInfoTable should check the TableState member to verify that the table is initialized and return an error when not.

    opened by HaukeRa 5
  • Error upgrading wireless coprocessor firmware on Nucleo-68

    Error upgrading wireless coprocessor firmware on Nucleo-68

    Describe the set-up Host OS: Linux glibc system Board: P-NUCLEO-WB55 STM32WB55RG (Nucleo-68) Tools:

    • STM32CubeProgrammer v2.4.0
    • SMT32CubeWB firmware images

    Describe the bug Trying to update the wireless coprocessor to latest v1.7.0 results in an error:

    Error: failed to download Segment[0]
    Error: failed to download the File
    Error: Failed to download image!

    How To Reproduce

    1. clone https://github.com/STMicroelectronics/STM32CubeWB
    2. enter the repository
    3. checkout tag v1.7.0
    4. cd Projects/STM32WB_Copro_Wireless_Binaries/STM32WB5x/
    5. follow instructions at How to flash the Wireless Coprocessor Binary via USB (Command Line Interface) in file Release_Notes.html using STM32CubeProgrammer v2.4.0

    Additional context The Update History section of Release_Notes.html shows 1.6.0 changes as latest entry even on tag v.1.7.0. However checking out the repo at v1.6.0 yields the same error result as v1.7.0.



    bug internal bug tracker tools 
    opened by anddam 5
  • USB + BLE (not BLE HID)

    USB + BLE (not BLE HID)

    First of all, great job on both the product and this repository. Really well structured and easy to follow.

    I'm working on a prototype for a keyboard that also requires wireless connectivity (separated from the HID layer). I'm basically trying to translate your TransparentModeVCP into a TransparentModeHID but I kinda hit a bump. Can't really seem to figure out where the initialization of the USB device takes place (there are a ton of includes from different projects / drivers/ middlewares).

    Would you kindly point me in the right direction?

    help wanted question mw ble usb 
    opened by pauleffect90 5
  • PCD Connect and Disconnect callbacks are not called anywhere in the code

    PCD Connect and Disconnect callbacks are not called anywhere in the code

    Describe the set-up

    • CubeMX v6.4.0 with CubeWB v1.13.1

    Describe the bug Generated code in usbd_conf.c contains HAL_PCD_ConnectCallback() and HAL_PCD_DisconnectCallback():

      * @brief  ConnectCallback callback.
      * @param  hpcd: PCD handle
      * @retval None
    void HAL_PCD_ConnectCallback(PCD_HandleTypeDef * hpcd)
      * @brief  Disconnect callback.
      * @param  hpcd: PCD handle
      * @retval None
    void HAL_PCD_DisconnectCallback(PCD_HandleTypeDef * hpcd)

    But these callbacks are not called anywhere in stm32wbxx_hal_pcd. This is same independent of selected USB Device Class. However other callbacks like HAL_PCD_ResumeCallback() are called and executed. Is this a bug, or what if the point of these functions then?

    question usb hal 
    opened by fronders 4
  • HAL Flash missing support for STM32WB10xx

    HAL Flash missing support for STM32WB10xx


    • STM32CubeIDE v1.10.0
    • Custom PCB with STM32WB10CC

    Problem The STM32WB10CC chip has a flash page size of 2 kByte (RM0478 Rev 5 pg 61) The stm32wbxx_hal_flash.h header defines the flash page size as 4 kByte

    Solution There are other features in the HAL (like RCC and TIM) that explicitly support the STM32WB10xx device series. It appears that the HAL flash feature needs to be updated to support the STM32WB10xx series.

    For example, in the case of flash page size, this code would become:

    #if defined(STM32WB10xx) || defined(STM32WB15xx) || defined(STM32WB1Mxx)
    #define FLASH_PAGE_SIZE                         0x00000800U  /*!< FLASH Page Size, 2 KBytes */
    #define FLASH_PAGE_SIZE                         0x00001000U  /*!< FLASH Page Size, 4 KBytes */
    opened by nicreuss 0
  • Confusing effects of CFG_HW_RESET_BY_FW flag

    Confusing effects of CFG_HW_RESET_BY_FW flag

    app.h file from examples defines CFG_HW_RESET_BY_FW as follows:

     * When set, this resets some hw resources to set the device in the same state than the power up
     * The FW resets only register that may prevent the FW to run properly
     * This shall be set to 0 in a final product
    #define CFG_HW_RESET_BY_FW         1

    From my understanding it means that when this flag is enabled, initialization code should reset some HW resources when software reset cause is detected. However, when I look at app_entry.c where this flag is used, I see:

    #if (CFG_HW_RESET_BY_FW == 1)
    static void Reset_BackupDomain(void)
      if ((LL_RCC_IsActiveFlag_PINRST() != FALSE) && (LL_RCC_IsActiveFlag_SFTRST() == FALSE))
        HAL_PWR_EnableBkUpAccess(); /**< Enable access to the RTC registers */
         *  Write twice the value to flush the APB-AHB bridge
         *  This bit shall be written in the register before writing the next one

    Backup domain reset is executed only when SFTRST is NOT SET, so there is other reset source than software reset. This is a little confusing. This behavoiur also leads to a problem when I want to use RTC and Shutdown LPM, because on every wake-up RTC resets.

    I guess that there is a bug and SFTRST should be checked if is SET. However, if above code is correct, how can I use RTC and Shudown mode if I have to reset backup domain on every non-software reset?

    opened by hlukasz 0
  • BLE_Hid Application  - Keyboard with Input and Output Report

    BLE_Hid Application - Keyboard with Input and Output Report

    P-NUCLEO-WB55.Nucleo STM32CubeIDE: 1.11.0 STM32CubeWB: 1.15.0. FUS version 1.2.0 Wireless Firmware version 1.15.0 (BLE_Stack_full)

    Hi all,

    modified the app as follows

    1. in BLE_Hid\core\inc\app_conf.h changed the debug trace uart to #define CFG_DEBUG_TRACE_UART hw_uart1

    2. in BLE_Hid\STM32_WPAN\App\hids_app.c added keyboard report descriptor

    static uint8_t report_keyboard[] =
    		0x05, 0x01,	//Usage Page (Generic Desktop),
    		0x09, 0x06,	//Usage (Keyboard),
    		0xA1, 0x01,	//Collection (Application),
    		0x05, 0x07,	//Usage Page (Key Codes);
    		0x19, 0xE0,	//Usage Minimum (224),
    		0x29, 0xE7,	//Usage Maximum (231),
    		0x15, 0x00,	//Logical Minimum (0),
    		0x25, 0x01,	//Logical Maximum (1),
    		0x75, 0x01,	//Report Size (1),
    		0x95, 0x08,	//Report Count (8),
    		0x81, 0x02,	//Input (Data, Variable, Absolute), ;Modifier byte
    		0x95, 0x01,	//Report Count (1),
    		0x75, 0x08,	//Report Size (8),
    		0x81, 0x01,	//Input (Constant), ;Reserved byte
    		0x95, 0x05,	//Report Count (5),
    		0x75, 0x01,	//Report Size (1),
    		0x05, 0x08,	//Usage Page (Page# for LEDs),
    		0x19, 0x01,	//Usage Minimum (1),
    		0x29, 0x05,	//Usage Maximum (5),
    		0x91, 0x02,	//Output (Data, Variable, Absolute), ;LED report
    		0x95, 0x01,	//Report Count (1),
    		0x75, 0x03,	//Report Size (3),
    		0x91, 0x01,	//Output (Constant), ;LED report padding
    		0x95, 0x06,	//Report Count (6),
    		0x75, 0x08,	//Report Size (8),
    		0x15, 0x00,	//Logical Minimum (0),
    		0x25, 0x65,	//Logical Maximum(101),
    		0x05, 0x07,	//Usage Page (Key Codes),
    		0x19, 0x00,	//Usage Minimum (0),
    		0x29, 0x65,	//Usage Maximum (101),
    		0x81, 0x00,	//Input (Data, Array), ;Key arrays (6 bytes)
    		0xC0		//End Collection

    changed the HIDSAPP_Init accordingly

    void HIDSAPP_Init(void)
      tBleStatus result = BLE_STATUS_INVALID_PARAMS;
      result = HIDS_Update_Char(REPORT_MAP_CHAR_UUID, 
                                (uint8_t *)&report_keyboard);
      if( result == BLE_STATUS_SUCCESS )
        BLE_DBG_APP_MSG("Report Map Successfully Sent\n");
        BLE_DBG_APP_MSG("Sending of Report Map Failed error 0x%X\n", result);

    modified the HIDSAPP_Profile_Update just to send "d" on Button_1 press

    void HIDSAPP_Profile_UpdateChar(void)
      uint8_t hid_buffer[8] = {0,0,7,0,0,0,0,0};
      tBleStatus result = BLE_STATUS_INVALID_PARAMS;
      result = HIDS_Update_Char(REPORT_CHAR_UUID,
      if( result == BLE_STATUS_SUCCESS )
        BLE_DBG_APP_MSG(" d press\n");
    	BLE_DBG_APP_MSG(" d press FAILED\n");
      hid_buffer[2] = 0;
      result = HIDS_Update_Char(REPORT_CHAR_UUID,
      if( result == BLE_STATUS_SUCCESS )
    	BLE_DBG_APP_MSG(" d release\n");
    	BLE_DBG_APP_MSG(" d release FAILED\n");
    1. and changed Human Interface Device Service (HIDS) in BLE_Hid\STM32_WPAN\App\ble_conf.h
    #define BLE_CFG_HIDS_PROTOCOL_MODE_CHAR           0 /**< Support of Protocol Mode Characteristic */
    #define BLE_CFG_HIDS_INPUT_REPORT_NB              1 /**< Number of Input Report */
    #define BLE_CFG_HIDS_INPUT_WRITE                  0 /**< Support of Input Write property */
    #define BLE_CFG_HIDS_OUTPUT_REPORT_NB             1 /**< Number of Output Report */
    #define BLE_CFG_HIDS_FEATURE_REPORT_NB            0 /**< Number of Feature Report */
    #define BLE_CFG_HIDS_EXTERNAL_REPORT_REFERENCE    0 /**< Support of EXTERNAL REPORT Reference Descriptor */
    #define BLE_CFG_HIDS_KEYBOARD_DEVICE              0 /**< Support of BOOT KEYBOARD Report Characteristic */
    #define BLE_CFG_HIDS_KEYBOARD_INPUT_WRITE         0 /**< Support of Keyboard Input Write property */
    #define BLE_CFG_HIDS_MOUSE_DEVICE                 0 /**< Support of BOOT MOUSE Report Characteristic */
    #define BLE_CFG_HIDS_MOUSE_INPUT_WRITE            0 /**< Support of Mouse Input Write property */
    #define BLE_CFG_HIDS_REPORT_CHAR                  \
    #define BLE_CFG_HIDS_PROTOCOL_MODE                1 /**< Report Protocol Mode */

    So far so good. Project compiles. Nucleo connects to the PC over BT and on Button_1 press "d" appears. Now the issue. Upun connection the PC tries to inform the keyboard that the Num Lock is on image and fails. When I set BLE_CFG_HIDS_INPUT_REPORT_NB to 0 the Output Report gets processed correctly image but as expected "d" is not send to the PC.

    How can I get both working? Thank you.

    opened by rstenet 0
  • Fix STOPF timeout not working in I2C_IsErrorOccurred

    Fix STOPF timeout not working in I2C_IsErrorOccurred

    When STOPF is never set, the I2C_IsErrorOccurred function looped forever, even after reaching I2C_TIMEOUT_STOPF This commit fixes this issue


    This issue is present in multiple HAL driver repositories and processor CubeMX packages, and sometimes it has been fixed in the HAL driver repo but not yet in the CubeMX repo. This list is not exhaustive:

    opened by paussems 0
  • Firmware Examples project for LL - I2C reader has flaw.

    Firmware Examples project for LL - I2C reader has flaw.

    Sample LL code to read from I2C occasionally fails.

    Issue is located in lines 442-470 of the following file : https://github.com/STMicroelectronics/STM32CubeWB/blob/master/Projects/P-NUCLEO-WB55.Nucleo/Examples_LL/I2C/I2C_TwoBoards_MasterTx_SlaveRx_Init/Src/main.c

    It is meant to read I2C data until STOP flag is raised. The issue is the ordering of the checks between RXNE and STOP flags.

    At the end of a transmission, the next-to last byte is read (line 452), then some actions are performed (in particular when checking timeout. It may also get interrupted). It will take some time to go back to the beginning of the loop line 443.

    By the time we get there, the last byte may be already received by the HW. In this case we have both RXNE and STOP flag raised.

    This will stop the operation and clear the STOP flag without reading the last byte received.

    A proper implementation would check the STOP flag only if/when RXNE is no longer set.

    The issue is real, we've observed it many times. It obviously depends on the CPU, peripheral and bus frequencies. It can also be triggered by adding some time-consuming operations between the data read (line 452) and the end of the loop (line 470).

    opened by Vince-H 1
STMicroelectronics is a world leader in providing the semiconductor solutions that make a positive contribution to people’s lives, today and into the future.
This is a C plus plus coding template for Compitative programming. This template is very optimized for the Online Judgment

C-plusplus-compitative-Programming-Template Tech We Used C++ Features Easy to compile Easy debug facility Analysised and optimized base template Steps

Alan Binu 15 Jan 27, 2022
DOOM BSP renderer for ZenithOS.

Zenith DOOM This project ports the DOOM BSP renderer to Zenith for use in custom games. It includes a zos/ directory in src/ which has includes that e

null 3 Jun 10, 2021
Half-Life bsp map to gltf converter

hlbsp-converter A tool to convert bsp maps (Half-Life and other GoldSrc games) into glTF scenes. Key features: Export embedded texture, and optionally

Alexey 8 Sep 5, 2022

Dapper Mime This unearths the name of a weekend project that I did in 2014. Both then and now, this is a port of ARM's CMSIS-DAP code to a platform wi

null 73 Dec 16, 2022
built-in CMSIS-DAP debugger tailored especially for the RP2040 “Raspberry Pi Pico”

RP2040 has two ARM Cortex-M0+ cores, and the second core normally remains dormant. pico-debug runs on one core in a RP2040 and provides a USB CMSIS-DAP interface to debug the other core. No hardware is added; it is as if there were a virtual debug pod built-in.

null 272 Dec 30, 2022
X-CUBE-AZRTOS-F4 (Azure RTOS Software Expansion for STM32Cube) provides a full integration of Microsoft Azure RTOS in the STM32Cube environment for the STM32F4 series of microcontrollers.

X-CUBE-AZRTOS-F4 Azure RTOS Software Expansion for STM32Cube With Azure RTOS complementing the extensive STM32Cube ecosystem providing free developmen

STMicroelectronics 28 Dec 7, 2022
X-CUBE-AZRTOS-F7 (Azure RTOS Software Expansion for STM32Cube) provides a full integration of Microsoft Azure RTOS in the STM32Cube environment for the STM32F7 series of microcontrollers.

X-CUBE-AZRTOS-F7 Azure RTOS Software Expansion for STM32Cube With Azure RTOS complementing the extensive STM32Cube ecosystem providing free developmen

STMicroelectronics 7 Nov 17, 2022
This repository gives an idea about how to use UART/SPI/I2C communication using HAL APIs

STM32-UART-SPI-I2C communication with Arduino board using HAL APIs This repository gives an idea about how to use UART/SPI/I2C communication using HAL

Shrilesh(Skrillex) 1 Nov 1, 2021
ADXL345 Library for STM32-HAL

ADXL345-STM32 ADXL345 Library for STM32-HAL This library is not complete so this library may run unstable. How to use this library Change the header f

Can Guveren 2 May 26, 2022
Library for STM32 microcontrollers with HAL to communicate with absolute orientation sensor Bosh BNO055.

Bosh BNO055 sensor library fro STM32 with HAL Library for STM32 microcontrollers with HAL to communicate with absolute orientation sensor Bosh BNO055.

Eryk Możdżeń 1 Nov 20, 2021
An optimized "RTOS" (more than HAL but less than RTOS) for ROV controling and getting sensor data

Nitori-ROV-OS 一个专门为水下机器人(ROV、AUV)进行优化的实时操作系统,暂命名为 Nitori,中文名 荷取 可以通过修改硬件兼容层(Port)进行移植 预计最初版本支持stm32f407和stm32h750,并在实验室目前的水下机器人中进行部署 系统分为四层,六个主要组件: 硬件

Doublues_G 2 Jan 10, 2022
Arduino Audiokit HAL (support for ES7148, ES7210, ES7243, ES8311, ES8347, ES8388, TAS5805M, AI-Thinker)

Arduino AudioKit HAL There are different ESP32 AudioKit boards available that can be programmed with the Espressif ADF Framework. The ADF Framework co

Phil Schatzmann 67 Jan 2, 2023
Sharpmake is an open-source C#-based solution for generating project definition files, such as Visual Studio projects and solutions, GNU makefiles, Xcode projects, etc.

Sharpmake Introduction Sharpmake is a generator for Visual Studio projects and solutions. It is similar to CMake and Premake, but it is designed for s

Ubisoft 779 Dec 23, 2022
A package to provide plug-in for Livox Series LiDAR.

Livox Laser Simulation A package to provide plug-in for Livox Series LiDAR. Requirements ROS(=Melodic) Gazebo (= 9.x, http://gazebosim.org/) Ubuntu(=1

livox 83 Dec 13, 2022
A set of projects for quickly calculating the sine function using Chebyshev polynomials

sin_approx_04 Содержит несколько проектов, написанных на языке С. Цель их создания - реализовать быстрое вычисление тригонометрической функции синуса

null 8 Jul 11, 2022
A set of tutorial projects for creating a simple digital radio receiver based on the STM32G431KB microcontroller

simple-radio Обучающие проекты по созданию простого цифрового радиоприемника на базе микроконтроллера STM32G431KB. Разработка программ выполнялась в W

null 9 Sep 21, 2022
A set of one-line C++ macros to simplify the creation of reccurent things in Qt projects

QDefs A set of one-line C++ macros to simplify the creation of reccurent things in Qt projects (like Qt Meta Properties) so that doing them in C++ is

null 3 Nov 2, 2022
A graphical interface to set options on devices with coreboot firmware

Corevantage A graphical interface to set options on devices with coreboot firmware. Introduction This is a utility that allows users to view and modif

null 31 Dec 20, 2022
STM32 firmware for a physical switch to set the GRUB boot selection

STM32 firmware for a physical switch to set the GRUB boot selection

Stephen Holdaway 318 Jan 4, 2023