SPI Slave and BLE on nRF51822

RE: SPI Slave and BLE on nRF51822

Hung Bui — Wed, 14 Dec 2016 21:42:47 GMT

sorry for late answer, but I don't understand how would you be sure the slave would be able to set the line to low after the master finish transaction if the CPU is occupied by the radio.

I'm quite novice with Mbed, but would it possible for you to access the SPIS hardware directly ? The way mbed use SPIS on the nRF52 doesn't take advantage of the EasyDMA feature and the ORC byte. This really limit the usability of the peripheral.

RE: SPI Slave and BLE on nRF51822

Szabolcs Székelyi — Mon, 12 Dec 2016 23:35:12 GMT

I tried radio notifications, and it worked, but it was unsuitable for this purpose since sometimes the CPU was still busy when the notification was inactive.

What actually worked and ensured a stable communication between the slave and the master was per-transaction flow control. When the slave fills the buffer with data, it also sets a pin high that interrupts the master and enables it to do one transaction. As soon as the slave sees the transaction completed, it reads the data sent by the master from the buffer, sets the interrupt line to low, prepares the next transaction, and interrupts the master again by setting the interrupt line high again. This ensures that whenever the master sends something, there's a transaction already prepared on the slave side, and no more data is sent by the master before the slave is ready to receive again.

RE: SPI Slave and BLE on nRF51822

Hung Bui — Tue, 06 Dec 2016 14:55:42 GMT

It could be a good idea. You can configure to receive radio notification on either ACTIVE, INACTIVE or both. You would need to keep track of this as there is no indication when it's active or the opposite. The CPU usually won't be occupied when the radio is inactive.

But from my point of view, if you already want to access something mbed is not provide, why don't just bypass mbed SPI and access the SPIS hardware register directly and simply provide large enough buffer with EasyDMA ?

RE: SPI Slave and BLE on nRF51822

Szabolcs Székelyi — Tue, 06 Dec 2016 14:32:43 GMT

What I'm trying to do now is to have the slave to signal the master on a dedicated signal line before it becomes unable to reply. This way the master can throttle polling it and resume when the signal goes low again indicating the slave's CPU is available again to reply. I'm using the nRF5 SDK's radio notification to achieve this. Though I'm not sure if this notification will mark exactly those times when the nRF's CPU is taken over by the BLE stack.

RE: SPI Slave and BLE on nRF51822

Szabolcs Székelyi — Tue, 06 Dec 2016 14:30:15 GMT

Well, discarding the transaction is not a good idea in this situation since I'm only sending continuously from the master side to poll if the slave has any data to send to the master. The very simple protocol I'm using on the bus is to send the number of bytes available so the master knows how many bytes to pull from the slave after (this can be zero). That's why I need to keep the bus running all the time, so sending a zero to the slave will allow the master to see if the slave has anything to send to it.

RE: SPI Slave and BLE on nRF51822

Hung Bui — Tue, 06 Dec 2016 12:54:33 GMT

What do you have on the master side on the second transaction ? Would it be the same byte as the first transaction ?

I am thinking it can discard the transaction if it detects the data from the slave is exactly the same as the last one. But this require you to add 1 bit as the flow control bit. So you only have 7 bit for data.

Another option is to export the project or use mbed CLI and you can modify the library on your purpose.

RE: SPI Slave and BLE on nRF51822

Szabolcs Székelyi — Mon, 05 Dec 2016 14:00:28 GMT

Of course the problem can be solved by using larger send/receive buffers so that the CPU has more time to prepare a reply, but unfortunately that's not possible with mbed's SPISlave API.

RE: SPI Slave and BLE on nRF51822

Szabolcs Székelyi — Mon, 05 Dec 2016 13:57:41 GMT

Yes, it definitely looks like a problem (or feature) related to mbed. In mbed, the send/receive buffers are one byte long. One requirement of a successful transaction is that there's some data already prepared in the send buffer. This requires calling the SPISlave::relpy() function before the transaction starts. If there's a reply already prepared in the send buffer, it's clocked out by the next transaction. But in order to keep the SPI bus running (from mbed's point of view), SPISlave::reply() has to be called again before the next transaction. If the master initiates the next transaction before SPISlave::reply() is called on the slave, mbed enters an (undetectable by API) error state when SPISlave::receive() (that tells if there's a completed transaction) will never again return true unless you call SPISlave::reply(). Then you're good again until the next missed transaction.

RE: SPI Slave and BLE on nRF51822

Hung Bui — Mon, 05 Dec 2016 13:18:40 GMT

I assume this issue comes from the mbed implementation. What exactly happens when it "blocks all data reception until a reply is prepared in the send buffer " ?

As from the hardware point of view, what i can see is that after you hit "buffer underrun" you will receive OVERREAD event, and on the master it will receive the ORC byte. There shouldn't be a lock up here.

Would increasing the RX buffer help avoiding the issue ?

RE: SPI Slave and BLE on nRF51822

Szabolcs Székelyi — Sun, 04 Dec 2016 04:46:35 GMT

The problem was data jam on the SPI bus. Once the SPI peripheral hits a buffer underrun (or "overread error" as the Reference Manual calls it), it becomes essentially unusable under mbed because it blocks all data reception until a reply is prepared in the send buffer. (But since this normally only happens after a reception, this becomes a deadlock). If you fill the buffer with an "unsolicited" reply, the bus will start working again.

In my case the overrun was caused by the delay introduced by mbed's BLE implementation. A working BLE radio can block the CPU for as long as 1495 microseconds (that's not the theoretical maximum, just the highest value I've seen). If the SPI peripheral has to execute more than one transaction (as dictated by the master) during the time when the BLE stack (or anything else) uses the CPU, you enter the above deadlock.

RE: SPI Slave and BLE on nRF51822

Hung Bui — Thu, 01 Dec 2016 12:14:32 GMT

Which mbed board are testing with ?

Some of the thread you quoted was pretty old and may not relevant anymore. For example the CPU is no longer locked up when the radio is active. It's hard to tell what went wrong, I'm not very familiar with mbed and it's also harder to debug with mbed. I would suggest to post the question on mbed forum, in addition. And maybe you can try to export the mbed project to debug offline ?

PPI and BLE should be fine as long as you don't use the PPI that the softdevice occupies.

With the hardware we have, SPIS and BLE should work, worst case is that SPIS will clock out DEF when it can't access the memory.