STM32WB BLE SHCI_SUB_EVT_CODE_READY Event is NOT received

[Amogh]

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

[Remy ISSALYS]

Hi,

First, with which stack version your screenshots with memory were taken ?

With your screenshot, we can see that CPU2 is in hardfault when SHCI_SUB_EVT_CODE_READY is NOT received. In this case (e.g. breakpoint doesn't get hit), could you click on "Break" button of the debugger and take a screenshot of call stack please and check flash SR register ?

Did you use TIM1, TIM16 or TIM17 ?

When you turn optimizations to LOW, the issue disappears or not ?

Best Regards

[Amogh]

Hi,

• We have 1.13.3 as our BLE Stack.

 

• Can you please elaborate, on how did you deduce CPU2 experienced hardfault? Please see attached pictures that show CPU is somewhere in RTOS Scheduler - (waiting for something..?)

Screenshots shows the Flash Status Bytes before callback is attached, and after IPCC is initialized =>

 

Screenshots shows where the CPU is Spending its time When IPCC is Expected..

 

 

• in CubeMX : SYS : we have TIM16 as TimeBase Source.
• Sorry about a mistake, but I should have written NONE instead of LOW. We have to turn OPTIMIZATIONS to NONE to ensure IAR can build in RELEASE Mode, and BLE Works. But again, its intermittent, i.e. when we make small changes, BLE IPCC stops.

Thanks

[Remy ISSALYS]

Hello,

Thanks for your answer.

At the address 0x20030000, you have the hardfault keyword according to AN5289:

And with flash register, we can see that flash is in error maybe causes by writing data at address 0x00000000 of the flash (e.g null pointer).

To find the root cause of your issue, you can use MPU by adding the following code:

In main.c :

static void MPU_AccessPermConfig(void);

/**
* @brief This function configures the access right using Cortex-M4 MPU regions.
* @param None
* @retval None
*/
 
static void MPU_AccessPermConfig(void)
{
  MPU_Region_InitTypeDef MPU_InitStruct;
  /* Disable MPU */
  HAL_MPU_Disable();
 
  MPU_InitStruct.Enable = MPU_REGION_ENABLE;
  MPU_InitStruct.BaseAddress = 0;
  MPU_InitStruct.Size = MPU_REGION_SIZE_1MB;
  MPU_InitStruct.AccessPermission = MPU_REGION_PRIV_RO;
  MPU_InitStruct.IsBufferable = MPU_ACCESS_NOT_BUFFERABLE;
  MPU_InitStruct.IsCacheable = MPU_ACCESS_NOT_CACHEABLE;
  MPU_InitStruct.IsShareable = MPU_ACCESS_NOT_SHAREABLE;
  MPU_InitStruct.Number = MPU_REGION_NUMBER0;
  MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0;
  MPU_InitStruct.SubRegionDisable = 0x00;
  MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_ENABLE;
  
  HAL_MPU_ConfigRegion(&MPU_InitStruct);
  /* Enable MPU (any access not covered by any enabled region will cause a fault) */
  HAL_MPU_Enable(MPU_PRIVILEGED_DEFAULT);
  
  return;
}

Call this function after SystemClock_Config like this:

SystemClock_Config(); 
MPU_AccessPermConfig();

Add a breakpoint in MemManage_Handler function.

Run your project with debugger and check if fault exception occurs and look call stack when the fault occurs to see cause of this fault.

 

Best Regards

[Amogh]

Hello,

Thanks for such a detailed response.

I followed your advise and attached below are the screenshots for

1. Stack at Hardfault Failure
2. Locations where the function causing failure is present.
3. Instruction(@PC) which is causing the failure

 

 

I am assuming since uxListRemove() is the last function on the stack, and since NULL node is being removed, a crash happens. Would I be correct?

I am still looking into the exact location in the file where this function is called.

 

Thanks

Amogh

[ttnickb]

Was this issue ever resolved?

I believe I am seeing something similar: no SHCI_SUB_EVT_CODE_READY received using stack 1.13.3 and a custom app for STM32WB55 based on BLE_HeartRateFreeRTOS.

Unlike the report here, I see 0x20030134 at address 0x20030000 (so no Hardfault). Decoding the flash seems to indicate correct stack information at address 0x20030134 (v1.13.3).

Thanks

[ttnickb]

I think I found my issue. I added a check on the return code for `osThreadFlagsWait() == 0` in the SHCI user event process. This is not the correct comparison to use, and was causing `shci_user_evt_proc()` to not be called. So my issue is probably not the same as the original post here...but figured I'd share.

[DSili.1]

Hello, 

Did you solve the problem? I have absolutely the same problem and spent a lot of time trying to solve it but without any result. I will be very grateful for your answer.

Best regards,
Dmitriy

[thomasonw]

For anyone who reached this, I too had the same issue:  CPU2 faulting.

It seems the solution for me was this:  https://forums.freertos.org/t/stm32wb55-flash-sr-cfgbsy-never-clears-when-using-freertos-and-tim1/12300

I too am using FreeRtos ontop of BLE-OTA, and noted that if Flash->SR->CFGBSY was set at the time of CPU2 reset via TL_Enable(); CPU2 would wedge.   Adding the above NULL check into HTIM1.Instance seemed to resolve this.

In the end, maybe not the problem, but surely a problem.  Hope this can help others.