BlueNRG-2 maximum SPI clock

[BPaik]

I am currently using a X-NUCLEO-BNRG2A1 to experiment with the BlueNRG-2. I initially set the SPI rate to 1.25 Mbit/s, but later noticed in the BlueNRG-2 documentation that the maximum SPI rate is 1Mbit/s. My question is how strict is this SPI rate limit, and what is the reason for it (hardware limitations, software limitations)? So far, I've run a number of the examples with no noticeable issues at 1.25 Mbit/s. The MCU I am using has a maximum system clock of 80 MHz. Using the SPI prescalers, the highest SPI frequency I can achieve within the 1 Mbit/s limit is 625 KBits/s. I am hesitant to do this because I don't want to potentially limit the bandwidth of the BLE interface. It seems the only way to achieve the 1 Mbit/s rate is to reduce the system clock for the MCU itself (which would affect the entire application). Ideally, if the BlueNRG-2 could run fine at the slightly higher rate of 1.25 MBit/s (as it currently seems to be doing), it would be the best option.

[Winfred LU · Accepted solution]

This is a hardware limitation.

It is because the SPI signals need to be oversampled by the slave in order to be correctly understood.

[BPaik]

WIth an 80MHz system clock, it seems like the fastest I can run the SPI clock and be within the 1Mbit/s limit is 625Kbit/s. What is the slowest the SPI clock can run without reducing the overall data rate of the BLE application? Or does maximum BLE application throughput drop as soon as you go below 1 Mbit/s SPI clock?

[Winfred LU]

Whatever SPI clock is used, BLE will still communicate at the standard PHY rate (1Mbps).

Regarding to the slowest SPI clock without compromising on BLE throughput, i don't have the immediate answer. We might need to calculate based on the overhead of the network coprocessor (SPI header overhead, ACI/HCI header overhead) versus Bluetooth transmission overhead.

In case the overall (BLE) throughput is concerned, the better approach is to use BlueNRG-2 as an SoC instead, then the SPI clock will not be a limitation.