BlueNRG-M2 not responding to SPI on custom STM32U5 PCB

[Jaume]

Hi all,

I recently designed and built a custom PCB for data acquisition and transmission through bluetooth using an STM32U575 as the main MCU and a BlueNRG-M2SA module for bluetooth data transmission configured as a Network Coprocessor. They are connected via SPI following the pinout on the BlueNRG-M2 datasheet and also looking at the X-NUCLEO-BNRG2A1 schematics. The BlueNRG-M2SA is connected to an external connector via SWD for flashing using an STLink-V3Minie. Resistor R13 is not usually soldered and is just used to enable the bootloader during image flashing. Schematic for the BlueNRG-M2 on the custom PCB provided below:

The problem is that I have not been able to achieve communication between the STM32U575 and the BlueNRG-2 module as whenever the main MCU waits for the IRQ signal from the BlueNRG-M2, it doesn't receive any and therefore returns BLE_STATUS_TIMEOUT and gets stuck after aci_hal_set_tx_power_level() during Device_init(). I have tried uploading different DTM images to the BlueNRG module, the ones on the BlueNRG-M2 website, both 2.1c & 2.1e and the ones provided with the BlueNRG-1_2 DK 3.2.3: DTM_SPI_M2SA.hex and also the NO_UPDATER version. On the MCU side, I am using the X-Cube-BLE2 middleware pack with HCI_TL set to Basic and HCI_TL_INTERFACE set to UserBoard and I have tried both the Beacon and SensorDemoBLE applications.

None of the previous has worked and I still get the same error always which seems to be that the BlueNRG-M2 is not generating the IRQ signal. I attach the STM32CubeIDE project I'm using to test just the BLE.

I have checked all suply voltages and they are correct for the MCU & the BlueNRG, they are both supplied with 3.3V.

If anyone knows something about this problem or knows any solution I will be grateful as I have been trying to solve this for more than two months. Also ask me for any additional information you might want to know about my build or configuration.

Thanks for the help!

[Andrew Neil]

Welcome to the forum.

Please see How to write your question to maximize your chances to find a solution for best results.

Please show the full schematic - including the STM32.

Before committing to a custom PCB, have you got this working on known-good hardware; eg, the  X-NUCLEO-BNRG2A1 with an STM32U5 Nucleo board?

Have you used an oscilloscope to verify your SPI signal integrity?

Have you used an analyser to verify your SPI comms?

[Jaume]

I attach the full schematic including the STM32 and the BlueNRG-M2. The project has two other schematic pages but are not related to the problem and are not connected to the BlueNRG-M2, they are additional sensors and external connectors.

I did not test with the X-NUCLEO-BNRG2A1 due to time and resource limitations but anyway, as I connected the BlueNRG-M2 module as in the X-NUCLEO-BNRG2A1 board and the only connection with the STM32 was via the standard SPI protocol and an External Interrupt, I didn't expect there to be any problem regarding the physical connections. However, I fully understand that this would have been a wise step to try before building the custom PCB.

I don't currently have access neither to an oscilloscope nor a logic analyzer but I should get access to an osciloscope in the following days with which I plan to look at SPI signal integrity and also the physical IRQ signal. I will update when I have that measured.

[Jaume]

I have finally gotten access to an Oscilloscope and the results are attached. As I imagined, the BlueNRG doesn't seem to produce the IRQ signal. The setup has been the same as I stated on the post, the BlueNRG-M2SA is flashed with the DTM_SPI_M2SA.hex provided in BlueNRG-1_2 DK 3.2.3 and the STM32 is flashed with the project I also provided in the initial post. The attached images show the following:

1. CS_IRQ.JPG: The yellow signal shows the CS signal from power-up while the blue signal is the IRQ or the DIO7 pin from the BlueNRG. The IRQ signal stays at 0V during the whole timespan. The CS signal is set low for 400ms, corresponding to the TIMEOUT_DURATION variable in hci_tl_interface.c. This happens a total of two times and afterwards stays constant at 3.3V. I have interpreted that these correspond to the hci_reset() and aci_hal_set_tx_power_level(1,4) when the STM32 tries to communicate with the BlueNRG-M2. Also the spacing between these two is 3 seconds, corresponding to the 1 second from TIMEOUT_IRQ_HIGH and 2 seconds as a delay between instructions.
2. CS_RST.JPG: Here the yellow signal is CS and the blue one is RST signal. The STM32 correctly resets the BlueNRG-M2 before pulling the CS pin low which corresponds to the reset performed when hci_init() is called.
3. SPI_MOSI_SCK.JPG: As the STM32 does not read an IRQ signal, it never starts sending any data via SPI if I interpreted the code correctly. Therefore, to check that the SPI would work fine, I wrote a separate code that sent a short message through SPI. The image shows the MOSI signal in yellow and the SCK signal in blue. Apparently the signals look good.

So after these tests I think I can conclude that the STM32 is working as expected but the BlueNRG-M2 is not generating the needed IRQ signal indicating that it is ready to communicate. If you need me to measure something else let me know and I will.

[Jaume · Accepted solution]

It seems like the BlueNRG module's crystal was dead.

I programmed it with the GPIO example code available in the DK and debugging it I saw that it stopped when initializing the HS crystal. I am know trying with another module and SPI seems to be alive