Best Practice for manging DMA conflicts?

[stevestevesteve]

Hello,

I'm working on porting a large project that uses some peripherals that share DMA channels. In our old code (no OS), we used interrupts for everything (no DMA). This is on an STM32F417.

Currently I am trying to get some code working that uses USART2 and I2C1 (but there will be others). In another thread it was adviced to work around DMA conflicts by disabling the driver. However, I noticed that if I disable the serial driver before the entire message is sent (like in the following snippet), the message is truncated (I assume this is because sdStop clears the DMA registers?).

Code: Select all

msg_t usart_write(SerialDriver * usart, char *ptr, int len) {
  sdStart(usart,&config);
  msg_t ret = sdWrite(usart, (uint8_t*)ptr, len);
  sdStop(usart);
  return ret;
}

Adding a sleep before the sdStop fixes the problem, but this is not acceptable for performance reasons. In fact it is much worse than our current interrupt-based solution. Are there workarounds possible? Or did I misunderstand something?

Right now it seems like the best option is just to write some (interrupt based, not using the DMA) drivers when a conflict can't be resolved by changing channel config.

[steved]

I believe some limited reassignment of DMA channels is possible on the F4 series.

For the UARTS, a driver with an interrupt-driven option is available in this thread - as my solution to the DMA conflict on a 32F0. Looks like the F4 has a different UART driver, but it may help if you need to go that way.

[Giovanni]

Note that The serial driver (sdXXX functions) does not use DMAs, the UART driver uses the DMA. You don't need that sdStop().

Giovanni

[stevestevesteve]

Ah great, thank you. I must have misunderstood.