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

SPIM writes with address offset

I'm developing a custom driver (C++) for the SPI master. Somewhere I've made a mistake, where the first received byte is written with a memory offset in SPI mode 1. I.e. we expect the slave to return three bytes [0x0C 0xA3 0xC0], but we must read four bytes and we receive [0x?? 0x0C 0xA3 0x33]. We've verified with an oscilloscope that the slave responds as expected and that the SPI mode is correct and the slave is selected correctly.

To initiate the transfer we use this code:

// Static variables
static constexpr uint8_t kBufferSize = 4U;
static volatile rx_buffer[kBufferSize];
static volatile tx_buffer[kBufferSize];

// Transaction start
// (Since we're only reading we could set the TX values to something more
// elegant, but for simplicitly we set them explicitly)
NRF_SPIM0->CONFIG = (SPIM_CONFIG_CPOL_ActiveHigh << SPIM_CONFIG_CPOL_Pos) |
 					(SPIM_CONFIG_CPHA_Leading << SPIM_CONFIG_CPHA_Pos);
NRF_SPIM0->TXD.PTR = reinterpret_cast<uint32_t>(tx_buffer);
NRF_SPIM0->RXD.PTR = reinterpret_cast<uint32_t>(rx_buffer);

NRF_SPIM0->TXD.MAXCNT = kBufferSize;
NRF_SPIM0->RXD.MAXCNT = kBufferSize;

NRF_SPIM0->TASKS_START = 0x01U;

// Interrupt service routine
NRF_SPIM0->EVENTS_END = 0U;
NRF_SPIM0->EVENTS_STOPPED = 0U;
NRF_SPIM0->EVENTS_ENDRX = 0U;
NRF_SPIM0->EVENTS_ENDTX = 0U;
NRF_SPIM0->EVENTS_STARTED = 0U;

// Slave transmits    [0x0C 0xA3 0xC0 0xFF]
// Rx buffer contains [0x?? 0x0C 0xA3 0xC0]
I clear both the TX and RX buffer prior to each reading and the behaviour is consistent.
There are two other slaves on the bus, which uses a different mode (0). These work as expected. The data that is output by the master also works as expected (in all cases). I also check the next memory address (rx_buffer[4] after increasing the allocated buffer size) and it does not contain the "missing byte".
I'm really stumped on this and would greatly appreciate any hints on how to troubleshoot this further.

nRF52832
SoftDevice 132 v3.0.0
No SDK
Parents Reply
  • Yes, here is a screenshot from the oscilloscope. In this case we're also outputting a command, but its not relevant for this case. What I expected to receive from this was a RX buffer of 0x0C 0xC4 0x75 0xFF, but instead it contained 0x?? 0x0C 0xC4 0x75.

    Yes, I'm aware of the parallel byte. This is (in my opinion) a slightly odd IC in that it doesn't receive a command prior to outputting the data.

Children
Related