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.

Workaround for DMA4 bug

Other Parts Discussed in Thread: MSP430F2618

Hi,

in current projects we use the DMA subsystem on a MSP430F2618. We have assigned one DMA channel for the ADC12 and two channels for external communication with USCI.

I have a question to the DMA4 issue reported in the device erratasheet http://www.ti.com/litv/pdf/slaz033j :

"When a 20-bit wide write to a DMA address register (DMAxSA or DMAxDA) is interrupted by a DMA transfer, the register contents may be unpredictable."

One workaround proposed is to temporarily disable all active DMA channels (DMAEN = 0).  Our software specification provides different drivers and encapsulates the different subsystems. According to our specification the ADC module is not allowed to enable/disable the USCI DMA and vice versa. So this approach is not useful.

Another workaround proposed is to use a Read Modify Write disable bit (DMARMWDIS = 1), but this one doesn't exist on the MSP430F2618 DMA register set.

The DMA Control Register 1 (DMACTL1) provides a DMAONFETCH bit. If this one is set, the DMA transfer occurs on next instruction fetch after the trigger. Does this one ensure that the error does not occur and a 20-bit wide write to a DMA address register isn't interrupted?

Regards

Christian

 

  • Hi Christian,

    Yes, DMAONFETCH = 1 will ensure that a DMA transfer will not interrupt a 20-bit wide write.

    Alternatively, you can just do a 16-bit word write to DMAxSA and DMAxDA, and the upper bits will automatically receive zero.  That's probably what you want anyway.  No need for a 20-bit write operation at all.  (Edit:  as in, "DMA0SAL = xyz;"  or  "DMA0DAL = xyz;"   or however your tools define the low word of those 20-bit registers.)

    Jeff

**Attention** This is a public forum