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

Overview

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

Troubleshooting

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.

Issues
  • 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
  • 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.

    image

    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

    Hello!

    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:

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

    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).

    https://github.com/STMicroelectronics/STM32CubeWB/blob/4a8759ffd65c098010fc60c9b1a2e3d59a1b4c0b/Middlewares/ST/STM32_WPAN/interface/patterns/ble_thread/tl/mbox_def.h#L75-L80

    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.

    ble 
    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.

    Log

    bug-ST-P-NUCLEO-WB55.log

    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)
    {
      USBD_LL_DevConnected(hpcd->pData);
    }
    
    /**
      * @brief  Disconnect callback.
      * @param  hpcd: PCD handle
      * @retval None
      */
    void HAL_PCD_DisconnectCallback(PCD_HandleTypeDef * hpcd)
    {
      USBD_LL_DevDisconnected(hpcd->pData);
    }
    

    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
  • stm32wbxx_hal_exti.c fails to build with -Werror=unused-parameter

    stm32wbxx_hal_exti.c fails to build with -Werror=unused-parameter

    Describe the bug stm32wbxx_hal_exti.c fails to build with -Werror=unused-parameter. Screenshot 2021-12-05 at 10 44 27

    Possible Fix The following change fixes the issue. I would be more than happy contributing but unclear to me what CLA I should get with ST to contribute. Maybe you can help me clarifying. Screenshot 2021-12-05 at 10 46 59

    bug duplicate internal bug tracker hal 
    opened by juliengros 4
  • Wrong BLE

    Wrong BLE "full" stack address ?

    Trouble BLE_HeartRateFreeRTOS not working on Nucleo board after import and stack programming according the releases notes.

    Maybe a wrong value in the documentation.

    Steps to reproduce . Import the BLE_HeartRateFreeRTOS project in the IDE. Stack version 1.13.3. . Compile the Release variant . Update the FUS of the Nucleo board if needed . Program the stack "stm32wb5x_BLE_Stack_full_fw". The programmer suggests the address 0x080AC000, whiles the releases note tells 0x080D0000. Choose 0x080D0000. . Flash the test program compiled before . Start the software. HRSTM device could not be find by a Android device for example.

    Repeat the same steps, but with the 0x080AC000 address for stack programming. The HRSTM device created on the Nucleo board could be detected.

    I verified twice.

    Describe the set-up Laptop, W11 up to date

    • The board (either ST RPN reference or your custom board). P-NUCLEO-WB55 board

    • IDE or at least the compiler and its version. STM32CubeIDE 1.9.0 and STM32CubeProgrammer 1.9.0

    Additional context Just testing BLE features on new specific boards from our company. I had to get back to the Nucleo board because nothing worked as expected. Even on the Nucleo board the examples didn't worked out of the box.

    Proposed correction https://github.com/STMicroelectronics/STM32CubeWB/blob/master/Projects/STM32WB_Copro_Wireless_Binaries/STM32WB5x/Release_Notes.html should be corrected :

    For STM32WB5xxG(1M) : stm32wb5x_BLE_Stack_full_fw.bin : 0x080AC000

    Merci, Best regards, Pascal

    projects ble 
    opened by pdelrot-samea 1
  • BLE Event Callbacks not working (ble_events.h)

    BLE Event Callbacks not working (ble_events.h)

    I'm trying to use the ble event callbacks given in "ble_events.c".

    So im implementing the function:

    aci_gatt_attribute_modified_event( uint16_t Connection_Handle,
                                                   uint16_t Attr_Handle,
                                                   uint16_t Offset,
                                                   uint16_t Attr_Data_Length,
                                                   const uint8_t* Attr_Data )
    {
      
    }
    
    

    but it get never called. The switch case option gets called!

    The Description describes that in default all events are masked, so it should not be necessary to mask it with: aci_gatt_set_event_mask(0x00000001); which changes nothing anyways.

    In the manual PM0271 Page 38 is described that the switch case as well as the callback framework can be used for the ble stack events. image All Examples use the switch case statement, an issue (https://github.com/STMicroelectronics/STM32CubeWB/issues/24) regarding that is solved, with the comment that one example was added -> I found the example "BLE_Peripheral_Lite_EventCallbacks", but it uses the "switch case" event handler and calls from there the "callbacks" in ble_events.

    So to use the callbacks I have to implement the switch case event handler and have to call functions from there, not really how it should be and not really callbacks. In that case the "ble_events" source and header files are useless. So how should it work?

    opened by buchvC 1
  • Potential variable name clash with C macros

    Potential variable name clash with C macros

    Version: v1.13.3 File: ./Drivers/STM32WBxx_HAL_Driver/Inc/stm32wbxx_hal_pwr_ex.h

    void              HAL_PWREx_HoldCore(uint32_t CPU);
    void              HAL_PWREx_ReleaseCore(uint32_t CPU);
    

    Usage of all upper-case for a variable name (may) clash with with macro definitions (which in many style guides shall use all upper-case).

    hal 
    opened by 42Bastian 0
  • P-NUCLEO-WB55.Nucleo BLE_TransparentMode bug in UART initialization when porting to a user board using LPUART1 instead of USART1.

    P-NUCLEO-WB55.Nucleo BLE_TransparentMode bug in UART initialization when porting to a user board using LPUART1 instead of USART1.

    Hello,

    In STM32Cube_FW_WB_V1.13.1/Projects/P-NUCLEO-WB55.Nucleo/Applications/BLE/BLE_TransparentMode/STM32_WPAN/App/tm.c

    line 170, there is a call to MX_USART1_UART_Init();

    It should be dependent upon definition of CFG_HW_LPUART1_ENABLED or CFG_HW_USART1_ENABLED, to either init USART1 or LPUART1.

    Best regards, Xevel

    projects ble 
    opened by Xevel 1
  • Malformed beacon from non-compliant zigbee device causes stack to crash

    Malformed beacon from non-compliant zigbee device causes stack to crash

    Describe the set-up

    • STM32WB5MMG on custom board
    • M0-core loaded with stm32wb5x_Zigbee_FFD_fw.bin v. 1.13.2
    • STM32CubeIDE v. 1.9.0
    • GNU Tools for STM32 (10.3-2021.10)

    Describe the bug In our testing environment (an office building) there is a piece of equipment that continuously broadcasts what looks like a zigbee beacon. According to wireshark the beacon is malformed and I expect this device to be some sort of proprietary (non-conforming) equipment that uses a 2.4 GHz IEEE 802.15.4 transmitter.

    However when our board starts scanning for a network it picks up this "beacon" and then the M0 core simply locks up. I would expect the stack to be immune to malformed packets but it looks like it is not.

    The M4 host is blocked waiting for EVENT_ZIGBEE_STARTUP_ENDED.

    How To Reproduce I have taken our board into a silent environment and set up an offending transmitter to mimic the problematic beacon, and the behaviour of our board is the same: As soon as I turn on the transmitter the M0 core/stack locks up. It appears to always happen on (or after) the last scan attempt but I cannot say for sure.

    The raw data in the malformed beacon is: 00 80 56 00 05 FA 07 22 CF 00

    Debug console output [M4 APPLICATION] Network config : APP_STARTUP_CENTRALIZED_ROUTER [M0] [00000002.020][PLATFORM] ZbNlmeResetReq : NLME-RESET.request (warmStart = 0) [M0] [00000000.011][PLATFORM] zb_startup_join_nwk_disc : Attempting network discovery. Scans = 3, Duration = 4 [M0] [00000000.012][PLATFORM] nwk_scan_req : MLME-SCAN.request (wpan0): type=1, page=0, mask=0x02108001, dur=4 [M0] [00000000.807][API] Scan Done - unscan channels 0x1 [M0] [00000000.827][PLATFORM] nwk_scan_req : MLME-SCAN.request (wpan0): type=1, page=0, mask=0x02108001, dur=4 [M0] [00000001.622][API] Scan Done - unscan channels 0x1 [M0] [00000001.623][PLATFORM] nwk_scan_req : MLME-SCAN.request (wpan0): type=1, page=0, mask=0x02108001, dur=4

    Wireshark dump Skærmbillede 2022-04-29 kl  11 42 53

    internal bug tracker 
    opened by tennispedersen 1
  • 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

    Set-up

    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).

    Reproduction

    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:

        while(__HAL_RTC_WAKEUPTIMER_GET_FLAG(phrtc, RTC_FLAG_WUTWF) == RESET);
    

    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);
        

        becomes

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

        becomes

        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

    st community 
    opened by mdiepart 4
Owner
STMicroelectronics
STMicroelectronics is a world leader in providing the semiconductor solutions that make a positive contribution to people’s lives, today and into the future.
STMicroelectronics
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 5 Jun 25, 2022
CMSIS-DAP using TinyUSB

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 47 Jun 11, 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 189 Jun 25, 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 21 Jun 3, 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 3 Apr 21, 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 40 Jun 20, 2022
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 743 Jun 10, 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 62 May 25, 2022
A set of projects for quickly calculating the sine function using Chebyshev polynomials

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

null 7 May 10, 2022
A set of tutorial projects for creating a simple digital radio receiver based on the STM32G431KB microcontroller

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

null 7 Apr 11, 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 2 Jan 28, 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 30 Jan 22, 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 307 Jun 14, 2022