BLE stack installation

andreas23 · ‎2020-07-09

Hello.

I'm using a custom PCB with the STM32WB50 controller. I think I successfully upgraded the FUS from version 0.5.3 to 1.0.2 and finally to 1.1.0 (when I read 0x20030030 I get 01010000). Then I tried to install the BLE light stack as described in the Release Notes of the STM32CubeWB framework. But I'm not sure if this was successful because I get some error messages during fwupgrade.

File download complete
Time elapsed during download operation: 00:00:27.389
 
RSS_GET_STATE_COMMAND status : 0x0
 
   RSS state : FUS_IDLE
 
   Error : FUS_NO_ERROR
 
RSS_GET_STATE_COMMAND status : 0x0
 
 
Firmware Upgrade process started ...
 
 
FIRMWARE_UPGRADE_COMMAND status : 0x0
 
   RSS state : FUS_IDLE
 
Waiting for firmware upgrade end
checking FUS state ...
Reconnecting...
Reconnected !
Success with Time elapsed during Reconnect: 2066 ms
 
Response received from device: NACK
Special Command not acknowleged
Reconnecting...
failed to reconnect after reset !
Failing with Time elapsed during Reconnect: 22660 ms
Unable to reconnect. Firmware upgrade finished.
Firmware Upgrade Success

At the end it tells me that the upgrade was successful but some lines above I get "failed to reconnect after reset". So, I'm not sure if this was working. I also have seen that after flashing the BLE stack, I don't get the version of FUS from the memory address. Is this the normal behavior?

If I send -fusgetstate two or three times, I suddenly get some positive response. And also the version number of FUS is visible again.

Nevertheless, I tried to make the BLE Beacon example running. What I have seen is that the SHCI related commands are working. So, I get some response from the Cortex M0 coprocessor. But when it comes to the BLE initialization my program gets stuck when "hci_reset" is called. The hci_cmd_resp_release function is never called. Does this mean that the BLE stack is not working correctly?

I also tried to send SHCI_GetWirelessFwInfo from the firmware to get some information about the stack. But the version number for FUS and the wireless stack is 0 (major and minor). What does this mean? Can someone explain this?

Thanks,

Andreas

Remi QUINTIN · ‎2020-07-09

Don’t worry, some error messages sound weird but in fact all was done well. The best to check when you have a doubt about the successfulness of the RF stack installation is to look at the SFSA option byte. If it is 0xCB for the full BLE stack, then the programming was correct.

You have to know that when the RF stack is working the FUS is not and so the FUS version is not available anymore when the FUS is not working.

When you send a fusgetstate command, you activate the FUS and its first action is to write its version somewhere in SRAM memory where its workspace is located.

Once the BLE beacon application is installed on the device, just reset the board and it should work. I understand you are using your custom board but if you did not change a line of the code, it should be working.

andreas23 · ‎2020-07-10

Thanks for your answer. This makes some things much clearer now.

Right now, I flashed the BLE full stack and the SFSA option byte is telling me 0xCB. So, I think this should be correct. I also printed the version of the stack and the FUS with the SHCI_GetWirelessFwInfo and I think this time, they should be correct (got 1.1 for FUS and 1.6 for the wireless stack).

But what I see now, is that the SHCI_C2_BLE_Init command does not return and my firmware blocks. It seems like the IPCC interrupt is never called.

Because I'm using the STM32WB50 chip and not the STM32WB55 could some wrong parameters of the SHCI_C2_Ble_INit_Cmd_Packet_t struct cause that the C2 controller sends no response back?

Is there any documentation for the parameters in the SHCI_C2_Ble_INit_Cmd_Packet_t struct?

Is there some way to test if the communication with the coprocessor is really working?

Thanks,

Andreas

Remi QUINTIN · ‎2020-07-30

Regarding some clarifications on the SHCI_C2_Ble_INit_Cmd_Packet_t structure, please have a look at the application note AN5289.

One way to test the BLE functionality is to load the BLE_p2pServer_reference.hex binary at 0x08000000. This code is located under

STM32Cube_FW_WB_V1.7.0\Projects\P-NUCLEO-WB55.Nucleo\Applications\BLE\BLE_p2pServer\Binary.

Then use your mobile to check if you can detect/connect to a BLE device named P2PSRV1.

You can also download the ST BLE sensor application to connect to your device.

GD'Av.1 · ‎2020-09-08

Have you solved your problem?

I am in a very similar situation:

the same issue with SHCI_C2_BLE_Init that does not return, but I use STM32WB55 chip on my custom PCB (the same of the evaluation board).

I have custom FW too, that runs perfectly on evaluation board, but stall on custom board.

Also BLE_p2pServer_reference.hex binary does not work on my custom board.

Thomas Laurenson · ‎2020-10-21

Hello,

Late response, I don't know if you solved your issue or not.

I faced the same problem today: I was stuck in SHCI_C2_BLE_Init ().

In fact the BLE stack did not start.

Our custom board prototype was working but the first batch of production was not.

We copied exactly the design from the nucleo WB55 board, at least for the RF part, and as I said, on our 1st prototype everything was ok.

But on the first batch of production the 32Mhz oscillator needed by the CPU2, noted 'X1 NX2016_32M' on the nucleo board, was miss placed due to pick and place programmation error.

Once placed correctly, CPU2 repsonded correctly and everything worked as intented.

So if your code is working on a the nucleo board, I suggest that you take a look at your custom board design.

Best,

Thomas