|
Hi!
I have a problem while accesing the
6416DSK's memory with CCS or Matlab.
I'm transfering 32-bit words from EMIF to
an input pingpong-buffer via EDMA, then processing the data and copying it to an
output buffer from where it is transfered to the MCBSP2/AIC23 for audio output
(similar to the dsk_app demo project). All works fine, but when I open a memory
view window in CCS and hit refresh, the audio output gets corrupted. When I
click refresh some times more, the audio sounds a bit different corrupted after
every click, and finally it gets alright again. The same thing happens when I
access variables over the CCS Link Toolbox in Matlab.
The data in the buffers itself looks OK all the
time (controlled with graph view).
Should this be a problem with the RTDX to CCS
or Matlab, or rather with the combination of the RTDX access with
EDMA/MCBSP transfers??
Thanks,
Andreas
|
|
|
RTDX-EDMA-MCBSP conflict
Started by ●December 9, 2004
Reply by ●December 9, 20042004-12-09
|
Hi!
Found a solution on my own, I had to check
'real-time mode' in the debug menu :-)
Now it works great!
Andreas
|
Reply by ●December 9, 20042004-12-09
|
Andreas- > I have a problem while accesing the 6416DSK's memory with CCS or Matlab. > I'm transfering 32-bit words from EMIF to an input pingpong-buffer via EDMA, then > processing the data and copying it to an output buffer from where it is transfered > to the MCBSP2/AIC23 for audio output (similar to the dsk_app demo project). All > works fine, but when I open a memory view window in CCS and hit refresh, the audio > output gets corrupted. When I click refresh some times more, the audio sounds a bit > different corrupted after every click, and finally it gets alright again. The same > thing happens when I access variables over the CCS Link Toolbox in Matlab. > The data in the buffers itself looks OK all the time (controlled with graph view). > Should this be a problem with the RTDX to CCS or Matlab, or rather with the > combination of the RTDX access with EDMA/MCBSP transfers?? If you're not in Run-Free mode (in v2.2 CCS -- maybe that is equivalent of "Real-Time Mode" that you mentioned), almost any action in CCS causes at least some JTAG command interaction with the target. Whether it's a major JTAG action (transfer RTDX data) or just a small "are you there, how ya doing" check when you change the source code view, any JTAG action by CCS causes the processor to stop briefly. That can interfere with time-critical things such as audio DMA. In your case, my guess is AIC23 channel samples get swapped or mis-aligned on a word boundary. With the AIC23, there is no way to know which channel -- you take it out of reset and the words start coming. If you lose track, then channel 0 might be channel 1 etc. Have you noticed why Texas Inst talks about XDS560 solving the problem of "stop mode debugging"? Their marketing group sure did not use that term when the only available debuggers were XDS510-style. But that's exactly what happens: the processor stops to execute the JTAG commands. Some things can run in the background (see SOFT and FREE bits in McBSP setup) but not a lot. -Jeff |
