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 EDMA3 event queues and McBsp0 on C6457

Hi

we have seen a strange behaviour on a C6457 (Chip Rev. 1.4), we would like to have some feedback or indication if anybody else has had similar issues.

We have configured some EDMA transfers through McBsp0. Data TX is triggered by event 12 (XEVT0) and Data RX by event 13 (REVT0).

The EDMA configuration is very simple storing a certain number of 32-bit words from DRR in a couple of ping-pong buffers and writing in DXR a certain number of 32-bit words from another couple of ping-pong buffers. The EDMA interrupt to CPU is triggered when the ping-pong buffer in use becomes full/empty. The strange behaviour occurs in simplex, half duplex and full duplex configuration (i.e. does not depend on the number of additional channels in use).

The strange phenomenon is that the data transfers and the consequent interrupt to CPU work IF AND ONLY IF the events triggering the EDMA channels are routed to the Channel Controller Event Queues 1 and 2.

If any of the queues 0, 3, 4, 5 is used the data transfer doesn't start.

With other EDMA transfers not using the McBSP0 we can freely use any of the queues also simultaneously with those through McBsp0.

Needless to say we have observed this phenomenon also using only the transfer on channels 12 and 13, moreover the data rate is safely low.

We have made also some "not politically correct" test by changing the queue number during emulation halt (McBsp0 stopped!) by writing directly in the DMAQNUMn registers through the registers window or through the memory window.

What happens is that moving the Channels 12 and 13 between queues 1 and 2 the system continues to work, but upon selecting any between queue 0, 3, 4 5 the transfer stops and never restart also reverting to queue 1 or 2.

On the contrary the other EDMA transfers not using McBsp0 (specifically some linked to GPIO interrupt and using Emif) continue to work selecting any of the CC queues directly writing to DMAQNUMn registers during emulation halt or selcting them during configuration phase.

What could be wrong with our code? Or has anyone ever seen something similar with C6457?

Thanks a lot for your help

Roberto

  • Roberto,

    Welcome to the TI E2E forum. I hope you will find many good answers here and in the TI.com documents and in the TI Wiki Pages. Be sure to search those for helpful information and to browse for the questions others may have asked on similar topics.

    In this case, the behavior you see is exactly how the C6457 was designed to operate. I have been caught by similar restrictions on other DSPs, and it can be difficult to figure out until you know where to look.

    Each of the C64x+ and later devices will have a Connection Matrix in the datasheet to detail all of the internal connections that are possible. Not all internal bus masters can access all bus slaves, so you will have to refer to the Connection Matrix to find out which connections are possible. For the C6457, this is Table 4-1:

    Regards,
    RandyP

  • Randy, thanks a lot for the soon and exaustive answer, it's exactly what I was looking for to be sure that there are not errorrs in our code

    br

    Roberto