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.

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

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?

Set-up

• 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 */
#else
#define FLASH_PAGE_SIZE                         0x00001000U  /*!< FLASH Page Size, 4 KBytes */
#endif

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
     */
    HAL_PWR_EnableBkUpAccess();

    __HAL_RCC_BACKUPRESET_FORCE();
    __HAL_RCC_BACKUPRESET_RELEASE();
  }

  return;
}
[...]

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?

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;

  UTIL_SEQ_RegTask( 1<< CFG_TASK_HID_UPDATE_REQ_ID, UTIL_SEQ_RFU, HIDSAPP_Profile_UpdateChar );

  result = HIDS_Update_Char(REPORT_MAP_CHAR_UUID, 
                            0, 
                            0, 
                            sizeof(report_keyboard),
                            (uint8_t *)&report_keyboard);

  if( result == BLE_STATUS_SUCCESS )
  {
    BLE_DBG_APP_MSG("Report Map Successfully Sent\n");
  }
  else 
  {
    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,
						  0,
						  0,
						  8,
						  hid_buffer);
  if( result == BLE_STATUS_SUCCESS )
    BLE_DBG_APP_MSG(" d press\n");
  else
	BLE_DBG_APP_MSG(" d press FAILED\n");

  hid_buffer[2] = 0;
  result = HIDS_Update_Char(REPORT_CHAR_UUID,
		  	  	  	  	    0,
							0,
							8,
							hid_buffer);
  if( result == BLE_STATUS_SUCCESS )
	BLE_DBG_APP_MSG(" d release\n");
  else
	BLE_DBG_APP_MSG(" d release FAILED\n");
}

3. 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                  \
  BLE_CFG_HIDS_INPUT_REPORT_NB   +\
  BLE_CFG_HIDS_OUTPUT_REPORT_NB  +\
  BLE_CFG_HIDS_FEATURE_REPORT_NB
#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 and fails. When I set BLE_CFG_HIDS_INPUT_REPORT_NB to 0 the Output Report gets processed correctly but as expected "d" is not send to the PC.

How can I get both working? Thank you.

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

WARNING

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:

• stm32h7xx_hal_driver
• stm32u5xx_hal_driver
• STM32CubeG4 but fixed in STM32G4xx_HAL_Driver

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