TMS570LS20216 SCI DMA Working Control Packet Read issue

Hello Anthony,

Thanks for the feedback.

The DMA is continuously active as the SCI-DMA is continuously receiving characters(20 characters test ). I've been able to monitor the reception by stopping the debugger and displaying the RX buffer content. The buffer contained the full frame. I was expecting, from 3) that the fact that the reception of multiple characters would update the Working Control Packet. It does not appear so. I've also tried by starting the SCI-DMA TX side to send data. The data was transmitted, but no update of the WCP.

The reason I'm trying to read the WCP is that we are using a serial protocol which has variable command length and content. The fact that, if possible,  I can check that 1 or more characters have been transfered to RAM by reading the WCP and its current address reg, would provide me a mechanism to check if a complete serial frame has been received.

Any idea ?

NOTE: If I cannot read the WCP, I will never be able to know if I received a complete serial frame. 

Thanks for your help.

Normand

Normand,

I did some experimenting w. the working control packet using a memory to memory transfer.

First, I never saw 0xFFFFFFFF in the DMA RAM in this area,  only 0x00000000 when the control packets were not written back.

Second, it seems that the control packets are only written back to this area if they absolutely must be in order to store state.  I tried some single frame transfers, where after one frame the block is complete, and this didn't write back even after the channel completed.  I guess it's 'done' and doesn't need to write back.   Writing back takes time and affects latency during channel switching, so this makes sense.  But it means you can't use the WCP the way you want to - you need to treat it as just scratchpad for the DMA and not actually use it for status.

Here's a screenshot to show you the write back finally happened, but this occurred only when I had:

  - 2 channels setup for 5 frames per block

  - only triggered 1 frame transfer for each channel  (so 4 remain outstanding)

Note that only ONE of the channels was written back, the other has it's state still held inside the DMA because it has not been switched out yet.

Also note that the address has a big gap between the initial and current / working control packet data,initial is at offset 0x000 and working at offset 0x800. 

I have not tried this myself, but here might be something that you could do.

You could trigger 2 DMA channels from the SCI.  Just configure 2 different channels to use the same channel # in the channel assignment register.   Then have the 1st channel move your SCI data, while the second channel moves a count.   The count would have a source address that points to an area of memory where you have programmed a set of values 0x00, 0x01, 0x02, etc.   The destination for the count could be a fixed location.  Then for each SCI byte you transfer make the count also transfer one byte.  In that way you might be able to read the count destination address and by seeing the value there, determine how many bytes have been transferred from SCI.   Just an idea.  Wasteful in the sense that it takes an extra DMA channel and the memory to hold the count array, but if you have the resources I think it would probably work.  EDIT:  I have used the assignment of one HW request to 2 different channels before and know that this works.  The request goes in parallel to the two channels and they both become pending.  But then the DMA handles the high priority channel first (I think the lowest #) followed by the next highest priorty.  In other words the order is controllable by selecting the channel #'s.

Hello Anthony,

Thanks for the feedback. I will give it a try.

Regards,

Normand