Something wrong with BLENRG-MS and STM32CubeExpansion_BLE1_4.2.0 sdk, program will trap in infinite loop at SPI_IRQ.

nfei · ‎2019-03-18

I use BLENRG-MS and stm32l07 mcu. Mcu call the APIs to control the BLENRG-MS module.

MCU initialize the ble module and start observer process by calling API,and the process will be terminated in three seconds.

The problem is that program may trap in infinite loop many times. The hci_tl driver is from STM32CubeExpansion_BLE1_4.2.0 packet. so whats the problem?

I found "while()" statement at hci_tl_lowlevel_isr() in STM32CubeExpansion_BLE1_4.2.0 sdk.

thanks.

/**
  * @brief HCI Transport Layer Low Level Interrupt Service Routine
  *
  * @param  None
  * @retval None
  */
void hci_tl_lowlevel_isr(void)
{
  /* Call hci_notify_asynch_evt() */
#ifdef HCI_TL
  while(IsDataAvailable())
  {
    hci_notify_asynch_evt(NULL);
  }
#endif /* HCI_TL */
 
  /* USER CODE BEGIN hci_tl_lowlevel_isr */
 
  /* USER CODE END hci_tl_lowlevel_isr */ 
}
static int32_t IsDataAvailable(void)
{
  return (HAL_GPIO_ReadPin(HCI_TL_SPI_EXTI_PORT, HCI_TL_SPI_EXTI_PIN) == GPIO_PIN_SET);
}

aj.sk · ‎2021-10-26

And will this usually terminate the connection or would the master just have to re-send the request?

Darren Legge · ‎2021-10-26

The connection stays up as I remember. The communication restarts when data is next sent to the BT controller (after which the interrupt is re-enabled). This is only a few ms later in my case. We are not currently using Bluetooth in production so I haven't looked at this for a long time, to be honest. Just testing it now and I can't make it get into the 'stuck' condition so maybe something else has changed. I am now using an BlueNRG-M0 instead of SPBTLE-RF0 for one thing...

aj.sk · ‎2021-10-26

@Darren Legge I have a quite large characteristic (155 bytes), it mostely happens when this one is read. I'll for sure keep your approach in mind!

Did you also modify hci_notify_asynch_evt? This is a function without return value...

Darren Legge · ‎2021-10-27

No, I didn't modify hci_notify_asynch_evt() in the end. I seem to remember it appeared like the BT controller was holding the interrupt pin active but no data got read back over SPI (I don't know why). Temporarily disabling the interrupt was the only way the code could continue to run. Our characteristics are all very short, and I was using X-CUBE-BLE1 4.4.0. Since the Bluetooth was just for a demo I didn't spend any more time trying understand the cause of the problem, I just used the work-around.

BErik.1 · ‎2024-02-26

We're using a work-around similar to yours:

void hci_tl_lowlevel_isr(void) {
      if (hspi1.Lock == HAL_LOCKED){
             SPIwasLocked = 1;
             return;
      }

but perhaps this problem was fixed in https://github.com/STMicroelectronics/stm32l4xx_hal_driver/commit/e49465048ae4329091e031dd9ae93fed1c2e3389 ?