MSP430F67xx errata DMA9

Which MSP are you exactly talking about?

In the specific 6736 errata sheet is no trace of DMA9. (during the last years, the more common sub-family errata sheets have been replaced with individual errata sheets for single devices)

So maybe you have a version of a more generic errata sheet which is obsolete already and won't be updated anymore.

Sorry.

MSP430F67691 Device Errata sheet

SLAZ509H–January 2013–Revised May 2014

I see. This is 67xx1 sub-family. (and there’s even 67xx1A sub-family)

Yes, the erratum is there and has been discussed here in the forum for some time. Since you still can use USCIB for high-speed SPI with DMA, it isn’t as bad as it looks at first. (I’m using SPI and I2C on the same USCI simultaneously): For UART, you usually have enough time to handle the transfer with IRQ. But I agree that it is a nasty one and should be fixed.

Well, I can’t say when this will happen. And except a very few exceptions, TI will likely not release premature information about when something will be fixed or not. Like most other companies I know. The only big exception here is Microsoft: they announce things where development has not even started, just to bind customers and prevent them from buying from a competitor.

BTW: a suggested workaround was to use DMALEVEL to trigger a transfer as long as the interrupt is there (not edge triggered). Since the interrupt is cleared on the transfer, this might work. But I don’t remember what the outcome was. You may try and test :)

Unfortunately, It fails with and without DMALEVEL.

Well, then I don’t have an idea. Unfortunately, it affects RX as well as TX, or else you could (depending on SPI mode phase) the other one for a trigger (and do two DMA transfers) with proper priority order. But as it seems, there is really no workaround for UART and the only workaround for SPI is using USCIB.