• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 30 subscribers
  • Views 514 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.

Problem with RTI->DMA->ADC->DMA reset

matteo lucarelli
Genius 3265 points


Hi,

on a RM48HDK I'm using a complicated chain of devices to perform a fast continuous acquisition from an external device (an infrared array). Currently I'm experimenting some reset problem because on sequential restart of my acquisition sometimes the last pixel of my array goes on first position. Probably I have some reset problem.


I cannot enter in detail here but that's the device chain:

- the RTI compare1 generate approx 1MHz DMA request

- the DMA CH0 on every request changes the HET1 DOUT state to feed my array and the ADC2 too

- the ADC is triggered by the HET1[14] and every conversion generate a DMA request

- the DMA CH2 on every ADC request moves a single ADC sample into a large buffer

- the DMA CH2 uses the HB and FB interrupt to call my "send data" function

All works flawless exept for the problem above. On every restart I perform the complete setup of the chain to be sure of a consistent behaviour throught sequences.

Perhaps my startup setup forgot to reset somthing and a DMA request remain appended somewhere but how to be sure to completely reset every device? Any suggestion?

Thank you,

Matteo

  • 0
    TI__Guru 68940 points

    Matteo,

    How are you determining that the last pixel goes first?  Is it just by the value of the data?

    Also, when you have the list pixel going first,  did it also go last during the previous cycle? i.e. is it repeated.

    What I'm getting at is whether you're just reading off of an empty FIFO and getting the last value twice.

    For the purposes of debugging this we allow you to add the FIFO empty/full status bit to the data read by the ADC - maybe you can turn that on to confirm it's not a case of reading twice from an Empty fifo.

    Also, is therre any guaranteed timing relationship between step 2 and step 3 in your list above, i.e. is HET1 DOUT toggling the same pin that results in the ADC trigger all as one step?   Or is HET1[14] being toggled by something in your HET program. 

    The HET might be introducing some jitter on the sequence if it's not the first case so thinking about how that may perturb timings is something else you might want to consider.   Remember that if you are setting a pin in software in the HET program, that the pin will change on the loop resolution boundary.  If the RTI isn't sync'd to HET somehow (unlikely that it is) then the RTI request might happen during different cycles of the HET loop and there may be some varying delay between the RTI triggering and the HET1[14] pin triggering.

     

  • 0 in reply to Anthony F. Seely
    Genius 3265 points

    Solved. I've forgot to reset the ADC FIFO.

    Thank you, anyway