Skip to main content
nfei
Associate
March 19, 2019
Question

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

  • March 19, 2019
  • 13 replies
  • 4223 views

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

This topic has been closed for replies.

13 replies

Darren Legge
Associate
October 26, 2021

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
Associate III
October 27, 2021

@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
Associate
October 27, 2021

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.