Why SPI in BlueNRG hungs suddenly after hours of correct work?

Piotr Romaniuk · ‎2018-05-11

Posted on May 11, 2018 at 12:33

Hi,

In my device I use BlueNRG-2 working as Network Processor (DTM firmware is loaded there).

It cooperates with STM32 where is my application. Processors communicates each other via SPI interface.

It works fine for long time but suddenly BlueNRG-2 stops responding.

STM32 change BLE_CS pin to active state (low) but BlueNRG never rise BLE_IRQ.

It may happen after half hour or couple of hours.

The application works periodic in two phases:

a) dicovery phase,

b) connection phase.

In discovery phase the device scans available external LE devices.

Then it connects to one of them and reads some characteristics value.

After that it disconnects and returns to scanning phase, and starts from the beggining.

It looks like a bug in BlueNRG firmware (provided by ST Microelectronics in Dev Kit).

What can be a reason of such problem?

How to debug it and get rid of it?

King regards,

Piotr

#bluenrg-2 #spi #hung

Piotr Romaniuk · ‎2018-05-12

Posted on May 12, 2018 at 12:23

An update:

It seems that BlueNRG is not woken up when CS goes low (please compare recordings from logic analyser below).

May I ask someone from ST to have closer look at this case?

Is there any issue with waking up (an errata case)?

Looks very serious.

Kind regards,

Piotr Romaniuk

Piotr Romaniuk · ‎2018-05-12

Posted on May 12, 2018 at 21:41

I have strong confirmation that BlueNRG-2 sometimes is not waking up from deep sleep state,

although the waking gpio pin goes low!

Below I describe verification method.

I put markers in a few places in the code (just sending one serial character):

On BlueNRG_Sleep() entry - e
after BlueNRG_IdleSleep - +
On BlueNRG_InternalSleep() entry - X
On BlueNRG_InternalSleep() exit - F

So following sequences corresponds to execution of WFI:

e+ = idle sleep,
eXF = deep sleep.

On diagram deep sleep state can be also identified by low level on serial line (during deep sleep line is pulled down).

The source code is taken from ST Development Kit for BlueNRG, so I treat it as reference.

But anyway, the verified part is very simple: setting waking up pin and execution WFI.

Why waking up is not working sometimes?

Regards,

Piotr Romaniuk

PS

Below is comparison of two analogous communication and sleep down.

Legend:

1-2 idle sleep

3 preparation to deep sleep

4 deep sleep

10 gpio waking pin goes low

5 marker for exit from deep sleep (end of function)

Piotr Romaniuk · ‎2018-05-13

Posted on May 13, 2018 at 20:11

I examined all measurements that I recorded.

I have interesting observation:

BlueNRG-2 does not wake up if waking low level appears 30us after going into deep sleep state.

When this time is different (larger or smaller) there is no problem with waking up.

Did I hit into some hardware hazard condition inside the chip?

Regards,

Piotr Romaniuk

Piotr Romaniuk · ‎2018-05-14

Posted on May 14, 2018 at 21:22

I measured statisticaly for different delays between entry into deep sleep and wakeup signal.

Problem appears only for 30us delay.

Antonio Vilei · ‎2018-05-23

Posted on May 23, 2018 at 16:02

Dear Romaniuk Piotr,

what version of the BlueNRG-1/2 DK are you using? The latest versions of the software (V2.5.0+) have fixed an issue with sleep management that would cause symptoms like the ones that you have reported.

Best regards,

Antonio

Piotr Romaniuk · ‎2018-05-23

Posted on May 23, 2018 at 16:07

The newest one:

BlueNRG-1_2 DK 2.6.0

Kind regards,

Piotr Romaniuk

Michael Krechko · ‎2018-05-29

Posted on May 30, 2018 at 06:55

May be there is the same workaround as in BlueNRG-MS. See ERRATA for it:

http://www.st.com/content/ccc/resource/technical/document/errata_sheet/42/a1/65/c4/26/c1/49/2a/DM00133230.pdf/files/DM00133230.pdf/jcr:content/translations/en.DM00133230.pdf

I use UART for connection with IC and I haven't had problems with it by now.

Piotr Romaniuk · ‎2018-05-30

Posted on May 30, 2018 at 08:03

Thank you Michael for that information.

Although the errata is for BlueNRG-MS but it is possible that it shares some hardware blocks with BlueNRG-2.

I also reported this issue directly to ST. I am waiting for some actions and confirmation.

Unfortunatelly almost two weeks passed, and there is no advice nor solution.

I only received questions if I am using newest version of DK and properly configured waking up.

Kind regards,

Piotr Romaniuk

PS

Just for the record, there is no errata for BlueNRG-2.

Michael Krechko · ‎2018-05-30

Posted on May 30, 2018 at 08:19

I had the same experience with ST online support, to be honest, request to it usually has only psychological effect)

You can try to scan SPI communication between BlueNRG GUI SW and your IC. May be it helps to find the reason of the problem.