2022-04-01 06:58 AM
Hello,
I am trying to figure out a root cause for a weird unexplainable error on STM32WB with BLE Stack.
In our application, we have BLE stack fully functional, but every now and then, when we make a small change, like adding a debug line, APPE_SysUserEvtRx callback function doesn't receive a SHCI_SUB_EVT_CODE_READY event.
If we move the change couple of lines down, some times this works, some time it doesn't. Its really very frustrating, as I have not been able to figure out what is causing this issue?
Any help/pointer is much appreciated.
Thanks
2022-04-04 03:12 PM
I would like to explain the problem a little bit more if possible.
BLE Stack works fine, but when I make small changes, ie uncomment line 1002, and 1003, I DO NOT get a SHCI_SUB_EVT_CODE_READY event.
We are using RTOS, with BLE co-processor binary version 1.13
Can anyone from ST please provide some insights as to what might be the cause of this behavior?
Thanks
2022-04-05 01:06 PM
Hi Remi, @Remi QUINTIN
I was wondering if you can please provide some guidance on why
APPE_SysEvtReadyProcessing()
receives
p_sys_ready_event->sysevt_ready_rsp == FUS_FW_RUNNING
instead of
p_sys_ready_event->sysevt_ready_rsp == WIRELESS_FW_RUNNING
when I make small non-essential /non BLE related changes in the app_ble.c or custom_app.c, or custom_stm.c.
Thanks
2022-04-06 02:53 AM
Hello,
What is happening when SHCI_SUB_EVT_CODE_READY event is not received ? Can you stop the debugger and look where are in the code ? Check call stack and logs please.
Where is your ad_data declaration ?
Which version are you using ? If it's 1.13.0, can you retry with the latest release v1.13.3 please.
Your last comment told about a second issue ?
Best Regards
2022-04-06 07:12 AM
Hello,
Thank you for responding!
ad_data is declared in app_ble.c, and I am just trying to change the local_name of the device, based on Mac Address. The problem is not just related to ad_data because even when I try to write to a characteristic and call a local function, SHCI_SUB_EVT_CODE_READY isn't received. I am not sure why and how something in the BLE thread can interfere and prevent the thread from even starting up.
Please see declaration of ad_data.
uint8_t ad_data[22] = {
2, AD_TYPE_TX_POWER_LEVEL, 6 /* 6dBm */, /* Transmission Power */
9, AD_TYPE_COMPLETE_LOCAL_NAME, '9','0','x', 'X', 'X', 'X', 'X', 'X', /* Complete name */
3, AD_TYPE_16_BIT_SERV_UUID_CMPLT_LIST, 0x0D, 0x18,
4, AD_TYPE_MANUFACTURER_SPECIFIC_DATA, 0x30, 0x00, 0x00 /* */,
};
step 1: when everything is working, programs jumps into the appe_Tl_Init below
static void appe_Tl_Init( void )
{
TL_MM_Config_t tl_mm_config;
SHCI_TL_HciInitConf_t SHci_Tl_Init_Conf;
/**< Reference table initialization */
TL_Init();
MtxShciId = osMutexNew( NULL );
SemShciId = osSemaphoreNew( 1, 0, NULL ); /*< Create the semaphore and make it busy at initialization */
/** FreeRTOS system task creation */
ShciUserEvtProcessId = osThreadNew(ShciUserEvtProcess, NULL, &ShciUserEvtProcess_attr);
/**< System channel initialization */
SHci_Tl_Init_Conf.p_cmdbuffer = (uint8_t*)&SystemCmdBuffer;
SHci_Tl_Init_Conf.StatusNotCallBack = APPE_SysStatusNot;
shci_init(APPE_SysUserEvtRx, (void*) &SHci_Tl_Init_Conf);
/**< Memory Manager channel initialization */
tl_mm_config.p_BleSpareEvtBuffer = BleSpareEvtBuffer;
tl_mm_config.p_SystemSpareEvtBuffer = SystemSpareEvtBuffer;
tl_mm_config.p_AsynchEvtPool = EvtPool;
tl_mm_config.AsynchEvtPoolSize = POOL_SIZE;
TL_MM_Init( &tl_mm_config );
TL_Enable();
return;
}
step 2: and then into osKernelStart() function
osStatus_t osKernelStart (void) {
osStatus_t stat;
if (IS_IRQ()) {
stat = osErrorISR;
}
else {
if (KernelState == osKernelReady) {
/* Ensure SVC priority is at the reset value */
SVC_Setup();
/* Change state to enable IRQ masking check */
KernelState = osKernelRunning;
/* Start the kernel scheduler */
vTaskStartScheduler();
stat = osOK;
} else {
stat = osError;
}
}
return (stat);
}
step 3: and then the startup event is received
static void APPE_SysUserEvtRx( void * pPayload )
{
TL_AsynchEvt_t *p_sys_event;
WirelessFwInfo_t WirelessInfo;
p_sys_event = (TL_AsynchEvt_t*)(((tSHCI_UserEvtRxParam*)pPayload)->pckt->evtserial.evt.payload);
/* Read the firmware version of both the wireless firmware and the FUS */
SHCI_GetWirelessFwInfo( &WirelessInfo );
APP_DBG_MSG("Wireless Firmware version %d.%d.%d\n", WirelessInfo.VersionMajor, WirelessInfo.VersionMinor, WirelessInfo.VersionSub);
APP_DBG_MSG("Wireless Firmware build %d\n", WirelessInfo.VersionReleaseType);
APP_DBG_MSG("FUS version %d.%d.%d\n\n", WirelessInfo.FusVersionMajor, WirelessInfo.FusVersionMinor, WirelessInfo.FusVersionSub);
switch(p_sys_event->subevtcode)
{
case SHCI_SUB_EVT_CODE_READY:
APPE_SysEvtReadyProcessing(pPayload);
break;
.
.
.
.
step 4: and then wireless firmware starts
static void APPE_SysEvtReadyProcessing( void * pPayload )
{
TL_AsynchEvt_t *p_sys_event;
SHCI_C2_Ready_Evt_t *p_sys_ready_event;
SHCI_C2_CONFIG_Cmd_Param_t config_param = {0};
uint32_t RevisionID=0;
p_sys_event = (TL_AsynchEvt_t*)(((tSHCI_UserEvtRxParam*)pPayload)->pckt->evtserial.evt.payload);
p_sys_ready_event = (SHCI_C2_Ready_Evt_t*) p_sys_event->payload;
if(p_sys_ready_event->sysevt_ready_rsp == WIRELESS_FW_RUNNING)
{
/**
* The wireless firmware is running on the CPU2
*/
APP_DBG_MSG("SHCI_SUB_EVT_CODE_READY - WIRELESS_FW_RUNNING \n");
but when I make changes to the BLE thread - like uncomment
line 1003: ad_data[12] = 'j'
breakpoint/function in step3 is never hit.
I was initially on version 1.13.0.5 but even after updating to 1.13.3.2, I get the issue.
2022-04-06 09:46 AM
Hello,
When SHCI_SUB_EVT_CODE_READY event is not received, can you stop your debugger, take a screenshot of the call stack please and look what the CPU is doing ?
Can you also take a screenshot of the memory content at 0x20030000 (first 4 word of 32 bits) ?
Can you add a breakpoint in shci_notify_asynch_evt function and check if you see the event or not ?
Best Regards
2022-04-07 10:16 AM
Hi,
Thanks
2022-04-07 10:36 AM
Hello,
The Rootcause of the problem seems to the the IPCC Rx interrupt not being triggered. What I dont understand is why would a change in BLE thread stop this from happening?
Thanks!
* @brief This function handles IPCC RX occupied interrupt.
*/
void IPCC_C1_RX_IRQHandler(void)
{
/* USER CODE BEGIN IPCC_C1_RX_IRQn 0 */
/* USER CODE END IPCC_C1_RX_IRQn 0 */
HAL_IPCC_RX_IRQHandler(&hipcc);
/* USER CODE BEGIN IPCC_C1_RX_IRQn 1 */
/* USER CODE END IPCC_C1_RX_IRQn 1 */
}
2022-04-07 01:21 PM
Hi,
I was digging in to find the problems root cause and I dont know if this helps but also putting a breakpoint in the Reset_Device(Void) function below , and then pressing play, kills the any interrupt on IPCC. I am using IAR in debug mode, and have compiler optimizations to high.
static void Reset_Device( void )
{
#if ( CFG_HW_RESET_BY_FW == 1 )
Reset_BackupDomain();
Reset_IPCC();
#endif /* CFG_HW_RESET_BY_FW */
return;
}
This problem is really odd!
2022-04-08 09:00 AM
Hi Remy,
I am using IAR and I recently learned that setting compiler optimizations to HIGH also causes IRCC to miss any interrupts. Does this help narrow down the issue? When I turn optimizations to LOW, IRCC is able to catch the interrupts.