• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 33 subscribers
  • Views 2314 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RM57 - DMA and SPI (non MIBSPI) - missing second byte

Davor
Intellectual 715 points
Other Parts Discussed in Thread: TMS570LC4357

I am having issues with RM57, DMA and SPI.

Notably, the second byte of the DMA SPI TX is always lost. Attached is the project + scope trace. Notice in the trace that 02 is missing.

Attached is the project with all relevant code to produce the scope trace above. 3681.rm57_spi_dma.zip

  • 0 in reply to Davor
    TI__Guru**** 191206 points

    Hello Davor,

      Sorry for the slow response. It is a major US holiday today and most people are not back to work until next monday. What you have shown indicates that there is a buffer overrun condition. The SPI employs a double buffer architecture which consists of a shift register and a buffer.  When the character in the shift register is not completely shifted out and the buffer already contains the second data and if there is another write to the DAT0 then this third write will overwrite what is already in the data buffer. in your case, the 0 which is in the shift register is being shifted out and the data 1 is in the data buffer. if the data 2 is written to DAT0 then it will overwrite the data 1 already in the data buffer. As far as why this is happening, we probably will not know until we have someone to take a closer look at it. Seems like either the SPI might be generating the DMA request too quickly. Sorry for the inconvenience and thank you for your patience.

  • 0 in reply to Charles Tsai
    TI__Guru**** 191206 points

    Hello Davor,

      I created a new project trying to mimic your setup and I'm able to reproduce your observation. It looks like it has something to do with your GCLK:HCLK ratio. Currently you have 3:1 ratio with GCLK=330MHz and HCLK=110MHz. All the VCLKx are also configured for 110MHz. These ratios are valid according to the LC4357 TRM even though it is not the most optimum setting from overall system performance point of view. When I change the clock ratio to GCLK:HCLK=2:1 with GCLK=330MHz and HCLK=165MHz and also the VCLKs being 82.5MHz the problem with the missing second byte goes away. While we will investigate further on the root cause please change the clock ratio to 2:1. It not only solves the SPI problem but also improves the performance. In the device architecture, there are some pipelining on the bus transactions between the CPU and the memory system and these pipelining operates at HCLK frequency. When you have the ratio at 3:1 each pipeline stage costs 3 GCLK cycles to the CPU in terms of latency. When you have the ratio at 2:1 the latency is reduced to 2 GCLK cycles. There are several pipelining stages in the architecture so the latency can add up. 

  • 0 in reply to Charles Tsai
    Intellectual 715 points

    Hello Charles!

    I'll test this right away. Thank you!

    Interestingly, the max for HCLK is stated as 150Mhz (which was why I thought 3:1 ratio was necessary with GCLK.330Mhz).

    edit: Works! Marvellous! THank you!

  • 0 in reply to Davor
    TI__Guru**** 191206 points

    Hi Davor,

      I think you are right that RM57 is stated for 150MHz on the HCLK. I will need to have some internal discussion on the solution for 3:1 ratio.

  • 0 in reply to Charles Tsai
    TI__Guru**** 191206 points

    Hi Davor,

      Another option is that the GCLK be set to 300MHz. This will limit the HCLK to 150MHz in the 2:1 ratio. The VCLKs to HCLK will also be 2:1 ratio making them 75MHz.

  • 0 in reply to Charles Tsai
    Intellectual 715 points

    Mmm, there are a few options.

    I also intend to use SRAM on the board, which is clocked from VCKL3. My original clocking had this at 110Mhz (with a 133MHz or faster SRAM chip to cope with this). Dropping this to 82.5Mhz or even 75Mhz is quite a performance hit.

    Oh well, at the moment I am just happy that DMA works and I can continue. :D

  • 0 in reply to Charles Tsai
    Prodigy 110 points

    I have the same issue where the 2nd byte is dropped by the DMA/SPI configuration.  I am using the TMS570LC4357, and I am not sure if that is the same as the RM57 mentioned in the OP.

    I confirmed that I have a 3:1 GCLK to HCLK ratio.  However, I am at a point in my project where my team has almost all of the requirements written and peripherals configured and tested, all except SPI and DMA not working properly.  I put the project at significant risk by changing the clock settings which have been used and tested for over a year.

    Can I get confirmation that this issue is applicable to the TMS570LC4357?  If I setup the DMA/SPI with some dummy data in the second byte, can I get confirmation that the dummy data will always be skipped?

    Also, was the root cause ever identified?

  • 0 in reply to Michael DeClerck
    TI__Guru 68920 points
    Michael,

    The issue is fixed in silicon revision B - so you should move to that silicon if at all possible.

    It is documented as DMAOCP#01 in the errata www.ti.com/.../spnz180c.pdf and the root cause is explained in the errata description. It's listed as 'Workaround None', even though the 3:1 ratio for SPI is discussed in this thread, because the errata covers DMA in general; and because other than perturbing the timing I don't think anyone has gone further in proving that the 3:1 ratio is bulletproof for SPI - which is why it was necessary to fix the issue on Rev. B.

    For rev B silicion - www.ti.com/.../spnz232.pdf section 3 "Silicon changes from previous device revision" lists DMAOCP#01 as fixed - for your reference.
  • 0 in reply to Anthony F. Seely
    Prodigy 110 points

    Does the DMA still increment properly on the Rev A despite this timing issue?  For instance, I may want to use the DMA to fill the transfer group RAM.

  • 0 in reply to Michael DeClerck
    TI__Guru 68920 points
    On Rev A, I don't think you can use the DMA at all with a 3:1 clock ratio, without the possibility of a lost transfer, if there is any chance that more than one request could be active at the same time.
    While the original post was two SPI requests back to back, the analysis showed that a software triggered request and a peripheral triggered request, which may be back to back just due to the asynchronous nature of the requests - would have the same problem.