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.

peripheral/configuration area fetch error during DMA

Other Parts Discussed in Thread: MSP430F5438A

I am using the MSP430F5438a.  I am writing to a fast (60Mhz) SPI peripheral using DMA.  The code works fine at 15MHz.  At 20MHz, a peripheral/configuration area fetch reset occurs just after DMA starts.  I know I cannot read the peripheral above 15MHz due to data set up time required on the SPI recieve data but I hoped I could write to it.  So I first tried to switch the mclock divisor in SPI UCBxBRW register.  At 15Mhz all works fine with the divisor set to 0 (this seems to mean 1 as well) or 1).  When I go to 20Mhz, I seem to be able to do non dma operations just fine with divisor set to 2.  When I try to do DMA and even with divisor set to 2, I will get a reset with 0x001E in the SYSRSTIV.  This does not always happen but does with very high regularity.

To recap

1) code works fine at 15 MHz and using either 0,1 or 2 in UCBxBRW

2) affect of divisor can be seen on scope so it is working

3) at 20Mhz it works only vary rarely but sometimes will work once.

4) I get a peripheral/configuration area fetch error and it appears to be happening during the DMA

Anyone got any ideas.  Am I stuck at 15Mhz if I want to do DMA??  Is there a clock speed limit for DMA (if so I have not found it)

 

Thanks

Charlie

  • What silicon type is your 5438A?

    The ones produced in 2010 did have a problem with the flash prefetch cache (teh flash itself is 32 bit and there is a 32->16 bit cache/converter).

    If the cach wasn't accessed for some time, it did malfunction, reporting MSB wrong on the first read after a pause.

    If your DMA stops the CPU for a longer time and moves from RAM to output wihtout touching flash, it is possible that the first thing that happens after DMA end is that the DMA interrupt vector is read (wrongly). Or that the next CPU instruction is read wrongly form flash, causing the CPU to jump into the wild.
    Normally, this erratum usually affects waking up from LPM, but extended DMA could trigger it as well, or executing code from ram.

    However, the higher MCLK frequency should normally shorten the time until DMA is done. Which should relax things. But that's the only thing that came in mind...

**Attention** This is a public forum