SPI with DMA problem

The device errata sheet doesn't list a known bug for DMA or USCI. This doesn't mean there is none, especially since others have reported DMA problems with eUSCI too.

I can imagine that the problem happens when both, RX and TX interrupts, are triggered at the same time. (one while the other is executed). Unfortunately, since the exact cause is yet unknown, I cannot provide a solution other than only using one direction and perform one or even both transfers using software and interrupts.

Manfred Meerk��tter said:

the examples are using level trigger, but that makes it worse and the manual strongly recommends to use edge trigger.

Yes, level trigger is known to cause problems (except for the external DMA trigger) and shouldn't be used for internal modules. I don't know why your examples use level trigger.

You can experiment with round-robin DMA priority or other settings the DMA module offers. Maybe it helps, maybe not. Again, the cause isn't known so the cure can only be found by coincidence, if at all.

Thank you for your response.

I'm sure now that it is no problem with the MSP430 hardware. When I disable the interrupts and let the MSP do a __delay_cycles(60000); for the time it requires to send the packet over the SPI everything will work fine.

I tracked the problem down to the FreeRtos tick interrupt. It starts with __bic_SR_register_on_exit( SCG1 + SCG0 + OSCOFF + CPUOFF ); to enter normal working mode after the interrupt. if I remove this statement the DMA/SPI will work. Because I don't use any sleep mode in my program so far this line of code should only clear status flags, which are already cleared.

Any ideas ?

I encountered a similar symptom some years back on the F1611. I attributed it to having the Tx channel serviced first, allowing the Rx channel to overrun.

I avoided it by assuring that the Rx channel always has priority:  (a) Assign Rx the lower-numbered channel (b) Don't use ROUNDROBIN.