Hi all,
Do you know a probrem on DMA module of MSP430FR5739?
This probrem was described on
http://e2e.ti.com/support/microcontrollers/msp430/f/166/p/222669/864227.aspx#864227
and announced as Errata DMA9 of FR5739.
This errata is described as a probrem to transfer data to and from eUSCI UART.
As a comment by John Chinnick, all devices including eUSCI may have same probrem.
We met similer probrem on eUSCI SPI of MSP430F67791.
When we ware testing eUSCIA0 SPI loop-back test, DMA channels often stop and DMA channels are hang uped.
Settings are as follows:
Memory -> DMA1 -> SPI ->(loopback)-> SPI -> DMA0 -> Memory
64 bytes transfer with SPI trigger
MCLK = 22MHz
SPI = 5MHz
Disabling interrupt service and usxing flag check as
// Check Rx Int Flag
while(DMA_getInterruptStatus(DMA_BASE, DMA_CHANNEL_0)
== DMA_INTINACTIVE) { // Rx Int
In most cases, tranfer was stoped after DMA transfered about 4 to 10 bytes.
We checked DMA0SZ and DMA1SZ to count real transfer size.
Send data size and recieved data size was often different.
At first, we guessed clock was too fast.
Then we tried many patterns of MCLK and SPI clock.
This probrem was not depended to the clock speed.
We found this probrem was depended to the setting of Prescaler!
I don't know why!
At least, when MCLK=1MHz and UCA0BRW=0x05, DMA was stalled.
We can not meet this stall when UCA0BRW=0.
This probrem means eUSCI SPI module MUST use same speed as MCLK.
Right? Is there the another reason?
Or DMA may be stalled in this condition CA0BRW=0?
Anyone knows what is happened?
And we need completely proper workaround.
The best is never use DMA, I know;-)
If you met some similer probrems, please tell me your experience.
I suppose the workaround of DMA9 is insufficient.
Because another ISR for example Timer, WDT and ADC may causes the DMA stall.
CPU will wake up asynchronously to DMA transfer.
I hope TI members redesign the die and improve the DMA and eUSCI to remove these difficulties immediately.
Thank you!