Я правильно понял, что DMA одновременно для USART1 и SPI2 нельзя использовать?

Да, в даташите написано что и для уарт1 и для спи2 используются каналы 4 и 5, те одновременно заюзать их видимо не получится. Во всех примерах дма все каналы используются согласно даташиту.

Кроме этого есть ещё одна проблема, ДМА на СПИ2 работает коряво, workaround есть в сэмпле MassStorage на сайте олимекса к их отладочной плате, P103 вроде.

А можно чуть подробнее об этом?

ммм... я немного ошибся, ДМА везде работает немного коряво)

// DMA transfer corruption errata
// Description
// Data corruption occurs when the CPU executes a write access to the APB bus while the
// DMA is also performing a write access on the same APB bus.
// However, the DMA transfer is not corrupted when the CPU performs a read access to the
// APB bus. Additionally, no data corruption occurs during multi DMA transfers on the same
// APB bus without CPU write access on this APB bus.
// Workaround
// 1. Ensure that your application does not execute a write access from the CPU to the APB
// bus when you have already programmed a DMA write on this APB.
// 2. Use semaphore implementation to avoid this behavior.

Т.е. если заюзать только СПИ, то всё скорее всего будет работать.

А можно ссылочку на первоисточник? Что-то в ерратах не нахожу. А из приведенного Вами фрагмента следует, что вообще нельзя писать в периферию на той же АРВ, на которой есть настроенная запись через DMA. Т.е. если DMA пишет в USART1 (висит на APB2) то я даже в GPIO не могу писать!
Это ОЧЕНЬ важное замечание, в этом необходимо разобраться внимательно.

Да, действительно, получается что ДМА не разгружает процессор, а просто немного ускоряет работу с переферией, нашел я эти комменты в исходниках примера MassStorage который идет для отладочной платы фирмы Olimex здесь

Из найденной информации следует совсем иное: DMA вообще НЕЛЬЗЯ корректно использовать в большинстве реальных проектов. Ввиду отсутствия FIFO имеем просто ж...


Я попытался использовать DMA на вывод в SPI2 потока 1МБайт/сек - ядро тормозится не более чем на 1% (на STR91 с FIFO это требовало побольше ресурсов). Насчет ошибок передачи пока сказать ничего не могу - вывод делался впустую.


Уже смотрю. В свою очередь я попытался поискать упоминания об этом ещё где-нибудь - пока не нашел. Не думаю, что столь существенная ошибка могла остаться никем более не замеченной, поэтому остаётся надеяться, что просто Stanimir Bonev в октябре 2007 чего-то недопонял и сгоряча зафиксировал несуществующий глюк. Тем более что внятного описания глюка там нет.

Предварительный результат исследований: при просмотре в режиме отладки (останов на контрольной точке и просмотр памяти) действительно периодически портятся данные, получаемые от АЦП через DMA: смещаются или выпадают каналы, при "рабочем полёте" (те же данные данные льются в USART с помощью DMA, дергается несколько GPIO) этого не замечено.

Смещение данных может быть вызванно тем что при останове процессора, АЦП продолжет работать !.
Умногих процессоров настраивается поведение клоков перефериии при брекпоинтах у этого я ненашел. Да и вобще реал тайм вещи отлаживать через JTAG ошибка.
Имхо АЦП устройство реального времени, а JTAG очень тормознутый. Это конечно только предположение сделанное по опыту работы с другими контроллерами, но через пару дней допаяют платку с STM32 обезательно проверю.

Я лишь пытаюсь понять, есть ли там проблема с DMA или её нет, см. выше (описание в примере от olimex)

P.S: С невозможностью использовать DMA одновременно на SPI2 и USART1 я разобрался и смирился