Post Go back to editing

[ADuCM3029]Spi read operation not working

Hi,

I'm trying to do a read operation from an IC. I can see the MISO data at the bus using an oscilloscope, but I can capture this in my application.

I'm using Analog Devices API functions:

  • adi_spi_MasterSubmitBuffer
  • adi_spi_GetBuffer

I need to send and receive data at the same transaction, so I send two Tx bytes and configures to receive two Rx bytes. But Rx bytes doesn't have the same data at the bus.

I'm using continuous mode, Dma, ADuCm3029 is the master and the chip select used is a GPIO, so I use ADI_SPI_CS_NONE.

The MISO pin has a 100k pull-up resistor.

  • Hello,

    To debug the software you can use the following steps:

    • Make sure you have the latest version of  the ADuCM3029 DFP installed (as of writing this answer, the latest version is 3.2.0);
    • Check out the ADuCM302x_DFP_Device_Drivers_UsersGuide.pdf in the DFP installation folder (ADuCM302x_DFP/3.2.0/Documents). This can point out some nuances that can mess up the communication, for example, if a callback function is registered, the adi_spi_GetBuffer method cannot be used anymore;
    • Make sure the SPI is in the right configuration to be talking to the slave (SPI phase and polarity are set correctly, speed is within range, etc.);
    • If you need to transmit and receive data in the same transaction, these bytes might not come at the same time. The slave IC's datasheet should have more information on this, but if you need to transmit 2 bytes then receive 2 bytes, you might need to have a 4 byte buffer for both the receive and the transmit. Of the transmit buffer, the first two bytes are transmit data, and the second two bytes should be neutral dummy bytes, and of the receive data, the first two bytes will be random and the second 2 will be the usable data. This works because the Transaction always happens two ways at the same time, so when transmitting a byte, you also receive one.

    These are just some debug steps I would take, from a software standpoint, without knowing what the slave is.

    Let us know if this helps.

    Regards,

    Andrei.

  • HI, 

    Thank you for all the good points, I'm using the DFP 3.2.0. And I find out that SPI was receiving the data, but some speed problem was making the data to be duplicated.

    An example:

    Sending 11110101

    Receiving 00110011

    I think that the first 4 bits also duplicate, but the FIFO overwrite with the last 4 bits. After finding the pattern I changed the bit rate, but just change the bitrate didn't solve the problem.

    Solution:

    1. Changed the bit rate
    2. Transaction to just send the read requisition, with 0 bytes at receive parameter
    3. Transaction to just receive the data requested before, with 0 bytes at transmitting parameter

    The way above worked as you pointed at:

    If you need to transmit and receive data in the same transaction, these bytes might not come at the same time. The slave IC's datasheet should have more information on this, but if you need to transmit 2 bytes then receive 2 bytes, you might need to have a 4 byte buffer for both the receive and the transmit. Of the transmit buffer, the first two bytes are transmit data, and the second two bytes should be neutral dummy bytes, and of the receive data, the first two bytes will be random and the second 2 will be the usable data. This works because the Transaction always happens two ways at the same time, so when transmitting a byte, you also receive one.

    The IC datasheet isn't very clear about the read operation, maybe this is the root of the problem. 

    And thanks to pointing about this:

    This can point out some nuances that can mess up the communication, for example, if a callback function is registered, the adi_spi_GetBuffer method cannot be used anymore;

    Best regards,

    Flavio.