MSP432P401R: MSP432 with DMA and SPI

I haven't found an answer, and I've been looking for years. In that time I've only run across one SPI unit (from [Other Guys]) that recognizes the concept of an SPI "transaction". I've come up with some (rather baroque) schemes, but all have been "too hazardous to deploy".

The problem with a second DMA (or a timer) is coordinating the two. With a Tx-only application (like a DAC), keep in mind that the Tx DMA completes two byte-times before the transaction is done.

16 bits is somewhat of a special case. This SPI unit doesn't offer 16-bit "bytes" (-> 16-bit transactions), but it has 2 bytes of buffering on the Tx side, so if you're dynamically generating the signal you can use programmed-I/O to fill both bytes and let it write-behind after double-toggling /CS.

Sometimes there are tricks. Which DAC are you using? Typically with a DAC you want fixed-rate output so the MCU needs to pace the transactions somehow, e.g. timer and/or external "load" pin. Maybe you can piggyback on that mechanism?

But I don't want to be so gloomy. Maybe someone else has solved this?

Hello Bruce,

thanks for your reply! I am using a TI DAC8311 (the one on the BOOSTXL Audio). And yes, I want to have a fixed-rate output with 44.1 kHz. Maybe I could set up two DMA channels, which are both triggered by the same timer. One would transfer the data from RAM to SPI, and the other one would generate the CS by writing data to a GPIO port. But as you said, the problem is coordinate this whole process (making sure the CS is asserted before the first SPI bit).
Sadly the hardware STE-lines (when you operate in 4-wire SPI mode) only assert CS for single bytes. It would be much easier if there would be some kind of configuration register stating the amount of bits/bytes for a single SPI transaction. But there isn't ...

Rather than using a second DMA, I'd suggest using one of the CCR outputs of the timer itself (TA0.1, e.g.) for the /SYNC signal and another (TA0CCR2, e.g. -- pick from Data Sheet SLAS826G Table 6-36) to trigger the DMA. I think you need two CCRs to get the edge-senses (rising for DMA, falling for /SYNC) correct, but they can be set up to transition simultaneously with different OUTMODs.

One headache is that you want the DMA to trigger twice (two bytes) per output period, but /SYNC to only trigger once. I think there's a solution there by running the timer at twice the rate (halve the period) while using Toggle (OUTMOD=4) for /SYNC and one of the "normal" PWM modes (Set/Reset, e.g.) for the DMA trigger. You should probably work it out on paper before believing me, though.

This also plays a bit fast-and-loose with the TXIFG, but one of the nice things about SPI is that it's completely predictable -- start a byte, wait 8 bit times, and it's done.

Hello Alexey, good to hear that there is a solution for this problem. I have read most of slau356, but the DMA chapter is not as intuitive as I thought. That's the reason why I didn't use DMA so far. Do you have any good proposals for documents to study the ARM PL230, preferably with MSP432 examples?

Andreas,

Try to debug driverlib DMA samples provided by TI first. Then there are some TI examples utilizing DMA for real-time ADC data transfer.
Then try to change the DMA code according to your needs.

Regards,
Alexey

Andreas,
Hope that you will find these examples helpful:

dev.ti.com/.../

e2e.ti.com/.../2578528

Regards,
Chris

@Alexey & Chris: Very very helpful hints, thank you very much. I will post another reply when I have the PCM output working with DMA (together with a MP3 decoder [libmad], which is working already nicely with a interrupt-driven PCM output).

Just another short question: When writing to a OUT Register of some GPIO port, DMA works without problems.

When I try to write to the corresponding bit-band alias address, nothing happens. Is there anything special to consider when writing to bit-band areas via DMA?

Also CCS does not offer to change the bit-band areas manually. When I display the address 0x42000000 in the memory browser, no content is shown...

Andreas,
Thank you for the closure and feedback.

Chris