I've been investigating the DMA stall in the Delfino 28335 I posted on earlier today. I've been doing more investigating, and generated a workaround in my code that counts the stalls as well as ignores them, using a clock SWI that identifies the stall and gets the measurement process going again from where it left off. But, the underlying problem still remains between McBSP B and DMA Channel 2 on the Delfino, and all my observations point to a problem with the peripheral DMA service event being generated but ignored by the DMA logic. Anyone know how I put this report in TI's pipeline for errata investigation? I count a jam every minute or two, and this processor isn't that dang busy in my design. I know it isn't my code as the machine that reloads the DMA (the only code that fiddles with DMA registers) is inactive until the DMA completes, so there's no attempt at re-entrancy (and I've put a trap in to catch this, which remains untripped after a couple hours). The DMA machine registers indicate the transfer was only halfway through when the stall occurs, so there isn't an issue with the CPU interrupt processing logic. So, it looks like I've got a genuine processor bug here.
-
Ask a related question
What is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
