STM32 v.1. DMA Driver Error

[alexblack]

Hi.
In trunk now there are erros in STM32 v.1. Driver, file stm32_dma.c:

Code: Select all

302 #if defined(STM32_DMA2_CH1_HANDLER) || defined(__DOXYGEN__)
303 /**
304  * @brief   DMA2 stream 1 shared ISR.
305  *
306  * @isr
307  */
308 OSAL_IRQ_HANDLER(STM32_DMA2_CH1_HANDLER) {
309 
310   OSAL_IRQ_PROLOGUE();
311 
312   dmaServeInterrupt(DMA2, 1);
313 
314   OSAL_IRQ_EPILOGUE();
315 }
316 #endif
...

Error in line 312 "dmaServeInterrupt(DMA2, 1);" Second parameter is stream and must be 8, i.e. "dmaServeInterrupt(DMA2, 8);"

Same errors for all DMA2 irq handlers below...

[alexblack]

It seems it is not so trivial: dmaServeInterrupt must be corrected too.

[steved]

Are you using a recent SVN? There was a bug fix in this area (affecting dmaServeInterrupt()) recently

[Giovanni]

There is still a problem with indexes for DMA2, those starts from 8.

I am changing the macro to take the table pointer as parameter.

Giovanni

[alexblack]

Yes.

[Giovanni]

I committed the modified code but cannot test until tomorrow, could you give it a try?

Giovanni

[rew]

I'm having a little problem with DMAv1 as well....

A few days a go I verified that I was getting transaction complete callbacks. Today after lots of debugging my callback is NOT being called. The cause seems to lie in that there is no way in the code that enables the TCIE bit in the CCR.

Code: Select all

 
#define STM32_DMA_CCR_RESET_VALUE   0x00000000U
[...]
  dmastp->channel->CCR = STM32_DMA_CCR_RESET_VALUE;

When I define a function, the NVIC gets enabled for that vector, but when I add:

Code: Select all

  MYDMAL->channel->CCR |= STM32_DMA_CR_TCIE;

I suddenly get the increasing numbers in the callback counter. I have the impression that a few days ago I did verify the callback being activated, but now I can't find any code that would set the TCIE bit. (and git tells me the "enable" function (where I'd expect the bit to get set) hasn't been changed since my birthday.)

[Giovanni]

Hi,

Mode bits are not set in the DMA driver but passed to the dmaStreamSetMode() function from the driver/application, for example:

Code: Select all

  SPID1.rxdmamode = STM32_DMA_CR_CHSEL(SPI1_RX_DMA_CHANNEL) |
                    STM32_DMA_CR_PL(STM32_SPI_SPI1_DMA_PRIORITY) |
                    STM32_DMA_CR_DIR_P2M |
                    STM32_DMA_CR_TCIE |
                    STM32_DMA_CR_DMEIE |
                    STM32_DMA_CR_TEIE;
...
  dmaStreamSetMode(spip->dmarx, spip->rxdmamode);
  dmaStreamEnable(spip->dmarx);

The above code is taken from the SPI driver.

Giovanni

[rew]

Ah!! The SPI driver is where I look for inspiration as well.

OK, that explains how SPI and other drivers still work with this "bug"....

I would personally consider that TCIE bit one of those that are "handled by the driver". The driver also handles clearing that bit when I disable the channel.

To save time in the critical parts of my code I initialize as much as possible just once, and then just enable/disable the DMA channel. So I only call "dmaStreamSetMode ()" once at startup.

[Giovanni]

There are drivers that do not require DMA interrupts, see SDC for example, other that require also other DMA interrupts like the ADC, this is why it is handled externally.

Giovanni