SPI packet loss with short BLE connection intervalls.

[ProfNocturne]

I have an BLE peripheral application running on a nrf52833 with softdevice S140 were I transmit data from Bluetooth to an external CAN-controller via SPIM and back. This is how the transfer looks like:

 

1. A BLE central is sending max. 232 Bytes to the peripheral which is stored in internal RAM.
2. After receive the peripheral is sending the data to the external CAN-controller via SPIM.
3. After a certain time the CAN-controller receives the response of max 232byte. It sets a port pin to trigger an event where the SPIM transfers the data to the internal RAM.
4. After that the BLE peripheral sends the response to the central.

 

As you can see both transfers BLE and SPI are separate and cannot interrupt each other.

During a transfer the SPIM is triggered every 125us (CAN=1MBaud) to transfer one CAN telegram.

The transmission via SPIM is handled on the highest possible IRQ-Level (2). So there should be a minimum of interference with the BLE softdevice.

In our application we want very short BLE connection intervals to transfer the data as fast as possible.

 

Now the problem that I have:

When the connection interval is set to a time below 30ms there is a packet loss on the SPIM.

Like I wrote before the BLE and SPIM transfer are separate so the softdevice has not much to do during the SPIM transfer and the high level IRQs of the softdevice should be so short that this should not be a problem?

The external CAN-controller has a RX message buffer which I can use. So the SPIM must only be triggered for example every 5ms. But this doesn't help.

 

Despite this, is the softdevices blocking the IRQ for the SPIM transfer too long? (Only empty PDUs are transmitted.)

 

May be the problem be solved if I use a nrf5340 with 2 cores?

[Sigurd]

Hi,

Some follow-up questions:

1) What SPI instance are you using? SPIM3?

2) What is the SPI frequency you are using?

[ProfNocturne]

It is SPIM0 with 8Mbps.

[Sigurd]

Hi,

there is a packet loss on the SPIM.

Could you explain this some more? Does the SPI transfer not happen at all? or is part of the SPI transfer missing(e.g. last x bytes of the transfer)? How are you detecting/measuring this?

During a transfer the SPIM is triggered every 125us (CAN=1MBaud) to transfer one CAN telegram.

one CAN telegram is 232 Bytes? How much data are you sending over SPI?

[ProfNocturne]

I can check the packet loss by reading a status register of the CAN-controller. It gives me the information if the internal fifo is empty, not empty, half full, full and if there is an overflow. I can also see it because the CAN telegrams are numerated. So in case of a packet loss = overflow there is a number missing. The fifo has a configurable size which I set to 28 CAN-RX-telegrams. So there is no need to get a CAN-telegramm every 125us via SPIM.

The 232 bytes of data are splitted into about 34 CAN-telegrams. Each telegram is 8 bytes long including 1 byte header = counter.
The telegram with CAN-ID and data and some other info is about 14 bytes long. But the recepetion of one CAN-telegram consists of 3 SPI-transfers. After getting the CAN-RX-Interrupt via the port pin the first step is reading out the before mentioned status register. The transfered data is 3 bytes. After that the CAN-telegram is transfered (14 bytes). The last transmission consists of sending 1 byte to inform the fifo that the reception of the CAN-telegram is done.

The duration of transmitting the 3 SPI-transfers in the port pin interrupt is about 95us. So there are about 30us for the rest of the system. But it seems this not enough.

If I run the same transfer without BLE activated I have no problems. So the problem might be related that the SoftDevice needs mostly the rest CPU time? (https://infocenter.nordicsemi.com/topic/sds_s140/SDS/s1xx/ble_processor_avail_interrupt_latency/ble_central_connection_performance.html)

Again the question: Could be the problem be solved if I use a nrf5340 with 2 cores? There should be less impact of the BLE (SoftDevice) to the "application" core?!

[Sigurd]

Hi,

ProfNocturne said:

Again the question: Could be the problem be solved if I use a nrf5340 with 2 cores? There should be less impact of the BLE (SoftDevice) to the "application" core?!

Possibly, but before more about the cause of the issue is understood, I still think it can be solved on the nRF52840.

ProfNocturne said:

The duration of transmitting the 3 SPI-transfers in the port pin interrup

It sets a port pin to trigger an event where the SPIM transfers the data to the internal RAM.

1) You have configured a input pin on the nRF52, and it uses the GPIO PORT event? 

2) When this input pin is triggered(CAN-controller set it high/low), this triggers the SPIM transfer from the nRF52 to the CAN-chip ?

If yes, then I suggested using GPIO IN_EVENT instead. See this link: https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsdk_nrf5_v17.1.0%2Fhardware_driver_gpiote.html&cp=8_1_2_0_3_4&anchor=gpiote_in

 

[ProfNocturne]

First sorry for the delay of my responses. I'm working on another projects.

1) No I'm already using the GPIO IN_EVENT.

2) Yes.

I changed my code so it is running in the main-loop and not on IRQ-Level. My code is now polling the input pin which is connected to the CAN-controller. Here I have the same problem.

I measured the time which the BLE stack blocks the main-loop during the data transfer of the CAN-telegrams. It shows that it is sometimes between 4 and 5ms. For my application this is too long since the fifo of the CAN-controller is not big enough. As I mentioned before it is max. 28 CAN messages deep. I receive every 125us one message. So theoretically my code must run at least every 3,5ms.

When I turn down the BLE connection intervall it seems that the blocking of the main-loop is happening more often. So the chance that there is a fifo overflow is increased.

It seems I have to try the nrf5340. Or do you have any other idea?