BlueNRG-x documentation discrepancy/lack of information.

[MatteoFeatureJam]

Hi everyone!

I have a custom PCB with a STM32L4 connected via SPI to a SPBTLE-1S. As indicated in the datasheet the SPBTLE-1S is built around the BlueNRG-1 SoC.

Until now I understood that I have to configure the SPBTLE-1S as a network co-processor in order to allow it's usage on a custom PCB.

In the DT0121 Design tip (How to configure the BlueNRG-1 and BlueNRG-2 devices in network coprocessor mode) document is written:

"The purpose of this design tip is to provide customers with guidelines on how to modify the reference DTM application for running on a custom printed circuit board (PCB).",

an than,

"In order to configure the BlueNRG-2 device as a network coprocessor, the device shall be programmed with a specific application, named DTM (Direct Test Mode). In the device SDK the source code for this application can be found in the path “\Project\BLE_Examples\DTM�?."

In the description of the SPI interface the following table can be found:

In the SPBTLE-1S datasheet the pins seem to be configured differently as shown in the following screenshot:On this basis the SPI connections between The STM32L4 (master) and the SPBTLE-1S(slave) are the following:

CLK -> DIO0

MISO -> DIO3

MOSI -> DIO2

CS -> DIO1

The current situation is this: I flashed the DTM_SPI.hex for BlueNRG-1 SoC on the SPBTLE-1S module and I tried to generate some code with cubeM and X-CUBE-BLE-1 pack to try some basic communication via SPI between the MCU an the BLE module. All What I get is a always high signal or always low signal on the MISO. Everything was checked with a logic analyzer.

My questions are:

1. Is there any mistake in the connections between the STM32L4 and the SPBTLE-1S on the PCB?
2. The binary file of the DTM firmware, DTM_SPI.hex, for the BlueNRG-1 SoC considers the different configuration of the pins in comparison with the configuration showed for the BlueNRG-2 Soc in the Design tip?
3. Do I have to modify the DTM firmware to make it work?

Thanks in advance for your help!

[MatteoFeatureJam]

@Winfred LU​ excuse me to bother you, but looking at your posts it looks that you may know something about this. Can you help? Thanks in advance!

[Winfred LU]

Besides those 4 SPI pins, GPIO pin 7 is also used, as an interrupt signal for the module to notify MCU.

Please note that SPBTLE-1S has 32MHz HS crystal, which is different from the one used in STEVAL-IDB007V1 (BlueNRG-1 EVB).

The prebuild firmware may not work for you.

Try to build the DTM firmware from STEVAL-IDB007V1M folder, for example,

<DK>\Project\BLE_Examples\DTM\EWARM\STEVAL-IDB007V1M

[gada]

I've been facing similar issue for some time.

We have a board made on similar lines of STEVAL-MKSBOX1V1. We used demo code for sensortile pro mode and modified it as per our needs.

On our custom board we flashed the controller STM32L4R9 Code and Since no hex for SPBTLE-1S is available I am trying to configure SPI pins DTM_SPI project from BlueNRG SDK V 3.2.1 But It doesnt work.

Specifically I had noticed in SensorTile MKSBOX Pro Mode Code BLESensors where in hci_tl_interface.c SPI Write HCI_TL_SPI_Send Function file that after resetting chip select pin, it waits for SPI IRQ pin from the SPBTLE-1S to go high (It remains high forever not responding to CS Pin).

Currently issue I am facing is that this pin remains high all the time, even on the development board (STEVAL-IDB007V1M) and on custom board.

(I believe and I did see in my experimentation 2 days back that if we toggle cs pin every 4-5 seconds the IRQ pin also toggles high low) Unfortunately, this is not happening.

I am stuck at the module firmware and feel I am very close but it isn't working.

Any pointers. Best would be if the SensorTile Board SPBTLE-1S Firware File is released by ST as on that board things are working fine.

Regards

[Winfred LU]

> On our custom board we flashed the controller STM32L4R9 Code and Since no hex for SPBTLE-1S is available I am trying to configure SPI pins DTM_SPI project from BlueNRG SDK V 3.2.1 But It doesnt work.

Please try to build from IDB007V1M folder: <DK 3.2.1>\Project\BLE_Examples\DTM\EWARM\STEVAL-IDB007V1M

which shall work with default settings. A prebuild firmware is also available.

> Currently issue I am facing is that this pin remains high all the time, even on the development board (STEVAL-IDB007V1M) and on custom board.

OK then. This shows that the issue is on main STM32L4R9's firmware.

The SPI IRQ is a signal that BlueNRG-1 (SPBTLE-1S) notifies STM32L4 to start a SPI transaction.

Normally, the IO interrupt service routine should be triggered, and STM32 (acts as the SPI master) should start to read the 5-byte SPI frame header, then it handles following reading accordingly.

After the data is properly read out, BlueNRG-2 will reset the SPI IRQ pin. (The SPI transactions are done) It waits until next event is coming.

> Best would be if the SensorTile Board SPBTLE-1S Firware File is released by ST as on that board things are working fine.

As explained, it looks that it's not an issue of SPBTLE-1S firmware.

[MatteoFeatureJam]

Hey @gada​ , I was able to make it work with the DTM_full.bin firmware that I found here:

https://github.com/stm32duino/wiki/wiki/STM32duinoBLE#stm32duinoble-with-steval_mksbox1v1

Check the tile.box code because the strict HCI trough SPI protocol described in some bluenrg-x related documentations does not work in this case.

hope it works for you too.