Skip to main content
path321
path321
Associate II
Apr 20, 2022 10:29 AM UTC
Solved

Port X-CUBE-BLE2 code to BLUENRG2-M2SA

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.
Laurent LOUAZON
Laurent LOUAZONBest answer
ST Employee
Apr 21, 2022 3:47 PM UTC

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

View in thread

2 replies

Laurent LOUAZON
Laurent LOUAZONBest answer
ST Employee
Apr 21, 2022 3:47 PM UTC

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
Apr 26, 2022 8:27 AM UTC

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