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.

C6748 / McASP / Won't Start Unless External AFSX Is Idle



Hello. I have an interesting problem that I cannot determine an answer. Does anyone know why this situation occurs? And whether there is a known method for handling it?

Here it is. First, I am using a C6748 DSP without OMAP; this is just the DSP. Second; I am using McASP0 as an interface to a CODEC. This is not terribly important, because what matters is the TDM interface, and all the CODEC is operating normally etc. I have successfully implemented the recommended startup logic provided by Texas Instruments in document SPRUFM1, the data sheet provided. I have also successfully operated the FIFO set in both directions, with internal loopback (DLB mode) as well as pin-to-pin loopback at all clock frequencies up to the maximum allowable. There are no issues there.

However, in my target application, an external clock (ACLKX) and an external frame sync (AFSX) are routed to the DSP. Note; in the above testing, with both DLB mode and pin-to-pin loopback, the DSP was "driving" both AFSX and ACLKX. In my application, the McASP will not clock data into the part ... unless ... AFSX is suppressed. The software successfully "prepares" (configures) the McASP all the way up to the enabling of the transmitter clock section, leaving the unreset of the state machines and frame sync subsystem to just prior to bus interrupt activity, as specified in the data sheet. Further, the software properly "pre-loads" the write FIFO with data for the bus, so that everything is staged and ready to clock out.

Ok. So what's the problem? The problem is ... AFSX is gated to the DSP at all times by the hardware. This pulse, when present during the unresetting of the state machines, apparently causes the state machines to throw a transmitter underrun fault. This is clearly seen in the start sequence by displaying the status register using the UART output. No emulator interrupting, or conditioning, is occurring. Installing a "gate" to "suppress" the AFSX pulse, and then having the software perform the unreset function, is just fine. In fact, the AFSX pulse can appear ANYWHERE in time after the unreset occurs ... minutes, microseconds, or hours later, and the bus will begin dumping (clocking) FIFO data to the serial shift register.

Nowhere in the TI supplied data sheet is there any requirement for AFSX to be suppressed prior to the unresetting of the state machine. Yet, this scenario is ultimately repeatable, with 100% reliability. AFSX can also be present AT ANY TIME prior to the unresetting operation of the state machine ... turning it off just prior to writing the unreset bit to the global control register works just as well. Then, turning it on afterwords and the bus is quite reliable.

So, I pose a question to the peripheral engineering staff for the McASP circuit peripheral. Is it a hardware/circuit requirement for the AFSX pulse to be absent from the bus (i.e. the bus be at logic 0 or logic 1 and stable with no pulses) ... during the transmitter state machine unreset operation?

And, if not, what am I doing wrong? And why isn't that requirement found in the data sheet? Or is it there in some way I'm not seeing it?