What initiates the TCP events XEVT and REVT?

Tim,

Tim Jackson said:

It seems strange to me that a co-processor should take it on itself to request data.

The TCP2 is designed to work as efficiently as possible and to operate with the resources available in the DSP. This is not strange at all. The McASP does the same thing after it is released from reset. In older DSPs, this was not the case, and you would have to have the DSP code start the first DMA transfer manually; this way you just setup the DMA and then the TCP2, and things run automatically for you.

Tim Jackson said:

How does the TCP know the params have been written?

If you program your EDMA channels and their PARAM as described in section 9.2 Programming Standalone (SA) Mode, it will work.

We choose to describe how you can use the TCP2 to make it as easy as possible for you to figure out how to program it. You can learn a lot about the internal logic from the programming descriptions, depending on your understanding of the EDMA3. For example, it says to set ACNT=64 for the Input Configuration Parameters Transfer, set ACNT=8*ceil(frame_length/2) for the Systematics and Parities Transfer, and set ACNT=8 * ceil ((frame_length+3)/4)) for the Interleaver Indexes Transfer. For all cases, BCNT=1 and CCNT=1, so these ACNT values are the exact number of bytes that need to be transferred.

Tim Jackson said:

this isn't just a confusingly labelled figure is it?

It is confusingly labeled if you do not understand the sequence of events that it is trying to describe. To me, it is slightly confusing because of the shorthand notation used for the events: XEVT should actually be TCPXEVT and REVT should be TCPREVT. But this detail did not confuse you, and for that, we thank you.

Please let us know if you have problems with the programming instructions. Have you found any example code? If not, we may need some more details on DSP, CCS version, and software package you are using.

Regards,
RandyP .0

If this answers your question, please click the  Verify Answer  button below. If not, please reply back with more information about your TCP2 questions.

Hi RandyP,

Many thanks for taking the time to try and help me.

Thank you for confirming that the TCP does 'make the first move' after reset. Yes, I can see the logic, and yes I probably am guilty of having a few out of date assumptions.

And yes, I have attempted to follow section 9.2, supplementing it with the "VCP2 TCP2 Channel Density" project code together with the CSL documentation. But I've obviously got something wrong and in the process of digging a bit deeper I realised that I did not understand figure 98, hence my question.

I think I have the correct values of ACNT, BCNT and CCNT (and the other 5). Stepping through the code, I've watched them get loaded into the various structures and watched them be loaded into the EDMA3 PSETS. And I've wathced them subsequently get zeroed and the LINK field get set to 0xFFFF, indicating the EDMA3 has completed its 3 Linked jobs. However, the TCP never generates TCPREVT, and sits there with STATUS=0x03006012, i.e. WINT=1, waiting for the interleaver table to be loaded.  Hence me wondering (then and now) just how it knows when its input params, especially the interleaver table, have finished being loaded.

Can you suggest what I should check next please?  Many thanks.

Tim

(CCS 3.3.79.5, TMS320C6455 on Sundance SMT362 on SMT310 carrier card.)

Correction: It would be more accurate to say that the first PSET gets zeroed and it's link set to 0xFFFF indicating that at least one of the two linked transfers completed. Not sure how to tell if one or both were copied over the original PSET.

And just in case it helps, here are the PSETs before the DMA kicks off :

0x02A04600 - 0x8001F000
0x02A04604 - 0x008B1A30
0x02A04608 - 0x0001 0040
0x02A0460C - 0x50000000
0x02A04610 - 0x0000 0000
0x02A04614 - 0x0000 4620
0x02A04618 - 0x0000 0000
0x02A0461C - 0x0000 0001

0x02A04620 - 0x8001F000
0x02A04624 - 0x00997D80
0x02A04628 - 0x0001 0460
0x02A0462C - 0x50010000
0x02A04630 - 0x0000 0000
0x02A04634 - 0x0000 4640
0x02A04638 - 0x0000 0000
0x02A0463C - 0x0000 0001

0x02A04640 - 0x8001F000
0x02A04644 - 0x00999000
0x02A04648 - 0x0001 00E0
0x02A0464C - 0x50050000
0x02A04650 - 0x0000 0000
0x02A04654 - 0x0000 FFFF
0x02A04658 - 0x0000 0000
0x02A0465C - 0x0000 0001

Tim,

Are you able to successfully run the "VCP2 TCP2 Channel Density" project by itself?

Tim Jackson said:

the LINK field get set to 0xFFFF, indicating the EDMA3 has completed its 3 Linked jobs.

If your TCPXEVT channel is mapped so its active PARAM PSET is at 0x02A04600, then you were right the first time, with the statement above. You have to go through the link sequence to get to the NULL PARAM PSET at the end. If you want prove to yourself that the sequence is being followed, change the first LINK field to FFFF and look at the status bits and the PARAM, then (after a reset) do that for the second one instead. Or clear the EER bit for the channel and manually trigger each phase by writing to ESR.

Having the third LINK field be FFFF will cause problems once you get the whole thing working. There will be a new TCPXEVT after the last read transfer and that will cause problems for the XEVT channel if its PSET is NULL.

Tim Jackson said:

However, the TCP never generates TCPREVT, and sits there with STATUS=0x03006012, i.e. WINT=1, waiting for the interleaver table to be loaded.

You can tell that the DMA channel responded to all three TCPXEVT, so these worked well. The fact that WINT=1 means that there is a mismatch between the configuration information you have sent to the TCP2 and the data that you have sent to it. Try writing a few more words from the DSP (or the debugger) or changing ACNT for the 3rd PSET and see what has to happen to make the 3rd phase complete.

I do not know the TCP well enough to tell you which parameters to look for, but this is a case where you just need to double-check them all to see what could be going wrong.

Regards,
RandyP

Hi RandyP,

Ha, got it! 

When you included "ACNT=8 * ceil ((frame_length+3)/4))" in your response I rather glossed over the details as I recognised it from the example code, and not taken in the "+3"  - but this is REALLY key isn't it!  When I previously said "I guess it could read the frame length and the start address and wait for the last value to be written, but I very much doubt it." I had no idea how significantly wrong I could be.  The "+3" suggests that not only does it monitor the write process but it does it 32 bit word wise and the "+3" makes sure the 'write last word' detector gets triggered.

Am I correct?  If so, did I miss this key detail in the documentation somewhere?  If not, then what's the process for getting it added?

Regards & many thanks for your time and effort,

Tim

Tim Jackson said:

Am I correct?  If so, did I miss this key detail in the documentation somewhere?  If not, then what's the process for getting it added?

You are correct that this formula is what you need to follow to get the operation to work right. I have no interpretation of the formula to offer, but you are at least as good an engineer as I am, except I just trust the formula that someone really knowledgeable came up with.

I am not sure what you mean about the documentation. I pulled this formula from the TCP2 User's Guide, from the section listed with the original statements on ACNT/BCNT/CCNT.

Do you have it working now?

Regards,
RandyP

If this answers your question, please click the  Verify Answer  button below. If not, please reply back with more information.