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.

MSP432 uDMA Clock Cycles

Other Parts Discussed in Thread: CC3200

I'm new to the MSP432, but not the MSP430 line of MCU's. I've recently started work using the uDMA on the MSP432 and I am, so far, extremely unimpressed with its speed. I understand that there is a latency with the FLASH operating at 48MHz, but should the uDMA -really- be taking 8 clock cycles to per transfer? The following code is my configuration:

    MAP_DMA_setChannelControl(DMA_CH0_TIMERA0CCR0 | UDMA_PRI_SELECT, UDMA_SIZE_16 | UDMA_SRC_INC_16 | UDMA_DST_INC_NONE | UDMA_ARB_1024);
    MAP_DMA_setChannelTransfer(DMA_CH0_TIMERA0CCR0 | UDMA_PRI_SELECT, UDMA_MODE_AUTO, DataTest, (void*)&P5OUT, 1024);


The data in DataTest is a uint16_t and is a simple increment counter... 0, 1, 2, 3, etc. By measuring P5.0, I am able to see it toggling at a rate of 8 clocks per toggle, as the LSb in DataTest[] changes every other value, thus causing P5.0 to toggle every DMA transfer.

Is this correct or is there something wrong with my DMA code or implementation?



  • Eight cycles per transfer matches what I observe during DMA to GPIO on MSP432. Under the same test conditions I get four cycles per transfer on CC3200, which uses a similar ARM uDMA.

    I'm wondering whether the fact that the MSP432 GPIO runs at MCLK/2 means that the DMA has to run at half-frequency for transfers involving GPIO.
  • Perhaps, I should run this on a different peripheral and hope that it will be 4 cycles, since it is similar architecture as the uDMA on the CC3200?
  • I think all the peripherals on MSP432 run at half the MCLK frequency. Also I can't think of another peripheral that would be able to consume/produce data as fast as the GPIO can.

    SRAM to SRAM transfers get close to 4 cycles on MSP432, but give an alternating pattern of 4/6/4/6. I haven't worked out what might cause those extra cycles yet.
  • Well, that's too bad...

    Ultimately, what I want to do is to be able to load the TA0CCR1-TA0CCR4 registers with updated values at a fairly precise time. I'm making a 16-bit DAC using 4 output pins in a R-2R-4R-8R setup, while each output pin is outputting a PWM signal from the TA0CCRn's. This way, it is like a hybrid DAC between a PWM and an R-2R network. The PWM's are essentially configured as 4-bit, and with 4 of these, I get 16-bits over all.

    The problem I'm running into is trying to load the CCR registers fast enough so that they don't glitch. Even if I get the DMA transfer to go faster, I think I will still need to turn the pins to tri-state, load the new CCR values, reset the timer back to zero, and then turn the pins back to outputs - every time I update the "DAC" with a new voltage value. Any thoughts on this?

**Attention** This is a public forum