Post Go back to editing

Wrong Data received from SPI1

Category: Software
Product Number: ADSP-21593
Software Version: CCES 2.10.0


I am trying to set up a proper communication between the Core2 of the ADSP-21593 and an on-board LAN-Chip. The SPI1 is used for this communication. This works fine for the simple approach of communicating in terms of sending 3 bytes and receiving 4 bytes from the LAN-Chip (1 register value) in both single and quad SPI mode. The problem occurs when it is tried to send 3 bytes and receiving more than 4 bytes (register polling). Then the SPI1 receives wrong data. This problem can be avoided if there is a print-statement inserted which only prints '\n' AFTER the actual SPI-transmission. Then the data is valid. Also running on a breakpoint which is set after the SPI-transmission validates the data in some way. But this solution is not satisfying at all. I cannot figure out what the problem is at the moment. Also waiting for a certain amount of time after the SPI-transmission does not solve it. Is there any reasonable explanation for that?

Regards, Vitus

  • Hi Vitus,

    Can you please provide your comments on below points to assist you better on this.

    1. Can you please share SPI controller and status registers value.

    2. Are you getting any error or exception while receiving a wrong data?

    3. Are you using DMA or core mode.

    4. If possible, could you please share your simple project which simulates this issue?

    Anand Selvaraj.

  • Hi Anand,

    sorry for the late answer.

    1. SPI1_CTL: 0x002000B2 SPI1_STAT: 0x00440C01, values are the values after a SPI transmission

    2. No, I don't get any error or exception. The data just 'gets corrected' when executing "std::cout << std::endl;".

    3. I am using DMA mode with quad-SPI.

    4. I just put together a simple project which shows the problem. It reads the values from the LAN-Chip via SPI1, copies it into another buffer, then prints the new line. After that the values of these two buffers are compared. Of course, they should be equal, but they are not. The number of values that differ in both buffers is then printed on the console. And this number is never zero, unfortunately.

    In the mean time I also found out that it does not matter whether the newline is printed before or after executing the communication over SPI - which also seems very weird to me.

    Regards, Vitus

  • Hi,

    Apologies for the delay, we understand that you are using L2 cached memory to store the SPI buffers.  If an outside source (e.g.,  DMA  controller) is accessing memory that is defined as cacheable, the programmer must ensure memory coherency.  

    If your input data buffer resides in cacheable memory, then after modifying the buffer it should be flushed from memory using the flush_data_buffer API in the ADI_FLUSH_DATA_NOINV mode. This prevents the DMA transfer from accessing stale data.

    If your results buffer resides in cacheable memory, then before triggering the RX DMA channel to permit transferring new results, the buffer should be  flushed using the flush_data_buffer API in the ADI_FLUSH_DATA_NOINV mode. The data should then not be accessed until the RX DMA channel says the next set of results are ready. When the results are ready, the buffer should be invalidated by calling the flush_data_buffer API in the ADI_FLUSH_DATA_INV mode..

    To know more about flush_data_buffer please refer the below CCES help path.
    CrossCore® Embedded Studio <version> > System Run-Time Documentation > Cache and CPLBs > SHARC+ Caching Configuration and Support Functions > flush_data_buffer

    Anand Selvaraj.