cancel
Showing results for 
Search instead for 
Did you mean: 

BlueNRG-2

RAlma.1
Associate III

Hi,

Please help if possible.

I have an automotive electronic board which has a BlueNRG-2 device on it and it runs Yocto Linux on its main processor which is connected to the Ble chip via UART interface. I have loaded the the BlueNRG-2 device with DTM firmware hence I can control the chip using hcitool by sending HCI commands over the uart. I have managed to put the device into connectable advertisement or Beacon modes so I can connect to it from my phone using "nRF Connect" or "BLE Scanner" apps. However, from the moment the connection between the phone and BlueNRG-2 device is made, it takes about 30 seconds and the connection drops and I cant connect to it anymore unless I repeat the whole steps again. why the connection drops? I am doing the same thing with STEVAL-ID00BV2 board and noting goes wrong, the connection stays alive until I disconnect it myself.

thanks for help.

Roosbeh

9 REPLIES 9
Laurent LOUAZON
ST Employee

Hello,

Reading your post, it seems there is HW dependency (as no problem when mapping your main processor with our eval kit instead of BlueNRG-2 on your PCB).

Could you eventually share your schematics (BlueNRG-2 part and mainly Low speed and high speed Xtal used).

Such problem are usually related to time shift so LS or HS oscillators/xtal related.

I would suggest:

  • to ensure your Low Speed oscillator is properly centered (see AN4818)

An other check could be to use internal RO as a test (means building DTM UART image with LS_SOURCE_INTERNAL_RO pre processing option)

If problem disappear it would confirm it could be related to 32kHz oscillator centering.

  • to ensure your High Speed oscillator is properly centered (see AN4818)
  • to check your High Speed oscillator start up time(see AN4818)

An easy test would be to increase this value in your DTM UART code (DTM-config.h)

/* High Speed start up time */

#define HS_STARTUP_TIME 328 // 800 us

Maybe your Xtal is having higher start up time and you can test increasing this value to max meaning below config

/* High Speed start up time */

#define HS_STARTUP_TIME 780 // 1900 us

Regards

Laurent

RAlma.1
Associate III

0693W00000WJJwoQAH.png 

Hi,

Please find a copy of the schematic. The BlueNRG-2 chip is connected to our main processor which runs Linx. we use hcitool commands to control the Bluetooth chip. also I set the

#define HS_STARTUP_TIME 800 // 1953 us

but the problem is still there.

regards,

Laurent LOUAZON
ST Employee

Hello,

Thanks for sharing.

Nothing obvious looking at your schematics.

Could you eventually share Low and high speed Xtal ref?

Have you checked AN4818 and xtal centering?

Did you try not using your 32kHz xtal (setting LS_SOURCE_INTERNAL_RO source)?

Regards

Laurent

Laurent LOUAZON
ST Employee

You may also test not using SMPS (remove 10uF coil) and set Vbat directly to SMPSFILT2.

Again the goal is to understand where the problem can be

RAlma.1
Associate III

0693W00000WJLXCQA5.pngWhen I set the low speed clock to internal as shown in the screenshot, I wont be able to communicate with the device from the main processor though UART. also you can see the Hight speed clock there, but is does not seem to be defied. I have asked our hardware engineer to look into the clock centring

RAlma.1
Associate III

Hi again,

STSW-BLUENRG1-DK package includes the DTM version 3.3.0

is it possible to get the package that includes DTM version 3.1.0 ?

Many thanks,

Laurent LOUAZON
ST Employee

Hello,

Please note when testing intyernal RO instead of external 32kHz you should set LS_SOURCE_INTERNAL_RO directly in pre processing options.

It is not recommended using an old SDK but I can provide it to you by FTP (I will send it to you this morning).

Regards

Laurent

MOhamed_Mehery
Associate III

I face such issue before, the problem was the bluetooth version of mobile phone

Umm.. Shouldn't it be #define HS_STARTUP_TIME 0x328? 

328 is a decimal, it equals 328.

0x328 is hex, it equals 808, close to the 800us in the comment.

This is a pretty major typo for the SDK.