Can I read a register to determine EDMA3 transfer destination in Ping Pong buffer?

Randy P? Anyone have any suggestions?

Mukul?

Hi Mike

Regret that this query has been un attended for a while. I have to admit that EDMA3 LLD is not my strong point, so I will point this thread to a few more folks who might be able to help on this more effectively on this. If the issue becomes too EDMA3 LLD specific you might want post a more specific query on the BIOS forum

For EDMA3 LLD there is a useful wiki ( I suspect you might've already seen it) and it has some examples on ping pong for 6437, which is not the part that you are using, but you could possibly see if that helps , incase you have some setup/software issues

http://processors.wiki.ti.com/index.php/Programming_the_EDMA3_using_the_Low-Level_Driver_%28LLD%29

MikeH said:

Is there a way to actually "read" the destination (ping or pong) from a (hardware) register within the EDMA3 controller so that I don't have a sync issue?

I am not sure if i completely understand this or what could you be doing wrong here , that makes you miss interrupts ocassionally... but you could possibly read the "active PaRAM" for McBSP TX or RX (whichever you are using) and look at the DST PARAM ( a CPU read of PARAM space) to see if it belongs to ping or pong buffer etc.

I would also recommend you elaborate on what could be causing an occasional missing of interrupts, is the software/processing steady state or do you have a surge of peripheral or processor activity when you see a missed interrupt etc?

Regards

Mukul

MikeH,

There are moderately dynamic registers like the PARAM that may be updated regularly and would show the current destination address. There are highly dynamic registers like the Transfer Controller's Source Active Destination Address Register (SADST) and Destination FIFO Destination Address Register (DFDSTn). But reading any of these to check status is like reading the Program Counter to decide which function you are executing - as soon as you read it, the data is stale.

Of course, that depends on some details, like which OMAP device are you using, and which peripheral is data coming on, and how fast is the data, and how much comes in per interrupt. And just for the record, which CCS and PSP and EDMA3LLD are you using?

The right solution is to figure out whether you are really missing interrupts, and if so, why you are missing them, and fix that.

Unless you put in a backup interrupt, when you miss an interrupt you will lose some data. And I just made up the "backup interrupt" thing to feel 100% accurate in that statement. This is my thinking on it: If you get an interrupt that tells you Ping is full, then Pong starts filling while you process the data in Ping. If you miss the interrupt that says Pong is full, Ping starts filling again anyway. When you get the next interrupt indicating that Ping is full again, you lose all the data in Pong because it is starting to fill again while you process Ping. I'm not sure how well I said that, so let me know if it does not make sense.

If this is for debug to figure out if you are missing interrupts and you just want to get a quick check on what is being transferred, you could read the PARAM.LINK field to see which PARAM will link in next. That will also tell you which one is running now, with the caveat that it may be about to change depending on speeds and loading and so on.

You could also use two difference TCC values for the Ping and the Pong PARAM link sets. An EDMA Interrupt Dispatcher would call a different ISR depending on which transfer set has just completed, so you would not have to read anything to figure out which one you are servicing.

Regards,
RandyP