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?

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 )
          |       ^~~~~
          |       ;
...

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.

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.

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.

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

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.

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

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?

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?

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

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.

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

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

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

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

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

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