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.

MSP430 flash controller blocking the DMA

Other Parts Discussed in Thread: MSP430F47173

Hi,

We have a device using the MSP430F47173 microcontroller. We're using the SD16A together with the DMA module to write samples into a buffer in RAM. We currently see a problem where after we do a flash write the DMA stops issuing interrupts.  Has anyone else experienced this kind of problem before? Is there any possibility of the flash controller conflicting with/blocking the DMA controller?

We're using the DMA channels with repeated single transfer, src and dst address incrementing. The DMA buffer in RAM is 128 bytes long.

Thanks for any suggestions.

Alex.

  • While a flash write is in progress, no interrupts may be serverd (GIE must be clear). During a flash write, flash is unavailable. This includes the interrutp vector table. Any read attempt to flash results in 0x3fff returned from the flash controller. Which is "JMP$" if fetched as instruction (the CPU  "jumps on place") but if the CPu tries to fetch an interrupt vector to serve an interrupt, 0x3fff is read as address of the ISR - which it is likely not. And the CPU executes code 'somewhere'. And since callign an ISR implicitely clears GIE, no futher interrupts cna be handled until GIE is set again - which it probably never does, depending on where the CPU 'runs wild'.

  • Yes, the interrupts are not stopped during the time we write into flash, but the strange thing is that just the DMA controller gets affected by this. The device doesn't block or anything as it would happen if it were to execute code from 0x3fff instead of the classic ISR.

    Thank you for your help!

  • I just checked the errata sheet and on this MSP, there is no erratum listed for DMA and FLASH.

    However, on other MSPs there are errata saying that DMA shouldn't be used during flash operation. In addition to not having interrupts enbaled during flash operation.

    Alexandru Stefan said:
    The device doesn't block or anything as it would happen if it were to execute code from 0x3fff instead of the classic ISR.

    Well, crashing is not a 'must' in this case.

    Depending on what code is found 0x 0x3ffe, teh device may just jump there and continue working - with some garbage on the stack. Like an iteration that never returns.

**Attention** This is a public forum