Port X-CUBE-BLE2 code to BLUENRG2-M2SA

[path321]

Hi,

We are developing a project with BLE connectivity, and we are leaning on using BLUENRG-M2SA as a network coprocessor, with a STM32L476 MCU as the host processor.

We have been experimenting with X-NUCLEO-BNRG2A1 ( that has BLUENRG-M2SP on it ), and have ported example code ('Central' and 'VirtualCOM') from STM32CubeIDE ( X-CUBE-BLE2.3 SW package) with success. Also, we have used RF-Flasher utility to flash firmware (BLUENRG-M2SP_DTM_SPI.hex from BlueNRG-M2SA_M2SP_DTM_Stack_v2.1c) directly to M2SP, also with success.

Finally, we tried unsoldering and replacing M2SP with M2SA on BNRG2A1 development board. However, despite being able to flash BLUENRG-M2SA_DTM_SPI.hex correctly, and while being able to recognize and send commands successfully with BLUENRG-GUI, the X-CUBE-BLE2 examples (particularly 'Central') doesn't work. In fact, it fails on initization.

Is there any change in X-CUBE-BLE2 SW that needs to be done, so that projects that run on M2SP also run in M2SA ?

I changed the #define's in bluenrg1_devConfig.c according to the DT0137 paper, but didn't make any difference

[Laurent LOUAZON · Accepted solution]

Hello,

From description, could be related to the fact BlueNRG-M2SA (using 32kHz xtal) is having longer wake up time than BlueNRG-M2SP (using internal Ring oscillator).

Two solutions to fix this issue

• Increase default timeout from X-CUBE-BLE2 from 15 to 100ms to better manage usage of external 32Khz xtal.
  • #define TIMEOUT_DURATION 100U (hci_tl_interface.c)
  • WARNING : when regenerating code using CubeIDE or CubeMX, this timeout value might be overwrite.
• Use a BlueNRG-M2SA DTM SPI image that is based on internal RO instead of external 32Khz.
  • Means you follow DT0137 app note guideline but you built DTM SPI image for M2SA keeping the LS oscillator preprocessing option for M2SP : LS_SOURCE_INTERNAL_RO
  • I would not recommend this as you would not benefits the optimized current consumption of M2SA versus the M2SP (around 1uA penalty)

Regards

Laurent

[path321]

Thank you very much Laurent, changing TIMEOUT_DURATION solved the issue.

It would be helpful if that information (about different timeout needed) was included in ST documentation ( especially DT0137 ) in future revision or if TIMEOUT_DURATION changed during CUBEIDE/CUBEMX code generation depending on the LS_SOURCE value, as others may come across the same pitfall.