Skip to main content
path321
path321
Associate II
April 20, 2022
Solved

Port X-CUBE-BLE2 code to BLUENRG2-M2SA

  • April 20, 2022
  • 2 replies
  • 1324 views

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

This topic has been closed for replies.
Best answer by Laurent LOUAZON

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

2 replies

Laurent LOUAZON
Laurent LOUAZONBest answer
ST Employee
April 21, 2022

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
path321Author
Associate II
April 26, 2022

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.

Terms & ConditionsAccessibility statement