2024-02-07 08:47 AM
assert_failed() is being called inside BleStack_Init() with USE_FULL_ASSERT defined. By default, Stm32CubeMx does not define USE_FULL_ASSERT so assert_failed() would have never been called.
Either way, BleStack_Init() returns zero causing APP_BLE_Init() to initialize gapp and gatt. No problems.
Question: Is the call to assert_failed() by design? Should I ignore assert_failed() during a call to BleStack_Init().
I am using Nucleo-WBA52CG, STM32Cube_FW_WBA_V1.2.0, arm-gnu-toolchain-13.2.Rel1-x86_64-arm-none-eabi and Ubuntu 22.
2024-02-07 03:21 PM - edited 2024-03-08 02:09 PM
> Should I ignore assert_failed()
No, you should understand why it is called and why the developer placed the assert statement at that place. Yes, it can be mistake or bug, but more likely it is not.
2024-03-08 01:15 PM
I am still getting an assert failure while calling BleStack_Init(). I get the failure in both stm32wba_ble_stack_basic.a and stm32wba_ble_stack_full.a.
Here is the call stack at the time of failure using stm32wba_ble_stack_basic.a and LinkLayer_BLE_Basic_lib.a.
The failure occurs in mem_pool_init(). Unfortunately, the assert doesn't come with an error code or a cause.
Any idea what the cause might be and how to fix the failure?