Hello there,
I am facing an issue with my Flipper Zero, which only arrived recently.
Every night and sometimes during the day as well, the Flipper crashes with the error message:
ST(R) Copro(R) HardFault
I use the Flipper to control some LEDs using GPIO with my own Bluetooth app, so it becomes quite annoying when the Flipper randomly stops working.
What could be done about this? Happy to provide any additional information.
Have you tried restoring new recent firmware? dev/org ? I had weird crashes with some older unsupported setups, and running certain applications that are not that memory friendly will manage to crash it but if you restore recent firmware it will prolly feel a lot happier.
Using qflipper or other upgrade methods to keep your fw update is definitely worth the effort especially if you have unstable stuff. If you are running original or other fw options, i definitely would recommend upgrading/restorign it again first to solve any issues you experience with older configurations.
see Releases · flipperdevices/flipperzero-firmware · GitHub Known Issues:
Periodic Core2 HardFauls in sleep mode, currently is being investigated by ST, waiting for their conclusion. Workaround: switch sleep mode to Legacy. Details on deep sleep can be found in our blog 1 Month Battery Life with Firmware Update Issues can be reported on our forum: Flipper Zero Low power mode
that might be the issue you experience.
Thanks for the responses.
I will do some testing to see how different firmware versions and enabling/disabling deep sleep and/or BT helps.
A comment on Reddit by user u/tehhedger seems to provide some more insight:
We have no idea what happens on the second core that is responsible for BT. Its firmware is an encrypted blob, provided by chip manufacturer, and the only way to communicate with it is over shared memory and a set of hardware semaphores.
Flipper’s MCU has hardware-enforced security mechanisms protecting that second core, so we cannot do anything to inspect its state besides very limited GPIO debug outputs that are mostly useless in this particular case, since we have no idea of second core’s internal workings.
That second core manages its state on its own, and we cannot force it into low-power states needed for proper deep sleep. We can only arrange certain conditions and expect it to enter sleep mode. Furthermore, we cannot restart that second core without resetting the whole MCU, if it fails for any reason.
Sometimes, with deep sleep enabled, second core encounters a hard fault and halts. From the main firmware running on first core, we can only see an indication that such fault had happened. And since there are no recovery mechanisms from that state besides whole chip reset, that’s what we do. And display that particular message.
We reported the issue to ST, chip manufacturer, and they confirmed that it indeed exists. However, they didn’t give us any estimate on new C2 firmware that would have that fixed. And they didn’t suggest any workarounds. So we have to wait.
Seems like solutions are being worked on as we speak. We just have to give it some more time.
There is however one major component, which seems completely omitted from the discussion:
It seems to be a binary problem. As in, you have it or you don’t.
How can this be, if not for some hardware issue / quality control gone wrong / etc?
Be transparent about this. The Flipper community is quite well connected, this isn’t the sort of thing you can just sweep under the rug.
This sounds like info from the blog post about deep sleep. It was very interesting.
I think you quoted the answer yourself. The problem is somewhere in ST’s encrypted blobs, and nobody but them knows why. The only thing the Flipper devs did wrong is not finding it early in QA.
It also begs the question: why did they choose this component?
It literally says on the landing page of the Flipper that the product is “fully open-source”.
What alternative components can you suggest that have the same feature set, consume the same (or smaller) amount of power, were available in mid 2020 in bulk quantities (40K units or more), cost the same as the STM32WB55 (or less) and have a similar footprint (to actually fit inside the Flipper)?
Answering your question - we chose STM32WB55 because it’s what was available at that time. Choosing pretty much anything else would mean a compromise on either manufacturing time (which was already way behind schedule), performance, price, or any combination of those.
As for the issue in question - the current solution is to switch the Sleep mode to Legacy in system settings.
This issue is very intermittent and happens pretty much randomly, so even though our QA team spent a lot of time testing it on multiple devices, they just were unlucky enough that it never happened on the testing rigs.
Still, it’s not a significant issue - just switching one toggle in the settings fixes it for now (though it undoes our power-saving efforts, but that’s temporary).
Thank you very much for the open conversation and insight about it.
My candor was merely feedback about how I, as a customer, felt about this whole situation.
The juxtaposition of a supposedly fully open source device and issues arising from “encrypted blobs” in the hardware just didn’t sit right.
The binary blobs suck but that’s the problem with most open source devices. It’s put a real damper on the open source smartphone market. Progress on PinePhone hasn’t been great. I had hoped to have something with a full days battery life by now. 
This topic was automatically closed after 11 days. New replies are no longer allowed.