Hi,
I have a few McASP questions...
Before I get in to that I should give some background (as it always helps)!
The receive data stream:
- We are only concerned with receive (hence operate in ASYNC mode with Tx completely disabled).
- The data stream consists of two 24-bit words (back to back) per frame sync.
- Both the bit clock and frame sync are externally generated.
- The data should be latched on the falling edge of the bit clock, and the frame sync is active high.
- There is a 1-bit delay between the frame sync and first data bit.
- The bit clock runs has a frequency of 25 MHz.
- The frame sync has a frequency of ~128.2 KHz.
- This gives a bit rate of ~6.1Mbps (128.2 KHz * 2 * 24-bits, giving approx ~25% utilisation).
Therefore:
- This data stream is not really TDM as the frames are seperated by gaps in the bit stream (i.e. when one frame ends there is a gap before the next begins).
- This data stream is also not BURST as there are 2 words per frame sync (giving a total of 48-bits of data per frame sync).
Previously we have used the McBSP (on a 64xx) for this task (using a 1 phase transfer containing two 24-bit words), and this works perfectly.
We are now in the process of moving to the low power OMAP architecture. As the L137 was the first available device in this it seemed a suitable candidate for further investigation, and even though there are no McBSPs it was thought that the McASP could do the job!
However, it seems not...
Fudging the McASP in to TDM mode with 2 slots of 24-bits and an external bit clock and frame sync works (most of the time).
BUT... after a few minutes it appears the the McASP's Rx state machine locks up.
I can view the external pins directly (via the GPIO registers) and the frame syncs, bit clock and data are still being generated (this has also been confirmed via scope probes).
I can restart the transfer by simply reseting the Rx state machine (setting and clearing GBLCTL.RSMRST).
However, there are no status bits to indicate that this situation has occured (the clock-failure and sync-error are useless, and no other error conditions are ever set).
So, some questions...
It appears that the clock-failure circuitry (accessed via RCLKCHK for the receive side) only works either from the internally generated bit clock or the high frequency master external clock (AHCLKR), but not the normal external bit clock (ACLKR).
Is this correct? What is the logic for not allowing the clock-failure circuitry to work from ACLKR?
Is it recommended to always route the bit clock through AHCLKR and then divide by 1 (rather than using ACLKR) as this gives access to the clock-failure circuitry?
And the main question is... is what I am trying to use the McASP for even possible (as obviously the McBSP is designed for this task)???
Thanks,
Joe Woodward
