SHCI_C2_Reinit produces error code 0xFE (and an invalid HCI command complete packet)

[HRadt.1]

I just updated SBSFU to version 2.4.0 (this version finally uses SHCI_C2_Reinit() to allow the application to run the regular initialization sequence even if C2 is already started by SBSFU)

SBSFU 2.4.0 now always initialized C2 (independently of it acutally being used) and calls SHCI_C2_Reinit before starting the external loader or the user application.

With 2.4.0 now our Bluetooth Loader does not start successfully anymore since C2 is already booted. The Bluetooth Loader uses the __SEV() method which should allow it to use C2 even if it is already initialized - under the condition that SHCI_C2_Reinit() has been called.

During investigations I realized that the call to SCHI_C2_Reinit() produces a non-zero error code. Specifically it produces 0xFE. This error code is not defined for HCI, and even if it is a custom error code, AN5289 does not give details on it.

One match I could find would be FUS_STATE_NOT_RUNNING (0xFE) which is a FUS state error value (ment to be obtained via SHCI_C2_FUS_GetState() ). Just in case this would be the case I checked with SHCI_C2_FUS_GetState() and FUS is indeed running (returns with error code 0x00 when called twice in a row). Also the SHCI_C2_FUS_LockUsrKey() completes successfully (this method is called shortly before SHCI_C2_Reinit() in SE_CRYPTO_Lock_Keys() ). So I assume FUS is running correctly on CPU2.

During debugging I also stumbled upon this:

An HCI command complete packet should have the following format:

But the command opcode fields do not reflect the opcode of SHCI_OPCODE_C2_REINIT (0xFC6F), but are instead set to the returned error code (254 / 0xFE, coincidence?):

(this is taken on the return line of SHCI_C2_Reinit in shci.c)

For other commands (checked SHCI_C2_FUS_LockUsrKey and SHCI_C2_FUS_GetState) the cmdcode field is set correctly.

Is there a problem with the SHIC_C2_Reinit command? Is it somehow an expected behaviour (but why then is __SEV() during application/loader C2 init not working?)

This issue is a large blocker for us, a timely response is highly appreciated. TIA!

Platform Details:

FUS 1.1.0

BLE Stack Full 1.8.0

STM32WB55CEU on custom board

[Christophe Arnal]

​Hello,

I am not sure of the working flow you need to implement but I believe the issue is that you are sending the SHCI_C2_Reinit() comand to the FUS. However, only the wireless firmware is supporting that command so the FUS should just report it does not support that comamnd.

If the plan is to jump from the SBSFU to the BLE Loader, it means it expects to load a wireless update firmware over OTA and this is not possible when the FUS is running on CPU2. You need the wireless firmware running on CPU2 for this.

The expecting working flow is that the SBSFU jumps on the BLE Loader only when the CPU2 runs the wireless firmware. If the FUS is running on CPU2, it measn a wireless update has been dowloaded and needs to be install and that is the responsibility of the SBSFU to complete the installation.

Is there any reason why the CPU2 is running the FUS when you are getting out from the SBSFU ?

Regards.

[HRadt.1]

Hello Christophe,

please be aware that the flow is implemented by the new 2.4.0 SBSFU version and not by me. This version always initializes CPU2 (regardless whether it is actually used) and calls SHCI_C2_Reinit() before launching anything else. If SHCI_C2_Reinit() is not supported by FUS, then SBSFU 2.4.0 is broken for the STM32WB55 in it's current form.

Also the naming suggests that SHCI_C2_Reinit() works on CPU2 regardless of which stack/fw is runing. And all documentation writes that it should only be used by SBSFU, which in it's default form never starts the wireless stack. This also lets me believe SHCI_C2_Reinit() was thought to be supported by FUS.

Is there any reason why the CPU2 is running the FUS when you are getting out from the SBSFU ?

This is nothing I implemented, it is like this in the official SBSFU release (for 2.4.0 in any case, for 2.3.1 only when launching a firmware after install)

So please note that even with the stock YMODEM loader SBSFU is not working correctly when launching a firmware that uses a wireless stack. That even got worse with SBSFU 2.4.0 since here even a reset can't make the firmware run, since CPU2 is always initialized by SBSFU. This was working in 2.3.1.

[HRadt.1]

I just tested again how SBSFU 2.4.0 behaves when wireless stack is running.

It seems like it is indeed working. Which actually causes more confusion for me. In SBSFU 2.3.1 I had to make sure FUS is running before invoking an image decryption, otherwise it would hang.

So it seems like the SHCI_C2_FUS_* methods are also available during wireless stack execution? Is this documented somewhere?

[Christophe Arnal]

​Hello,

SHCI_C2_FUS_*  are clearly NOT supported by the wireless stack except :

FUS_GET_STATE which is used to request the wireless firmware to switch on the FUS when called twice

and all SHCI_C2_FUS_*** related to Customer Key Storage (CKS) feature.

For all command related to CPU2 firmware update, you need the FUS running on CPU2

Regards.