SPI Slave problem with buffers (nRF51, SDK v10) - Bug in nrf_drv_spis_event_t structure?

[puz_md]

Hello,

I've been working with the SPI Slave on a nRF51-DK for several days. I am using the nRF51-DK (PCA10028), S130 v1.0.0 and SDK v10.0.0. First, I set up a RX and TX buffer of equal size (nrf_drv_spis_buffers_set() is called with same RX and TX buffer lengths). In this scenario, everything seemed to work fine.

After I started to implement my SPI protocol, I wanted to change the TX buffer length so that it represents the actual amount of data to transmit. I expected the driver to send the "overread" character for any additional bytes. The RX buffer length was kept at the actual buffer size. In this scenario, I had a lot of trouble with receiving the expected data. I played arount with switching buffer length parameters in nrf_drv_spis_buffers_set() but in the end, I came to the following conclusion:

In the nrf_drv_spis_event_t structure which is reported to the event handler, rx_amount and tx_amount are switched.

Can anyone confirm this bug? If I use the tx_amount value as the number of received bytes, my current implementation seems to work fine.

Update:

SPIS_Test.zip

Here is a sample code that demonstrates the bug. It is a makefile project with GCC toolchain. see hardware_config.h for SPI pins. You can observe the debug output with the Segger JLink RTT Client (see driver/spis.c, spis_event_handler() ).

The software configures a TX buffer of 2 bytes and a RX buffer of up to 200 bytes. Buffers are cleared to 0 before each transaction. Now, when you use a SPI Master to send for example 8 bytes (data bytes are not 0), you can see the that the correct data has been received (8 data bytes) but rx_amount countains 2. On the other hand, tx_amount contains 8 although we only configured a tx buffer length of 2 bytes. You may switch those values and the debug output shows the correct information.

[Susheel Nuguru]

puz_md,

Thanks for this report,

I did some debug and found that this is a bug in the driver in file nrf_spis.h

__STATIC_INLINE uint8_t nrf_spis_tx_amount_get(NRF_SPIS_Type const * p_spis)
{
    return (uint8_t) p_spis->AMOUNTRX;
}

__STATIC_INLINE uint8_t nrf_spis_rx_amount_get(NRF_SPIS_Type const * p_spis)
{
    return (uint8_t) p_spis->AMOUNTTX;
}

Here you can see clearly that wrong registers are fetched. Correct them to the below.

__STATIC_INLINE uint8_t nrf_spis_tx_amount_get(NRF_SPIS_Type const * p_spis)
{
    return (uint8_t) p_spis->AMOUNTTX;
}

__STATIC_INLINE uint8_t nrf_spis_rx_amount_get(NRF_SPIS_Type const * p_spis)
{
    return (uint8_t) p_spis->AMOUNTRX;
}

I will add this in known bugs in here and register an internal ticket for the team to know about it

[puz_md]

Currently I am using SDK10 as SDK11 is still in alpha state. I can't remember if I actually compiled my code with SDK11, but I definitely took a look at the release notes and there was no information about a fixed SPIS bugs. So I assumed the bug would still be present in SDK11 ;)

Maybe not so many people use the SPI Slave interface (with a complex protocol), as this would suggest that there is another microcotroller which uses probably more power than the nRF5x. So this would not be a classic low power application. We are using the nRF5x in different scenarios where sometimes low energy consumption is crucial. In other cases, there is enough power available and the nRF5x just provides Bluetooth (Smartphone) support and sometimes sensor access for a device. Having the same software and hardware architecture makes development much easier :)