Receiving HCI_HARDWARE_ERROR_EVENT event_time_overrun, advertising never observed

[towynlin]

My company is working on a product based on the STM32WB55, using the full BLE stack, currently v1.11.0. The error described below was also occurring on v1.10.1 previously.

As far as the host application on CPU1 knows, the device is advertising successfully. See logs such as:

[app_ble.c][Adv_Request][718] Successfully Start Fast Adv

However, I am never able to actually observe advertisements from a BLE scanning mobile phone app.

In BLE debug trace logs, I am receiving the following:

[tl_mbox.c][OutputDbgTrace][759] ble evt: 0x10
[tl_mbox.c][OutputDbgTrace][762]  payload: 02
[tl_mbox.c][OutputDbgTrace][777] 

According to AN5270, Table 311 in section 3.1 and Table 315 in section 3.1.4, this signifies HCI_HARDWARE_ERROR_EVENT with error code event_time_overrun, described as "bluecore time overrun error detected". I haven't found any more documentation anywhere about this.

Full log posted here: https://gist.github.com/towynlin/2744c2101c4175ab77154ddf1eca6312

User @MLancaster​ posted about the same error in early January and has not received a response. See https://community.st.com/s/question/0D53W00000TIcraSAD/receiving-hcihardwareerrorevent-from-ble-stack

Questions:

1. What can cause the CPU2 time overrun?
2. How can I prevent the overrun?
3. Is there something I need to do that I'm not doing, like resetting a watchdog timer?
4. Is the overrun a symptom of a bug in the BLE stack?
5. Would the time overrun in fact prevent advertising?

This is the highest priority blocker for the product and for the company right now, so nearly all my attention is on this issue. Thanks in advance for any and all help. Let me know if there's anything else I can provide or any testing I can perform.

[WD]

I have the same error, In the application that transmits data.

Too hard to develop BLE with STM32WB.

Should I use Nordic? :loudly_crying_face:

[towynlin]

We have done extensive testing internally and have isolated the problem to be between a STM32WB55CGU6 (48-pin UFQFPN48 package) which works fine and a STM32WB55VGY6TR (100 ball BGA WLCSP100 package) which gets the time overrun error. This is with both boards running FUS and full BLE stack 1.11.0, and running the exact same binary. We really need someone from ST to give us some information here. We need the bigger package to accommodate other changes, requiring more peripherals.

[towynlin]

I just want to let everyone know that ST is working with me on this issue in a support case right now. I'll update here as we figure things out.

[loopie]

Hey towynlin, do you have any news on this topic? We are facing the very same issue using a STM32WB5MMG.

[towynlin]

Hi @Simon Krütt​, thanks for following up, and sorry to hear you're having the same issue. Here's the story.

It took several weeks of conversations, but ST primarily recommended PCB layout changes to the GND layer and antenna circuit.

The biggest layout delta for us was changing the GND layer to be directly underneath the microcontroller. Originally, we had the immediate inner layer used for BGA breakout and PWR. We changed it to BGA breakout and GND. This provided a GND plane for the microcontroller, the High Speed oscillator, and the antenna.

We also added the antenna matching circuit. Originally, we misinterpreted ST's documentation on their IPD impedance matching chip. We thought we could go directly from microcontroller to IPD to antenna. However, it turns out we need to go microcontroller to IPD to antenna matching circuit to antenna. So, we added a pi filter before the antenna.

We also added more GND stitching vias around the antenna area, straightened the RF layout to eliminate angles in the trace, and tweaked the oscillator placement to have better GND plane filling around it.

All these changes together did ultimately get BLE working. However, we then started encountering unexpected audio streaming issues, which was frustrating.

During this process, we did a single, one-week-long sprint on nRF from scratch, and basically caught up to the functionality of our ST solution. At that point, we decided to move forward with Nordic based on pace of development and quality of support.

[FCasa.1]

Hello,

I am working on a custom board with the SoC STM32WB5MMG and I am facing the same problem receiving the event HCI_HARDWARE_ERROR_EVENT. As I understand from the discussion and related literature, the problem is related with the hardware design (I suppose in my case the problem is derivated from the noise present in power supply).

Do you have any tips which can be done to improve the problem. In my case filtering the power supply output has reduced the reproducibility of the event error but it is still happening after some time.

It would be much appreciated some support or guidance through the error.

Thank you in advance!

Best regards,

[APanev]

Hello FCasa1,

It seems like we solved the problem.

Firstly, we did a new PCB design. We followed the layout recommendations as close as possible. Given that in our case placing the module at a corner was not possible, we tried to keep that side free of copper. We tried to establish a connection but it didn't work.

Then we replaced the 3.3 V Buck converter with an LDO and now we are not experiencing the issue anymore (already for a week).

The Buck had a ripple of around 50mV, which apparently is too much. The module seems to be too sensitive, so probably switching to a linear regulator is better than filtering the ripple.

Soon we will test the old PCB design with a stable power supply in order to evaluate the influence of the layout only.

I hope I was helpful.

Best Regards

[FCasa.1]

Hello APanev,

Thank you for the response about the progress you experienced. Two weeks ago we implemented the same solution you are proposing, we substituted the step down converter we have for a LDO. We have seen that the error is not happening when just working with the BLE. By the other hand in our desgin we have other parts which work with a Buck&Boost regulator and the error appears to us again only when we start working with this regulator.

We are working in some improvements, I will inform in this thread any improvement achieved.

I will be also attend about your conclusions with the layout design.

Best regards,