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.

C6457 MMRAERR bit seems stuck

Hi,

I am working with the EDMA3 in the C6457 DSP on the TMDSEVM6457L evaluation kit.  I was having trouble with the EDMA3TC modules and was looking at the ERRSTAT register (address 0x02A20120) to learn about the problem.  Bit 3, the MMRAERR bit, always reads high on all TC modules, even immediately after a device reset.  On top of that, attempts to clear it by writing 0x00000008 to the ERRCLR register seemed to crash the peripheral without clearing the offending error bit.  The error bit never cleared, but after that write the Event Queue associated with that TC appeared to stall completely.  What is the expected behavior of that bit, and should I worry about a seemingly persistent error condition?

Thanks!

Zachary Clifford

  • Zachary, that seems odd indeed. I would expect it to show a '0' unless an access to invalid config space has been made. I will try to check on an EVM here. But are you able to successfully configure and run an EDMA example supplied with TI software?

  • Thanks for getting back with me.  I've done some more debugging, and the problem appears to have disappeared.  I am trying to use the McBSP as two independent half-duplex serial ports.  I was trying to use SPI mode, but it appears that SPI mode configures the McBSP as either Master or Slave, not both.  That may have been related, but for my application I can use the McBSP in its normal mode without issue.  The upshot is that the MEMERR bit problem appears to have cleared up while I was debugging.

    I tried running the TI McBSP + EDMA example, and it worked fine.  That example uses the CSL INTC module directly, so it required modification to use the Hwi module available in SYS/BIOS.  After making that modification, the demo only worked sometimes when other threads were operating.

    It did work when the buffers were 64-byte aligned and the transfer sizes were multiples of 32 bits.  In the end, I tracked it to a cache issue referenced in the errata for the C6457. Adding a CACHE_wbL2 call to the transmit buffer before use and a CACHE_invL2 call to the receive buffer before use cleared up the apparent alignment requirements.  It is possible that the real problem was that my SYS/BIOS skeleton project used the L2 cache while the TI demo code did not.

    At this point I can continuously stream data in and out of my DSP, and I hope the above explanation can help someone else stuck on this issue.

  • Zachary, good to know your project is up and running. We appreciate you posting your debug details here so that others can benefit from your work. Thanks again.