Bluenrg-MS returns 0x00 in SPI header after sending command

Dhaval Malav · ‎2018-01-31

Posted on January 31, 2018 at 22:05

I have STM32L4 connected to Bluenrg-MS. I am sending data over to the Bluenrg-MS which sends data to peer device. However, after some successful transfers (not consistent: sometimes after 50 notifies and sometimes after 3000 notifies) Bluenrg-MS starts returning 0x00 as its header after STM32L4 sends any command.

in STM32L4 we are also implementing CS line de-assertion and assertion after each transaction and hence we believe that should wake up the Bluenrg-MS.

Not sure what is going wrong. Any help or direction will be much appreciated.

#bluenrg-ms #spi #stm32l4+

Antonio Vilei · ‎2018-02-01

Posted on February 01, 2018 at 17:05

Dear Dhaval Malav,

what firmware version of the BlueNRG-MS chip are you using? Please make sure you are using v7.2c (the latest by the time of this writing).

Are you using the SPBTLE-RF module or is it a custom board?

Also, what software are you running on your STM32L4? As a reference you can use the

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

package.

Best regards,

Antonio

Dhaval Malav · ‎2018-02-01

Posted on February 01, 2018 at 17:33

Thank you Antonio for your response.

Firmware of BlueNRG-MS - using getBlueNRGVersion I a getting fwVersion to be 0x710 which I believe prior to 7.1a

Custom Board - We are using custom board.

Software on STM32L4 - We developed our own FW however, most of the BLE code is based on X-Cube-BLE and other example codes.

How can I update FW to v7.2c?

Having said so, now knowing the fw version, does the behavior I am seeing makes any sense to you? Where BlueNRG-MS goes to sleep (I suppose from SPI Header) and never come backs.

Thank you,

DM

Winfred LU · ‎2018-02-01

Posted on February 02, 2018 at 07:55

Hi DM,

FW v7.2c is available :

http://www.st.com/content/st_com/en/products/embedded-software/wireless-connectivity-software/stsw-bnrg-v72c.html

Firmware update process can be started in 2 ways:

1. (SW) through an ACI command: aci_updater_start

2. (HW) pull the IRQ pin high during power-up or reset

Please reference

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

for detail.

Best Regards,

Winfred

Antonio Vilei · ‎2018-02-02

Posted on February 02, 2018 at 10:17

Hi Dhaval Malav,

since you are using a custom board with your own crystal and oscillator, did you follow allthe steps related to the IFR configuration as described in the related section of the

http://www.st.com/content/ccc/resource/technical/document/application_note/46/0a/77/7b/04/f5/4c/b7/DM001167pdf/files/DM001167pdf/jcr:content/translations/en.DM001167pdf

Application Note, 'Bringing up the BlueNRG and BlueNRG-MS devices'?

IFR stands for Information Register and it allows you to fine tune parameters to adjust for different crystals and oscillators.

I suggest to get an X-NUCLEO-IDB05A1 boardas a reference to test your code. This board is based on a ready-to-use module, the

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

, which has been fully tested and pre-certified for FCC and IC compliance.

If you don't have very high volumes orform-factor issues, you may consider using this module on your board as a viable alternative.

You can also refer to these other threads, where you may find some useful information to debug your currentissues:

https://community.st.com/thread/34391-reset-bluenrg-ms-by-connecting-multiple-devices-simultaneously

https://community.st.com/message/146656-re-bluenrg-ms-fw-72c-hangup

Best regards,

Antonio

Dhaval Malav · ‎2018-02-02

Posted on February 02, 2018 at 21:51

Thank you Antonio for the response.

We did follow proper IFR configuration and are generating IFR with following values:

1. 32MHz

2. 32.768KHz

3. SMPS 4.7uH

4. Stack 2

5. LS Crystal period 1638400

6. ls Crystal Freq 2684354

7. hs startup time 327

We are not using off-the-shelves module because of form factor requirements.

BTW, do you see any reason why on our board BlueNRG-MS chip stops responding after some time. In other words for few seconds, notification works however then host controller gets 0x00 as SPI header from BlueNRG-MS.

Dhaval Malav · ‎2018-02-02

Posted on February 02, 2018 at 21:53

Thank you Winfred, we have custom board and will work on getting BlueNRG-MS programmed to new fw as you suggested.

However, referring to my comments to Antonio, given our current setup do you see any reason why BlueNRG-MS stops after few seconds of successful transfers.

Winfred LU · ‎2018-02-05

Posted on February 06, 2018 at 04:46

Hi DM,

Regarding the failure '

Bluenrg-MS starts returning 0x00', it seemed BlueNRG-MS being in some state (locked or sleeping) not responding to SPI.

It will be easier if replicating the failure with

X-NUCLEO-IDB05A1 with some STM32 Nucleo board

as Antonio suggested. And debug step by step.

If this is a SW (or BlueNRG-MS FW) issue, it will be replicated easily. Then you can check maybe there is something wrong with the command sequence, MCU configurations, IFR settings, FW upgrade, etc.

If it is not replicated, maybe HW is to be blamed. Then you will need to check schematics, layout, etc.

Best Regards,

Winfred