Part Number:OMAP-L138
Hello all,
I'm using the OMAP-L138 with the C674x DSP. McBSP interfaces to the EDMA through a FIFO. Under normal operation my application is working fine and it will frequently stop and start the EDMA and McBSP. The serial port is configured to use an external FSX and CLKX. The lockup appears to always happen once the serial port is started, not in the middle of operation, so the failure could occur in the shutting down of the serial port previously or the re-initialization and startup of when the failure occurred.
In order to get the lockup to occur much more regularly, I have provided an excessively noisy clock to the McBSP and observe the same symptoms to the original lockup (described below). I have had problems with the device that is providing the clocks to be unreliable at times (I have had issues in the past with the clocks disappearing). I understand that having a bad clock is a cause for problems, but I guess I would like to know more specifically about how this problem occurs and what the symptoms can be. The device providing the clocks is 3rd party, so it is essentially another black box for me.
After a lockup has occurred I've investigated the registers to get some idea of what might be going wrong. The EDMA has no Interrupt Pending (IPR) for the McBSP Tx event, EMR and SER are both clear. The EDMA is pointing at the 65th element, which is the next element to be loaded into the FIFO, this is somewhere in the middle of the EDMA paramset. The FIFO appears to be full (length 64). The Mcbsp0DSP.SPCR is 0x02032007 (the McBSP receiver is in use and still functioning) which shows:
- XRDY is '1-YES'
- XEMPTY is '0-YES'
- XRST is enabled
- XSYNCERR is '0-NO'.
- XINTM is '00-XRDY'
I read this as meaning the McBSP believes it has sent DXR (which has been set to the first element the EDMA transferred) since it believes it is empty and ready for new data in DXR. As an experiment in my emulator I toggled XRST to disable and re-enable the McBSP. I saw DXR update to my expected element #2, XRDY and XEMPTY were in the same state as above. The FIFO remained full and the EDMA had incremented one position to point to the 66th element. The serial port still remained locked on [now] the 2nd element. It appears like the entire "chain" is still working, so I suspect the problem does not lie in the EDMA or FIFO. I have also physically monitored the DXR pin for activity and see no activity (constant zero). Even after toggling XRST I see no activity on the DXR pin (not even a single transfer) even though I would expect the McBSP to constantly transfer the contents of DXR even when it thinks it has underflow (FREE = '1 - ENABLE').
So the second part of this post is I am looking for a way to recover from this condition. Performing a soft reset (reloading C674x code) does not recover, the next time I start the serial port the same symptoms exist. This restarting of the DSP application follows the McBSP initialization procedure from the User's Guide very closely. The only way I have found to recover is by powering the entire module off with a hard reset. I have attempted to use the PSC to disable and re-enable the McBSP0 after getting in this condition, but no matter what state I try to transition to, PSTAT remains '1 - IN TRANSITION' as if it is not receiving any sort of communication from the McBSP0. Then if I attempt to read any McBSP0 registers, my core hangs and debugging terminates and the only recovery is again the hard power down reset.
So I'm looking for answers to 2 questions:
1) What exactly is locked up and how does it get into this state?
2) Is there any sort of recovery mechanism besides powering off the module?
Thanks for your time,
Marshall