2021-03-08 06:57 PM
Hi,
I picked up a X-NUCLEO-BNRG2A1 (Extension board Lot:2040 for the Nucleo-64 boards), and I am trying to communicate with it through a Nucleo-F411RE Board. I basically generated a project template through CubeMX for the STM32F411RE and included the BlueNRG-2 (X-CUBE-BLE2) Pack to include Bluetooth HCL/ACI APIs along with the project template.
I also assigned in CubeMX (in the Software Packs section) that I will be using SPI1 bus, GPIOB Pin 14 for the SPI EXTI Pin, GPIOA Pin 1 for the SPI1 CS pin, and GPIOA Pin 8 for the HCI_TL_RST Reset Pin.
I also configured the SPI1 bus to be Full Duplex Master, Prescaler = 128 (to obtain 781.25KBit/s baud rate), CPOL Low, and CPHA = 2 Edge (based on the configurations found in an example project under X-CUBE-BLE2\3.2.0\Projects\NUCLEO-L476RG\Applications\SampleApp).
In case this information is needed, these solder bridges are connected:
I am using Page 31 of this Programming Guideline as a reference, and that SampleApp project as a reference to Initialize the device, and to Setup the Device Address. I basically call the two functions hci_init(APP_UserEvtRx, NULL); and Setup_DeviceAddress(); (the first function can be found under hci_tl.c, and the second function can be found under app_bluenrg_2.c. I ported the functions Setup_DeviceAddress() and APP_UserEvtRx() to successfully execute these functions).
My project never seems to successfully execute Startup_DeviceAddress() as it seems to not be able to communicate with the BlueNRG-2 module through SPI during these two instances:
/* get a random number from BlueNRG */
ret = hci_le_rand(random_number);
ret = aci_hal_write_config_data(CONFIG_DATA_PUBADDR_OFFSET, CONFIG_DATA_PUBADDR_LEN, bdaddr);
I scoped the SPI1 bus that should have exchanged data with the BlueNRG-2 and observed that only the CS lines were pulled low and then high immediately, without the STM32F411RE Nucleo toggling the SPI_SCK or SPI_MOSI (no data was sent through the SPI1 bus and the STM32F411RE immediately disabled the SPI1 communication).
Through breakpoints, I find that at HCI_TL_SPI_Send() function (found under hci_tl_interface.c), the code always fail at this block:
while(!IsDataAvailable())
{
if((HAL_GetTick() - tickstart_data_available) > TIMEOUT_DURATION)
{
result = -3;
break;
}
}
if(result == -3)
{
/* The break causes the exiting from the "while", so the CS line must be released */
HAL_GPIO_WritePin(HCI_TL_SPI_CS_PORT, HCI_TL_SPI_CS_PIN, GPIO_PIN_SET);
break;
}
I concluded this because 'result' returns -3 at the end of this function, and the lines after this block of code does not get executed. This would mean that the SPI_IRQ interrupt never fired from the BlueNRG-2 Module based on the comments of the code generated by CubeMX (I tried using both PA0 and PB14 for the code and they both yield the same results).
Why is it that my BlueNRG-2 (X-NUCLEO-BNRG2A1) fails to produce an interrupt at that point? I don't think there's anything wrong with HAL_GetTick() too as I did not change the code. There was a part of the code I commented out in hci_init() that resets the BlueNRG-2 (toggles the PA8 line) too, as I noticed that after the PA8 line goes high, the whole device seems to stop working. I previously would connect the PA8 line to the RESET pin in the J12 bridge of the X-NUCLEO-BNRG2A1. I assumed that ignoring that operation would be fine for the board.
I also saw that you can flash firmware onto the X-NUCLEO-BNRG2A1 based on the Erratum Sheet here. Is this a process that needs to be done before playing with the X-NUCLEO-BNRG2A1? What is the purpose of using the STSW-BNRGFLASHER to update the firmware on the board?
Any help would be greatly appreciated. Thank you!
UPDATE:
I just got a ST-Link/V2 connector and I am trying to flash DTM_SPI.hex firmware found under BlueNRG GUI 4.0.0/Firmware/BlueNRG2/DTM. When trying to flash the firmware, the ST-Link/V2 failed to connect to the device (although the SWD interfaces is listed as connected in the BlueNRG-X Flasher Utility.
I tried disconnecting the jumper J10 and use a multimeter across the J10 pins and measured almost 0.4V. Does this mean that the X-NUCLEO-BNRG2A1 isn't getting the voltage it needs to power on? However, I also tried connecting an LED across between the 5V/3V3 pins and the GND pins in CN6 and the LED seems to light up. I also used the multimeter to scope the 5V and 3V3 pins and can verify that both pins are at 5V and 3.3V respectively.
2021-03-10 09:26 AM
Hello,
concerning the pinout configuration, if you want to use the PB14 as SPI_IRQ, you should also bridge the PIN 28 of the CN10 on the Nucleo board with the PIN 28 of the CN10 on the X-NUCLEO-BNRG2A1. Otherwise, you can use PA0 and you don't need any bridge.
In any case (either using PA0 or PB14 with the bridge), please, do not forget to enable the corresponding interrupt line from the NVIC view in STM32CubeMX.
The following picture shows the complete pinout configuration (please, note that the USART2 is used).
Anyway, you can find all the information on how to setup a project for your X-NUCLEO-BNRG2A1 in the Getting Started Guide included in the X-CUBE-BLE2 package.
Also, for your project I'd suggest to use the latest STM32CubeMX v6.2.0 (available on st.com) and the latest X-CUBE-BLE2 V3.2.0.
Regards,
Silvio
2021-03-10 11:48 AM
Hi Silvio,
Thanks for the response! Regarding your CubeMX pinout configuration, when including the X-CUBE-BLE2 package, CubeMX did not ask me to link any USART pins or RCC_OSC32_IN, RCC_OSC32_OUT, RCC_OSC_IN, RCC_OSC_OUT, and the JTAG pins. Are those pins required for the X-NUCLEO-BNRG2A1 board to work properly?
As for the SPI_IRQ pin, I changed mines to PA0 now since I realized yesterday that the Nucleo-F411RE's PB14 is not connected to the X-NUCLEO-BNRG2A1's PB14 pin. In the Getting Started Guide on page 7, it is mentioned that R85 must be unmounted to use PB14 (while R82 is mounted). Would it be a problem that both R82 and R85 are mounted on the X-NUCLEO-BNRG2A1?
Do you also know why I could not flash the DTM_SPI.hex firmware onto the X-NUCLEO-BNRG2A1 via SWD? I connected all the pins based on ES0526 Board Limitations Sheet, and followed presentation page 16 of the Quick Start Guide presentation, but the Flash Tool kept saying that it failed to connect to the device.
I will also update my CubeMX and X-CUBE-BLE2 software too (I had the older CubeMX and could not use the X-CUBE-BLE2 V3.2.0 that was previously installed).
Thank you! I look forward to hearing back from you.
2021-03-10 06:06 PM
Hi Silvio,
So the STM32F411RE Nucleo board seems to successfully communicate with the X-NUCLEO-BNRG2A1 now through SPI. I added the HCI_TL_SPI_Reset() function, along with a 2 second delay before initiating communication with the Bluetooth module based on one of the example projects found under STM32CubeMX.
This was done without flashing a firmware onto the X-NUCLEO-BNRG2A1 (I still have issues connecting with the X-NUCLEO-BNRG2A1 through SWD with the BlueNRG-X Flasher Utility. The message produced is still the same: FAILED. (It's not possible to connect to the device)).
Thank you!
2021-03-11 12:39 AM
Hello,
good to know you solved the issue.
Concerning the USART and RCC pins, they are enabled by default by the STM32CubeMX when you start a project for a Nucleo board.
They are not required for the X-NUCLEO-BNRG2A1 board to work. You can for sure disable them if you don't need them.
The USART can be anyway useful if, in your application, you want to print out on a serial terminal some log messages.
Concerning the R82 and R85, you will face no issue with that configuration.
Concerning the issue with the BlueNRG-X Flasher Utility, if you followed the instructions in the documents you mentioned you should be able to flash the device on the X-NUCLEO-BNRG2A1. I can only suggest you to check the connections and retry. Anyway it is not mandatory to update the BlueNRG firmware.
BR
Silvio
2021-03-11 02:51 PM
Hi Silvio, thank you for the answers! I have one more question regarding the BlueNRG-M2S. If I were to buy a BlueNRG-M2S from Digikey, would it come with the latest firmware already flashed onto it? If that were the case, communicating with the BlueNRG-M2S through SPI should work immediately, and invoking HCI commands/APIs would also work immediately?
2021-03-12 02:13 AM
Hello,
after buying the BlueNRG-M2S, you need to flash it with the FW for using the BlueNRG-M2 module as network processor (the module gets controlled by an external host connected via SPI or UART). You can find the latest FW version in the section Utilities of BlueNRG-M2 web page on st.com.
BR
Silvio
2021-03-12 01:47 PM
So, for example, if I were to purchase the BlueNRG-M2SP module, I would need to connect the BlueNRG-M2SP's SWD pins to a ST-LINK V2 module, and then flash it with the BlueNRG-X Flasher Utility?
In this case, the pins needed would be SWCLK (Module Pin 12) which is DIO9, and SWDIO (Module Pin 13) which is DIO10 based on page 13 of this datasheet? And I would probably need to connect RESET, VDD, and GND to the ST-LINK V2 module too? Are there any other prerequisites for flashing the firmware properly onto the BlueNRG-M2SP? Or is there a BLE module that ST provides that already comes with flashed firmware upon purchase?
Thank you!
2021-03-16 09:30 AM
Hello,
the connection schema is correct, the pins to be used are SWCLK, SWDIO, RST, GND and VDD.
No other prerequisites are needed for the flashing.
Among the BLE modules, you could take into account the BlueNRG-2N network coprocessor which comes pre-programmed with a production-ready stack image.
Also, this module relies on the same HCI stack of X-CUBE-BLE2 that you are using for the BlueNRG-M2.
Regards,
Silvio
2022-12-21 11:45 PM
hi , @RrW did you resolved the issue? if yes can you please help me out with the same bnrg2a1 errors?