• Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 279 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

L137 McASP Emulation Control

Joseph Woodward
Prodigy 210 points
Other Parts Discussed in Thread: OMAP-L137

I know this isn't really an L137-specific questions, but is it possible to halt the McASP (via emualtion control/Code Composer)???

I in the process of porting and updating some old code from a C64xx platform to the L137.

Previously we used the McBSP as our serial data pump, but as one doesn't exist on the L137 we are now using the McASP (the received data stream is basically two 24-bit data words per frame sync, so the McASP in TDM mode is ideal for this).

This data is moved from the McASP using the EDMA3 to alternating buffers in L2 (a ping-pong transfer), with an interrupt after each complete block to signal to the DSP to start processing.

This seems to work, but the problems come when trying to debug. Previously the McBSP would halt during an emulation stop, however it appears the McASP (and hence the DMAs) do not.

This causes problems, as the data I am trying to inspect and debug gets overwritten (by the DMA which also does not stop) before I get chance to see it!

Is there a simply solution to this problem? Can the McASP be halted?

Thanks,

Joe Woodward

  • TI__Mastermind 41665 points

    The McASP in the OMAP-L137 does not support the emulation suspend signal so it will continue to run when CCS is connected (there are a couple of warnings about this in the McASP manual), unfortunately it does not look like this can be toggled with the OMAP-L137, in the case of other peripherals there is a SUSPSRC register that controls emulation response on various peripherals but McASP is not one of them.

    This being said you may have to modify your EDMA configurations to debug, such that they write into a larger continuous buffer instead of overwriting data, this may or may not be something you could practically do in your system though. What sort of issues are you trying to debug at this point, perhaps we could go from that angle?

  • in reply to Bernie Thompson TI
    Prodigy 210 points

    Thanks for the reply.

    I've worked around the issue, and this has given me enough information for debugging.

    Basically, I've altered the task that deals with processing a block of data log a copy of the data to a large secondary buffer in external RAM (fortunately I have enough processing time between blocks and spare memory to do this, and this is fairly unintrusive (after playing with the priority levels and assuming that writes to external RAM are non-blocking and hence cheap!)).

    As this buffer is large (several orders of magnitude larger than the internal DMA buffer) it means that the data is not overwritten by the point I manage to manually pause the DMA, and hence I can debug!

    The application is a software radio, with a data stream of continuous I/Q samples. We want to avoid having very large DMA buffers, as this adds unnecessary latency the system (and latency is important for the intended application). Thus the DMA buffers have been sized to be as small as possible without incurring a ridiculous overhead from the set-up/tear-down costs of the algorithms used and the time taken to context switch to deal with the interrupts launched by the EDMA.