• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 83 subscribers
  • Views 1012 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Does the RPT instruction stall the DMA?

AndyP
Expert 1776 points

Hi, 

I know that the RPT instruction is not interruptible, but does it also stall the DMA?

I have situation like this: ADC is sending bursts of data (serially, 8 channels, 16-bit) via a McBSB to XINTF zone 6 (external SRAM). DMA is used for this. Is it possible, that RPT instruction with zone 6 accesses (the same zone), stall the ADC transfers that it could lead to loss of data from ADC?

And one additional information: clock for the ADC and data stream is from external PLL (not from the CPU itself).

The CPU is F28335.

 

Best Regards,

Andrew

 

 

 

 

  • 0
    TI__Guru* 91215 points

    AndyP said:

    Hi, 

    I know that the RPT instruction is not interruptible, but does it also stall the DMA?

    I have situation like this: ADC is sending bursts of data (serially, 8 channels, 16-bit) via a McBSB to XINTF zone 6 (external SRAM). DMA is used for this. Is it possible, that RPT instruction with zone 6 accesses (the same zone), stall the ADC transfers that it could lead to loss of data from ADC?

    And one additional information: clock for the ADC and data stream is from external PLL (not from the CPU itself).

    The CPU is F28335.

     

    Best Regards,

    Andrew

     

     

     

     

    Hi Andrew,

    The arbitration between CPU and DMA accesses to the XINTF is described in www.ti.com/lit/SPRUFB8 - section 4.1

    Cheers

    Lori

  • 0 in reply to Lori Heustess
    Expert 1776 points

    Thank you Lori for the suggestion. I've already read that part. But the RPT instruction is a special one, and it can create long non-interruptible delays. I was wondering if the DMA can somehow break those RPT loops. Can you confirm that DMA can not break these loops?

    If this will be true, than one should be very careful when using RPT instruction (regarding responsiveness of the system). Especially when you have some slow external devices connected to XINTF zones, and RPT loop is performed on this low speed external device.

    Andrew

     

     

  • 0 in reply to AndyP
    Genius 5885 points

    Andrew,

    For such a case you have a compiler directive to disable generating code with RPT instruction. If you are writing in assembly, you are correct, it is up to the programmer to take care of such issues.

    Mitja

  • 0 in reply to Mitja Nemec
    Expert 1776 points

     Yes, I know that there is a directive for this, I am already limiting max. RPT iterations to 100. But I'm experiencing strange data loss from external ADC, and I wanted to be sure, that the RPT is indeed stalling DMA.

     Andrew

  • 0 in reply to AndyP
    TI__Guru* 91215 points

    AndyP said:
    I was wondering if the DMA can somehow break those RPT loops. Can you confirm that DMA can not break these loops?

    The RPT instruction will push the following instruction into the CPU pipeline N number of times - there is no fetch from memory.  All of this happens in the CPU and the DMA has no influence.  Once the instruction gets to the peripheral - whether it is in the read or the write phase of the CPU's pipeline - the arbitration rules in the reference guide take over.   The XINTF also takes multiple cycles to perform a read/write from the CPU or the DMA so yes it is easy to get into this situation where there are a number of arbitrations taking place.

    AndyP said:
    If this will be true, than one should be very careful when using RPT instruction (regarding responsiveness of the system). Especially when you have some slow external devices connected to XINTF zones, and RPT loop is performed on this low speed external device.

    Yes - I agree - if both the DMA and the CPU are heavily accessing the XINTF you will have bottlenecks.

  • 0 in reply to AndyP
    TI__Guru* 91215 points

    AndyP said:

     Yes, I know that there is a directive for this, I am already limiting max. RPT iterations to 100. But I'm experiencing strange data loss from external ADC, and I wanted to be sure, that the RPT is indeed stalling DMA.

     Andrew

    This will allow a break in the RPT yes - if there is an interrrupt pending this is enough for the interrupt to be taken by the CPU and serviced.  In the case of the DMA it may allow a couple of cycles for the DMA to get an access in, but then the aribtration rules will once again take over.   It works nicely for an interrupt but maybe not in this case.  Perhaps try even a lower limit for RPT?

    -Lori

  • 0 in reply to Lori Heustess
    Expert 1776 points

    Thanks for all the responses.

    Now I'm pretty sure what is happening.

    I'll give you an example. In the listing file I have multiple RPT loop like this:

    386 0000006b F60E RPT #14
    387 0000006c 2484 || PREAD *XAR4++,*XAR7 ; [CPU_] |118|

     In the C code this is a simple memcpy(), and in this case variables are in XINTF zone 6 (the actual single read and write takes 5 CPU cycles, that is 40ns in case of 150MHz CPU clock).

    So if I copy 100 words from one variable to another (both in zone 6) it should take minimum 100*2*40ns = 8us. And this is not interruptible by CPU or DMA.

    The ADC stream is clocked with 2.62MHz, so one 16-bit word is transmitted to McBSP in 6.11us.

    So when this RPT loop takes place, one ADC word is lost as DMA can not service it (and even worse problem arises -> ADC channel to buffer mapping gets corrupted).

    So the bottom line is: I must lower RPT iteration count or even entirely disable RPT.

     

    Thanks again for claryfying it for me,

    Best regards,

    Andrew