6457 CSL and MCBSP documentation disagreement

So, no answer to this and no suggestion of who to contact that might know more?

Normally, I would suspect that the CSL is correct if it is used to make the device operate a certain way. But in this case, the documentation was specifically changed from prior devices, like the C6455 which does use 00 to drive X/RINT from X/RRDY. Someone went to the effort to change the documentation to make the value 00 be reserved because they do not want you to use this value.

I do not have the C6457 CSL on my PC, so I will ask you: Is the value 00 just in the header comments (or even header constants) or is it actually used in an example that generates interrupts? I ask this because the CSL probably started from a previous device, like the C6455, and was modified as needed to apply to the C6457.

And to add to the confusion, as I searched through the McBSP UG for RINT and RINTM, there are other implications that RINT can be triggered on RRDY=1. But I still go with the theory that those confusing places are also residuals from previous documents.

My advice is to assume the User's Guide is correct and do not use X/RINTM=00b. If you insist on getting an interrupt for every X/RRDY event, route it through the EDMA3 with a DUMMY DMA channel to generate your interrupt through the EDMA3's interrupt output.

The EDMA3 is really a better place to handle X/RRDY events anyway. No DSP involvement until a set of data has been accessed, like a frame or page or payload or whatever. That is what the EDMA3 is there for and what it does very well.

Brady,

We are looking into which of these is correct.  That said, Randy's suggestion that it's likely the CSL documentation being carried over from previous CSL version is highly likely.  The CSL for PCI on C6457 was ported from C6455, and there were minor changes to the PCI interface and this functionality may have been removed and documented in the UG, but unintentionally left in the CSL documentation.  For now I'd suggest following Randy's suggestion on how to implement this, at least until we've reconciled the concern.

Randy,

Thanks for replying to this and providing an alternative method to use while this is being resolved.

Best Regards,

Chad

Randy,

Here is the chunk of code from csl_mcbsp.h:
 

typedef enum {
    /** Interrupt generated on RRDY of RCV or XRDY of XMT */
    CSL_MCBSP_INTMODE_ON_READY         =                  0,
    /** Interrupt generated on end of 16-channel block transfer
     *  in multichannel mode */
    CSL_MCBSP_INTMODE_ON_EOB           =                  1,
    /** Interrupt generated on frame sync */
    CSL_MCBSP_INTMODE_ON_FSYNC         =                  2,
    /** Interrupt generated on synchronisation error */
    CSL_MCBSP_INTMODE_ON_SYNCERR       =                  3
} CSL_McbspIntMode;


I have not seen it actually used in an example, and I am using EDMA as you suggest;
I just wanted to point out and hopefully resolve this discrepancy.  Thanks for your answer.

-Brady

edit:  some formatting problem, and the html editor is not working (404 when I click the button...)

EDIT: Reformated for forum visibility - Chad Courtney