This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Need help on Periph_to_mem DMA transfer started from an interrupt

Good evening all,

I need advice on the following problem.

I have to connect an external hardware generating 32-bit values at a continuous rate of 1536 kHz to a GPIO port of a Cortex M4F CPU.

I had thought to use the DMA to fill a 512-entry buffer, in double buffered mode, alerting the CPU when one of the two flip-flop buffers is filled. This seems to not present problems.

What I am not sure is how to communicate to the DMA controller that a new sample is ready on the GPIO port. First of all, can the DMA be used this way ? IOW, can it be controlled by an EXTI interrupt generated by a pin of a GPIO port (of course not the same port where the samples are arriving from).

To summarize, the flow should be this :

- A new sample is set on the pins of a GPIO port.
- A pin of another port is toggled to tell to the DMA controller to read that value and to deposit it in memory, incrementing the memory address.
- When the count of samples reaches 512, a buffer switch happens, and an interrupt is generated to the CPU, which will then process the just filled buffer.

A snippet of code on how to initialize the NVIC and the DMA controllers would be much appreciated, thanks.

Parents
  • Well, I've checked Freescale K60's manual and it seems that your requirements could be matched. I don't know which M4F you choose but you can read its manual for sure.

    Take K60 for example, you should notice:

    1. Only DMA Channel 0~3 supports PIT triggers. You could configure PIT to trigger DMA from GPIO to buffer @1536kHz.

    2. You'd better choose a specific oscillator, whose frequency be multiple of 1536kHz.

    3. Double 512 buffer switching, that sounds a perfect Ping-Pong workmode. You can find similar samples from your chip vendor.

    4. BTW, is it a 480*320 digital camera?

Reply
  • Well, I've checked Freescale K60's manual and it seems that your requirements could be matched. I don't know which M4F you choose but you can read its manual for sure.

    Take K60 for example, you should notice:

    1. Only DMA Channel 0~3 supports PIT triggers. You could configure PIT to trigger DMA from GPIO to buffer @1536kHz.

    2. You'd better choose a specific oscillator, whose frequency be multiple of 1536kHz.

    3. Double 512 buffer switching, that sounds a perfect Ping-Pong workmode. You can find similar samples from your chip vendor.

    4. BTW, is it a 480*320 digital camera?

Children
  • Jack,

    thanks for checking. I don't know how similar or dissimilar is the Freescale K60 from the STM32F4, but it is reassuring to know that that possibility exist, at least in that case.

    About the oscillator, the final board will have the STM32F407VTG clocked by the same master clock of the RF portion, so everything will be synchronous. The prototype I am developing will have to rely on the 168 MHz of the Discovery board, but in any case the "heart beat" will be given by the external toggling of the GPIO pin, which belongs to the clock domain of the RF part.

    The double 512 buffer switch works perfectly, I have already used it coding the DAC driving portion of this project, and expect no problems from this.

    No, it is not a 480*320 digital camera... it is an RF acquisition product, with a couple of 14-bit ADCs that sample at 72+ MHz, and a FPGA with a DDC (Digital Down Converter) coded in it, that, using a Cordic and a series of CIC and decimators, performs a downconversion and a downsampling of a portion of the band sampled by the ADCs.

    The DSP part does not bother me, it is just this DMA stuff that makes me unsure on how to proceed. My experience of the ARM architecture is very scant...

  • The ARM architecture is basically a processor core and for some chip generations an interrupt controller and memory controllers. Most other parts of an ARM chip is a mix of different blocks that the chip manufacturer have bought from ARM, or developed themselves for that chip, or lifted from some older generation chip they have.

    So it really is important to focus on the specific chip family that you are going to use. Other families from the same manufacturer, or chips from other manufacturer, can be totally different.