C67+ dMAX and McASP issue.

Steve, just to confirm, you don't see the channel swap happening if you dont halt the system. Correct?
Also, have you tried reducing the number of serializers or channels to see if the problem goes away? What i'm trying to understand is if the issue is just a byproduct of emulation handling interfering with the ability of dMAX to service McASP

Cheers,
Gagan 

Gagan,  actually, I think the channel shift problem is related not servicing dMAX interrupt in time.   It is easily duplcatible with emulation halt, such as animate on a breakpoint.  We have a few products with different number of serializers and all exhibit this problem.

Regards,

Steve

Steve, I understand. So what is your expectation? If the dMAX interrupt is not serviced, it will be difficult to guarantee the correct behavior of the system

Cheers,

Gagan

Gagan,  our dMAX has two ping pong buffers.  When dMAX interrupt occurs (dMAX transfer completion, TCC), it reloads an alternate buffer.   It keeps writing data to buffer PING, buffer PONG, buffer PING, buffer PONG continuously.   Our dMAX ISR (interrupt service routine) is to take a fresh buffer and process the data.

When dMAX interrupt not serviced (or serviced late), dMAX will over write a unprocessed data in the memory (no hardware error).  But it should not shift channel data WITHIN a buffer.

Thank you.

Steve

Steve, I understand. Let me check on the impact to dMAX behavior when breakpoint is put.

Cheers,
Gagan

Steve,

Agree that McASP & dMAX should continue streaming when the CPU is halted. 

Can you check to see if this happens when you only use one serializer in the same TDM mode?

Steve,

When you hit a breakpoint do you have any memory or register windows open to the McASP registers?  If so, the act of refreshing the register/memory window will cause you to lose a single sample worth of data which might explain your channel rotation.

Brad

Brad,

Please elaborate.

1)   I halt DSP and see dMAX and McASP is continuously running by filling the DMA buffers.  Then I opened McASP register window and refresh it.  I could not get the channels to rotate.

2)  Do you mean that if I don't have any memory or register windows open, there will be no channel rotation?

3)  Is this a known problem of CCS 3.3 debug breakpoints?

4)  Is it a dMAX problem or McASP problem?

Thank you.

Steve

SGQ said:

Please elaborate.

The following note appears in the McASP Guide twice:

The C672x DSP does not support the emulation suspend signal. Therefore, if a

data window is open in the Code Composer Studio™ integrated development

environment to observe the XRBUF locations, the emulation read from the

XRBUF locations causes an undesirable side effect of clearing the RDATA bit

in RSTAT. Furthermore, if you write to the XRBUF through the Code Composer

Studio™ integrated development environment, the emulation write to the

XRBUF locations causes the XDATA bit in XSTAT to be cleared.

SGQ said:

1)   I halt DSP and see dMAX and McASP is continuously running by filling the DMA buffers.  Then I opened McASP register window and refresh it.  I could not get the channels to rotate.

Ok, this might not be the issue, but it's something to pay attention to, i.e. what memory ranges you are opening while you're halted.

SGQ said:

2)  Do you mean that if I don't have any memory or register windows open, there will be no channel rotation?

That's taking it further than I intended, but it sounds like a good experiment.  Does the rotation go away if you don't have any windows open?  Ultimately I was just intending that you should not open debug windows TO THE MCASP REGISTERS.

SGQ said:

3)  Is this a known problem of CCS 3.3 debug breakpoints?

It is the intended design of the device as documented in the McASP Guide.

SGQ said:

4)  Is it a dMAX problem or McASP problem?

It affects every peripheral in the device.

Brad,

Thanks for the reply.  But I don't think that is the cause of our channel rotation, at least we don't have evidence of it yet.

1)  If I don't have any memory/register windows open, I still get channel rotation.

2)  If the channel rotation is caused by emulation read the data port of McASP,  then McASP status registers should show error.  There was no errors.

What else could cause the channel rotate?

Thank you.

Steve

SGQ said:

1)  If I don't have any memory/register windows open, I still get channel rotation.

Ok, the memory windows probably are not the issue.

SGQ said:

What else could cause the channel rotate?

I think you need to do some further testing to try and isolate the issue.  For example:

