• State Verified Answer
  • Replies 2 replies
  • Subscribers 67 subscribers
  • Views 3129 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 104033
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

SPI Slave with heavy interrupt in BTLE

Scarlet

Hello, I'm an developer using nrf51822.

I have the same problem with this. devzone.nordicsemi.com/.../ But this problem has no more discussion...

Here is my problem. We use a 3rd party analog front end (AFE) as SPI master. (SPI speed: 1.2Mbps/650Kbps) This AFE sampling rate is 8192 Hz (8192 interrupt in one second...?) Each sampling point has 2 bytes. We want to send all data through BTLE to mobile. (Connection interval: 7.5ms)

In our experience, if we disable BTLE and only count the number of interrupt in one sec. The counter shows 8192~8195. It seems nrf51822 can receive all interrupt (point) from AFE. But when enable BTLE and start transmitting AFE sampling point (20 byte per packet) The counter drops about to 4900.

I guess this is because the priority in BTLE is higher than SPI interrupt. I found there is an EasyDMA mechanism in SPIS, but I think EasyDMA will not decrease the number of 8192 interupt if the sampling data is not consecutive in one "granted".

Hung Bui says there is an "DMA controller" will have no data loss if the SPI slave speed is 2Mbps Is that correct? Or any development tips for my situation? Thanks.

Parents
  • 0

    Hi

    I understand from your text that you are transmitting 819228=128 kbps, which is equal to the maximum throughput of the nRF51, see the S110 Softdevice specification, chapter about BLE Data Throughput. For a connected phone or central device, you will probably experience less throughput, see this thread and this blog post

    When data is transferred from the SPI master to the BLE central device, the procedure is as follows:

    • The SPI master will set the CSN line low in order to initiate the SPI transaction
    • SPI master will clock out data
    • SPI master sets CSN line high to indicate end of transaction
    • When transaction ends, the SPIS semaphore is automatically granted to the CPU
    • The CPU processes the data and relocates buffers and the CPU is granted back to the SPI slave

    The SPIS uses easyDMA so it can store data in RAM without intervention of the CPU. The SPIS semaphore prevents the SPIS and the CPU to access the dedicated RAM space at the same time. So when the semaphore is granted to the CPU, the SPI slave can not receive data from the master. If the SPI master transmits data when the semaphore is granted to the CPU, the DEF character is clocked out on MISO. So if the SPI master is receiving DEF characters on MISO, then you are sending data to early from the SPI master.

    The semaphore can be granted to the CPU for an extended time when the softdevice is enabled. This is because when during BLE connection event, i.e. when a BLE packets are sent/received over the air, then the CPU is blocked. If a BLE connection event is ongoing when a SPI transaction is complete, CPU is blocked and SPIS buffers are relocated first when the BLE connection event ends.

    Length of a BLE connection event is around 1ms when sending 1 packet per connection interval, but is around 6ms when sending 6 packets per connection interval. So if you send 6 packets over the BLE link in each connection interval, then the sending frequency of the SPI master must not be higher than sending each 6ms. This will however be improved with the upcoming third revision of the nRF51 hardware, available within the next few weeks, where CPU will be blocked for maximum of 0.25ms during a BLE connection event.

    Another solution, if at all possible on the SPI master side, is to decrease the SPI transaction frequency, but by sending more data in each transaction.

    Additional idea is to connect GPIO control line between master and slave, where the slave can actually signal the master when it is ready to receive data.

Reply
  • 0

    Hi

    I understand from your text that you are transmitting 819228=128 kbps, which is equal to the maximum throughput of the nRF51, see the S110 Softdevice specification, chapter about BLE Data Throughput. For a connected phone or central device, you will probably experience less throughput, see this thread and this blog post

    When data is transferred from the SPI master to the BLE central device, the procedure is as follows:

    • The SPI master will set the CSN line low in order to initiate the SPI transaction
    • SPI master will clock out data
    • SPI master sets CSN line high to indicate end of transaction
    • When transaction ends, the SPIS semaphore is automatically granted to the CPU
    • The CPU processes the data and relocates buffers and the CPU is granted back to the SPI slave

    The SPIS uses easyDMA so it can store data in RAM without intervention of the CPU. The SPIS semaphore prevents the SPIS and the CPU to access the dedicated RAM space at the same time. So when the semaphore is granted to the CPU, the SPI slave can not receive data from the master. If the SPI master transmits data when the semaphore is granted to the CPU, the DEF character is clocked out on MISO. So if the SPI master is receiving DEF characters on MISO, then you are sending data to early from the SPI master.

    The semaphore can be granted to the CPU for an extended time when the softdevice is enabled. This is because when during BLE connection event, i.e. when a BLE packets are sent/received over the air, then the CPU is blocked. If a BLE connection event is ongoing when a SPI transaction is complete, CPU is blocked and SPIS buffers are relocated first when the BLE connection event ends.

    Length of a BLE connection event is around 1ms when sending 1 packet per connection interval, but is around 6ms when sending 6 packets per connection interval. So if you send 6 packets over the BLE link in each connection interval, then the sending frequency of the SPI master must not be higher than sending each 6ms. This will however be improved with the upcoming third revision of the nRF51 hardware, available within the next few weeks, where CPU will be blocked for maximum of 0.25ms during a BLE connection event.

    Another solution, if at all possible on the SPI master side, is to decrease the SPI transaction frequency, but by sending more data in each transaction.

    Additional idea is to connect GPIO control line between master and slave, where the slave can actually signal the master when it is ready to receive data.

Children
Related