Possible Deadlock in SBSFU while starting CPU2?

HRadt.1 · ‎2020-07-20

I'm in the process of integrating the SBSFU into a project.

I got stuck when the decryption process seemed to hang.

After I got the SeCoreBin symbols loaded I realized that it was waiting for CPU2 to become active (specifically while waiting for FLAG_WAIT_CPU2_RDY to be set to 0)

To make sure the FUS version was up to date I flashed a known-working application firmware and used it to read the FUS version (which is 1.1.0). But I noticed that I had to call SHCI_C2_FUS_GetState(..) twice, which means that the wireless firmware was running on CPU2.

Is it a problem for SBSFU when the wireless stack is running on CPU2? If not, what could cause shci_notify_asynch_evt not being called?

A deadlock here would mean a bricked product, which is of course not acceptable.

Thanks in advance!

HRadt.1 · ‎2020-07-20

I can reliably reproduce this by installing a firmware that uses the Wireless Stack (Bluetooth Full).

When I install the SBSFU afterwards it will always hang after transmitting an image (using the stock YMODEM protocol) while decrypting ("New Fw Encrypted, to be decrypted").