Failure to use the ADI SPI driver on ADuCM4050

Hi,
I have difficulties to use the SPI driver of the ADuCM4050:
In my system SPI1 is connected to ADXL362 (CS0) and SD card (CS1). SPI2 is connected to IS25LP128 (CS0, Flash memory).

Right now the SD card is not implemented and there is no card in the circuit.

Here is the function I use to generate the SPI transaction for both:

bool SPI_Action(ADI_SPI_HANDLE handle, uint16_t wr_len, const uint8_t *wr_data, uint16_t rd_len, void *rd_data)
{
ADI_SPI_TRANSCEIVER Mtransceive __attribute__((aligned(4)));
//uint8_t DummyRxBuffer[2] __attribute__((aligned(2)));

assert(((int)wr_data % 2 == 0) && ((int)rd_data % 2 == 0));

Mtransceive.pTransmitter = (uint8_t *)wr_data;
Mtransceive.TransmitterBytes = wr_len;
Mtransceive.nTxIncrement = 0;
Mtransceive.pReceiver = rd_data;
Mtransceive.ReceiverBytes = rd_len;
Mtransceive.nRxIncrement = 0;
Mtransceive.bDMA = true;
Mtransceive.bRD_CTL = (rd_len == 0) ? false : true; // Ignore the activity on MISO during write;

return (ADI_SPI_SUCCESS == adi_spi_MasterReadWrite(handle, (const ADI_SPI_TRANSCEIVER* const)&Mtransceive));
}

if I initialize Mtransceive.bRD_CTL = true, then writing 2 bytes and read 0 bytes from the ADXL362 causes the call to adi_spi_MasterReadWrite() to never ends.
if I initialize Mtransceive.bRD_CTL = false, then the previous problem is solved, but then I always read bytes of 0xFF from the flash IC...

This is how I finally arrived to the code I have just sent you that contains a strange condition on the value that is assigned to bRD_CTL field..., but I fail to understand what happens here.

My question is what is the exact role of the bRD_CTL and what is the source of the behavior I am observing?

Thanks,
Kobi

Top Replies

    •  Analog Employees 
    Sep 16, 2019 in reply to KdT +1 verified

    Hi 

    1. If you set bRD_CTL to true, the read buffer will only be filled after it transmits nTransmitterBytes number of bytes. If it is false, the read buffer is being filled at the start, while transmitting…
  • 0
    •  Analog Employees 
    on Sep 4, 2019 3:22 AM over 1 year ago

    Hi

    According to the device drivers api reference manual. bRD_CTL indicates whether the transaction should enable RD_CTL (true) or not (false). RD_CTL effectively provides half-duplex operation as outlined in the HRM. More info about it on page 15-31 of the HRM. You can also be guided by this User Guide.

    Also, are you sure about setting the nTxIncrement and nRxIncrement to 0? This may be the source of the behavior you are observing,

    Regards

  • Hi jhake,

    I am sure the nTxIncrement & nRxIncrement are both 0...

    Thanks,

    Kobi

  • Hi jhake,

    Sorry, I misunderstood your last question.

    I don't need that the pTransmitter & pReceiver fields will be modified by the driver function at the end of the call.

    I use a blocking driver function, and allocate the necessary buffers (including the one of the Mtransceive struct in the stack) for each call.

    Thanks,

    Kobi

  • 0
    •  Analog Employees 
    on Sep 6, 2019 2:15 AM over 1 year ago in reply to KdT

    Hi

    The nTxIncrement and nRxIncrement should be 1 so that the receive and transmit buffer pointers move by 1 byte every receive/transmit. Try to have them set to 1, unless you're sure that you should have it on 0.

    Regards

  • Hi jhake,

    I modified the nTxIncrement to be 1 if I have any byte to write (else 0), and similary for the nRxIncrement,

    Now I tried the following combinations:

    1. RD_CTL = false:

    Now when I only write, it seems to work, but when I tried to both write and read, then the program halted due to an internal assert (not in adi_spi.c, but I had no access to the file source code). It ends with a call to _kill() and dissasembly window.

    2. when RD_CTL = true:

    Now the application stayed in the driver function, when I tried to only write but not to read.

    My summary:

    It seems that the previous workaround of setting RD_CTL to true only if I have bytes to read is the one that still worked, exactly as was the case when nRxIncrement = nTxIncrement = 0.

    I could have lived "happily" (but clueless about the driver) with this workaround, but now there is a problem with the SPI when I try to work with the SD card... (never exit the driver function or returns only zeros - depending on the way I try to configure the parameter struct to the driver)

    I have no idea how such a simple task of generate a SPI transaction can become so problematic :-////

    Thanks,

    Kobi