cancel
Showing results for 
Search instead for 
Did you mean: 

Programming and Running BLE stack in CPU2

ABN
Associate III

Greetings,

Currently the project has a requirement for a Custom BLE server profile. I have a few doubts, for which I'm seeking clarifications.

  1. I flashed the 'stm32wb5x_BLE_Stack_full_fw' v1.14 at the specified memory location as per the release notes. The binary was successfully upgraded. When I perform the step debug, the 'WirelessInfo' returns the proper values. In the next step, most of the times 'p_sys_ready_event' returns FUS_FW_RUNNING instead of WIRELESS_FW_RUNNING. What is the cause for this? Even though the wireless stack is programmed why does the return value is not proper?
  2. When the return value of p_sys_ready_event is proper(WIRELSS_FW_RUNNING), the program moves forward. Program hits the 'APP_BLE_Init' function and the command packet is initialized. Then 'SHCI_C2_BLE_Init' is hit. This function is returns the status with the value 0x04(undefined in the documents) and the program gets stuck in Error handler(). Based on the comments provided before the error handler function, CPU2 might not have the wireless binaries. If that is the case, then the wireless info should have returned the improper value right? What might be the reason for the program to hit Error handler instead of moving forward?

Awaiting your response at the earliest.

Thanks,

Akash Bharadwaj

1 ACCEPTED SOLUTION

Accepted Solutions
Remi QUINTIN
ST Employee

A quick answer:

Wen using CubeProgrammer to flash the device, you have to check the "Start Wireless stack" button to ensure the program counter of the M0+ cote (CPU2) is indeed set at the start of the wireless stack.

Otherwise the CPU2 will never execute the wireless part and instead will remain on the FUS. This can explain your second point as CPU2 when launched by CPU1 is not executing the right code.

View solution in original post

2 REPLIES 2
Remi QUINTIN
ST Employee

A quick answer:

Wen using CubeProgrammer to flash the device, you have to check the "Start Wireless stack" button to ensure the program counter of the M0+ cote (CPU2) is indeed set at the start of the wireless stack.

Otherwise the CPU2 will never execute the wireless part and instead will remain on the FUS. This can explain your second point as CPU2 when launched by CPU1 is not executing the right code.

ABN
Associate III

@Remi QUINTIN​ 

Thanks for the update.