• Could it be somehow related to not servicing the ISR for a period of time?  You could test this theory by writing some code that disables interrupts, spins for a few seconds, and then enables interrupts again.  See if that code will cause any channel rotation to occur.
• Could it be somehow caused by some physical coupling between the JTAG and the McASP interface?  You could check this by putting an oscilloscope on the data interface and triggering off one of the JTAG signals like TDI.  Make sure there's nothing odd going on like a dip in the voltage level, noise on the signals, etc.

Can you elaborate further on the issue?  For example, how often do you see the issue?  50% of the time when you halt the processor, or is it more rare or more common?  Do you always see the exact same behavior (Channel 1 appearing on Channel 17) or do you see different behavior?  Approximately what percent of the time do you see each behavior?  Is the McASP the audio master or slave?  Are you able to try it the other way around?

[quote Brad]: "Could it be somehow related to not servicing the ISR for a period of time?  You could test this theory by writing some code that disables interrupts, spins for a few seconds, and then enables interrupts again.  See if that code will cause any channel rotation to occur."

Regarding the servicing dMAX ISR,  I observe the following case.  When I stop the processor using emulation halt,  dMAX and McASP are still running by writing audio data to memory continuously.   I don't see my audio channels not shifted.   During emulation halt, dMAX ISR is not serviced.    This tells us that delay or not servicing ISR do not cause channel shifts.

[quote Brad]: "how often do you see the issue?  50% of the time when you halt the processor, "   

About %10 of the time.

[quote Brad]: "Do you always see the exact same behavior (Channel 1 appearing on Channel 17) or do you see different behavior?"   

When channel shifting occur, it is always channel 1 appearing on channel 17.

[quote Brad]: "Is the McASP the audio master or slave?" 

Master.

[quote Brad]: "Are you able to try it the other way around?" 

No..

SGQ said:

When channel shifting occur, it is always channel 1 appearing on channel 17.

Can you provide more detail on your channel arrangement?  You have 4 serializers and 32 channels, but how are the channels arranged.  Does the first serializer have channels 0-7 or does it have 0, 4, 8, 12, ...?

To unscrable the channel mapping:  Channel 0 data rotates to channel 28, channel 1 to 0, and everything shifted up by one.

We have 4 serializers and each has 8 TDM slots, totaling 32 channels.  Serializer 0 has first 8 channels, serializer 1 has next 8 channels and so on.  All audio data are aligned in memory from channel 0, 1, 2..... 31, each channel has 96 samples which represent 2ms of audio.

The following tables has rows as serializer, columns as TDM slots and elements are channel numbers.  They consist of two frames in each table.  The first table has the start up condition when running correctly.  The second table represents data after channel rotate.   We lost one TDM slot 7 .

We did some further testing and concluded that the channel can rotate without emulator plugged in.  We can duplicate channel rotation by overload DSP processing.  When DSP is overloaded, dMAX and McASP should still run as is.  We have two ping pong buffer set up as dMAX reload0 and reload1.

I feel this is cause by McASP missing an events to dMAX.  But can not think of how.   My gola is to first detect the channel rotation and then to correct it.

Thank you.

Regards,

Steve

Steve,

The only thing that comes to mind that could make the dMAX miss real-time would be a conflict in the interconnect.  For reference please see section 2.6 "High Performance Crossbar Switch" in the data sheet.

In that diagram notice that the McASP has two ports, one connecting to the peripheral config bus and the other connecting to the McASP DMA Bus. 

• How have you configured the RBUSEL bit?
• What address did you program into the dMAX in order to read the data? 

In particular, if RBUSEL=1 and you are using the peripheral config bus then I think the possibility of conflict will be much higher.  Put another way, the DMA bus is accessed only by the DMA so there's no chance for a port conflict at the McASP when the dMAX uses the DMA bus (RBUSEL=0).

There's also a chance for conflict on the memory side.  Are you placing the buffers in internal or external memory?  Have you tried switching it to see if the behavior changes?

Brad

Brad,

How have you configured the RBUSEL bit?

[Steve's reply]:   Set to 0.   McASP is only accessed by dMAX.

What address did you program into the dMAX in order to read the data?

[Steve's reply]:  0x5400 0000.

I have found the problem and resolved the issue.

Thank you very much.

Regards,

Steve

SGQ said:

I have found the problem and resolved the issue.

So what was it?!

That was due to my manipulation of the PP bit in Transfer Entry.  Without touch that bit, channel doesn't rotate.

I'm glad it's resolved!  Thanks for sharing the root cause with the rest of the community.

Is it a known issue with TMS320C6726B?