BlueNRG-MS hangs

blil jahov · ‎2018-07-05

Posted on July 05, 2018 at 21:12

Hi,

I'm using BlueNRG-MS to transfer data to host PC running windows 10.

The connection interval is 15ms, slave latency 5, connection timeout of 300 ms. BlueNRG-MS sends 1 notification of 20 bytes each connection (verified using BLE sniffer). Everything seems to work fine.

However, after few seconds of steady link, connection suddenly drops.

Running in debug I see that the connection status is '1' and that no disconnection event was received, even tough device is not connected in windows BLE settings.

I'm running on 32 MHz and 32 kHz clocks if it matters, HS startup time is calibrated, IFR is configured properly.

Any ideas how to solve this?

Antonio Vilei · ‎2018-07-06

Posted on July 06, 2018 at 10:57

Dear Blil Jahov,

as you mentioned IFR configuration, I guess you're using your own hardware design.

I don't know if you have very high production volumes of if you have any form-factor constraints, but did you take into account the possibility to use our

https://www.st.com/content/st_com/en/products/wireless-connectivity/bluetooth-bluetooth-low-energy/spbtle-rf.html

based on the same BlueNRG-MS chip?

In this way, you wouldn't need to take care on your own of all the validation and certification issues.

You can evaluate the module by using the

https://www.st.com/content/st_com/en/products/ecosystems/stm32-open-development-environment/stm32-nucleo-expansion-boards/stm32-ode-connect-hw/x-nucleo-idb05a1.html

expansion board for STM32 Nucleo along with the

https://www.st.com/content/st_com/en/products/embedded-software/mcus-embedded-software/stm32-embedded-software/stm32cube-expansion-packages/x-cube-ble1.html

software.

Best regards,

Antonio

blil jahov · ‎2018-07-06

Posted on July 06, 2018 at 12:27

Hi Antonio,

Yes, I'm using custom board.

No, using ST module is not possible. This is for a big company project and FCC certification fee is not an issue.

I'm very interested in solving this. I will try to reproduce this issue on your hardware as well.

Any idea what could be the root cause?

Antonio Vilei · ‎2018-07-06

Posted on July 06, 2018 at 12:55

If you can try the same usage scenario with the hardware that I recommended in my previous post, it would be very useful indeed.

Since you mentioned IFR and HS startup time, I guess you already followed all the steps described in the

http://www.st.com/resource/en/application_note/dm00116738.pdf

Application Note, &39Bringing up the BlueNRG and BlueNRG-MS devices&39.

Out of curiosity, what TX power level are you using? In the past, someone reported issues with some crystals when using higher power levels. Maybe you can try using a lower TX power output and see if this improves anyhow the situation.

Moreover, based on the expected production volume, you may also want to get in touch with the ST sales office in your area and get support from one of our Field Application Engineers in Israel.

I&39m adding

Gallucci.Gerardo

and

Lu.Winfred

to this discussion, in case they have any other suggestions.

Best regards,

Antonio

blil jahov · ‎2018-07-07

Posted on July 07, 2018 at 09:44

Hi,

I have already followed the steps described in 'Bringing up the BlueNRG and BlueNRG-MS devices'.

I also tried various Tx power levels. I can see that same behavior in all of them.

Is this behavior new to you? did you never encountered in such behavior?

Antonio Vilei · ‎2018-07-09

Posted on July 09, 2018 at 11:00

Hi Blil,

a while ago I experienced something similar with the old BlueNRG chip (which is not recommended for new designs and has been replaced by the BlueNRG-MS chip).

In that case, however, reducing the TX power level would make it work reliably. On that occasion, another workaround was selecting a different IFR configuration that was using the ring oscillator inside the chip, instead of an external crystal.

Perhaps this may work in your case, too. If you want to give it a try, you can find the IFR configurations for the ring oscillator inside the 'Firmware\BlueNRG-MS_stack' folder of the

https://www.st.com/content/st_com/en/products/embedded-software/evaluation-tool-software/stsw-bluenrg-dk.html

installation directory. At the time of this writing, the latest version of the DK is 2.0.2. As you're using 32 MHz, the configuration that you can try is ifr_3v1_003_mode02-32MHz-RO32K_4M.dat. Alternatively, for 16 MHz you could use ifr_3v1_003_mode02-16MHz-RO32K_4M.dat.

Please let me know if this works for you.

Best regards,

Antonio

blil jahov · ‎2018-07-09

Posted on July 09, 2018 at 15:56

Hi,

I tried using the internal ring oscillator and used the exact same settings as in ifr_3v1_003_mode02-32MHz-RO32K_4M.dat .

I also tried using the lowest TX power level.

I still reproduce this strange behavior - BlueNRG-MS is not connected to the central, but when debugging the connection indication is still on.

Antonio Vilei · ‎2018-07-10

Posted on July 10, 2018 at 14:54

Hi Blil,

do you have a BLE sniffer to check what's being transferred over the air? That would be useful to understand what's going on.

Also, it would also be interesting to see what happens if you use another BlueNRG-MS as Central, so that you can inspect the log on the Central, too. For that, I would suggest to use an ST design like the X-NUCLEO-IDB05A1 board that I mentioned earlier.

By the way, did you have a chance to see if the same behavior can be reproduced with the

X-NUCLEO-IDB05A1?

https://www.st.com/content/st_com/en/support/support-home.html

Best regards,

Antonio