This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

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.

Related