Здравствуйте!
Использую массив памяти, разбитый на две части для записи во флэш
DMА заполняет одну половину массива, а другую проц перекидывает во флэш
Потом они меняются
итд
При считывании ошибки, неясно почему.
Вот думаю
Могут ли процессор и DMA одновременно обращатся к SRAM?
Останавливается ли проц когда работает DMA?
В документации не нашел. В глаза не бросилось.
Странно такой важный пункт могли бы почетче
Подскажите плз, если кто знает

Целая глава в документации: 15. HSB Bus Matrix (HMATRIXB)

А спасибо. Слона то я и не приметил

Подскажите плз где взять Errata на SAM4L
у Atmel не нашел, наверное плохо искал

Есть проблема совместной работы DMA и проц
На всякий случай опишу проблему

есть массив разбитый на 2 части по DMABLSIZE

Есть SPI slave по которому передаются в камень 32битные слова по 4 байта
в одном кадре передается 3 слова.
Каждое слово на 1 больше предыдущего
поток бесконечен

Передача осуществляется через DMA, программа в это время крутится в цикле
while(true){

while(!blocktowrite);

ProgPage();

blocktowrite = false;
}

по окончании заполнения одного блока DMA переключается на второй, адрес которого был заранее установлен в релоад регистре
срабатывает прерывание в котором
- устанавливается reload адрес первого блока. DMA при этом не выкл
- устанавливается reload размер. DMA продолжает работать
- устанавливает флаг blocktowrite
прерывание завершается

далее программа переходит в цикл, откуда вызывается ProgPage(), сбрасывающее содержимое первого блока во flash

итд все повторяется. Блоки, естественно меняются местами. Заполняется один считывание из другого.

При смене блоков или как-то еще происходит искажение одних из первых байт. Искажение в общем случайное, но строго регулярно

Может у кого-то было такое? Мало ли. Неделю t,ecm

Errata не нашел в поисковике, видно молодой проц

Рубрикатора такого тоже нет на сайте, gblfhfcs

Помогите, если кто что знает
Спасибо

Подскажите плз где взять Errata на SAM4L
у Atmel не нашел, наверное плохо искал

Есть проблема совместной работы DMA и проц
На всякий случай опишу проблему

есть массив разбитый на 2 части по DMABLSIZE

Есть SPI slave по которому передаются в камень 32битные слова по 4 байта
в одном кадре передается 3 слова.
Каждое слово на 1 больше предыдущего
поток бесконечен

Передача осуществляется через DMA, программа в это время крутится в цикле
while(true){

while(!blocktowrite);

ProgPage();

blocktowrite = false;
}

по окончании заполнения одного блока DMA переключается на второй, адрес которого был заранее установлен в релоад регистре
срабатывает прерывание в котором
- устанавливается reload адрес первого блока. DMA при этом не выкл
- устанавливается reload размер. DMA продолжает работать
- устанавливает флаг blocktowrite
прерывание завершается

далее программа переходит в цикл, откуда вызывается ProgPage(), сбрасывающее содержимое первого блока во flash

итд все повторяется. Блоки, естественно меняются местами. Заполняется один считывание из другого.

При смене блоков или как-то еще происходит искажение одних из первых байт. Искажение в общем случайное, но строго регулярно

Может у кого-то было такое? Мало ли. Неделю t,ecm

Errata не нашел в поисковике, видно молодой проц

Рубрикатора такого тоже нет на сайте, gblfhfcs

Помогите, если кто что знает
Спасибо

Конечно, errata в самом datasheet, п.45

Если кто - нибудь знает тонкости работы DMA и процессора, сталкивался с подобным поделитесь


Есть ли симуляторы для sam4l?Проверить это [CENSORED]

Не с той стороны заходите.
Всегда стоит придерживаться правила:
"В первую очередь ищем баг у себя. И во-вторую очередь - у себя. И в 3-ю. ... И только в N-ую - у кого-то другого".
И ещё - как правило баги процесора лежат гораздо глубже, а не на поверхности.
У вас-же - обычная штатная работа. Очень маловероятно, что виноват баг CPU.
Где-то Вы напутали с синхронизацией DMA - ISR - цикл while(!blocktowrite)
либо не понимаете как работает DMA.
Так что следуем правилу.

Проблема возникает у процессора при считывании, при включенном ДМА. Это установлено парой экскрементов
После остановки содеримое в массиве нормальное из JTAG
Характер ошибки меняется при изменении частоты процессора и вариации длины пакета в HSB арбитраже
А как ISR может влиять на DMA?
В том смысле что я теряю часть данных ? нет это точно сбой
Прилагаю рисунок - в первых двух словах 3тьи байти искажаются и так в начале каждого блока строго регулярно но случайным образом

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

Или же время переключения ДМА такое большое что сбивается прием во время переключения

ваш SPI кстати аппаратный? А ФИФО есть на нем? Может тупо прерывание и переключение чего в SPI проглатывает, может каким-то ножками дергает, которые SPI обмен сбивают?

Что-то Вы странное рассказываете, коллега...
Имею кучу проектов на LPC17xx/LPC177x, везде очень активно используется GPDMA (и в непрерывном режиме (flip-flop) и single-shoot) работающее с различной
периферией: SSP, UART, ADC, DAC, даже GPIO. И не сталкивался с подобной проблемой.
Есть там проблема с приоритетом GPDMA-CPU, это да, но описанной не помню.
Если нужно непрерывное DMA, обычно использую либо flip-flop в 2 буфера, либо более сложные варианты с редактированием
следующих LLI-структур в памяти в ISR на лету.
Также делаю и завершение непрерывного DMA - не запрещением через бит "Channel enable", а посредством установки LLI в 0 в следующем LLI-блоке в памяти.

К сожалению - с SAM4L дела не имел, так что по его периферии ничего сказать не могу.

Да я не говорю про проблемы, я говорю про сложности.
вот типа завершение через Channel enable как раз из того раздела.

If a channel must be disabled without losing data in the FIFO, the Halt bit must be se
so that further DMA requests are ignored. The Active bit must then be polled until it
reaches 0, indicating that there is no data left in the FIFO. Finally, the Channel Enable
bit can be cleared.

ибо
A channel can be disabled by clearing the Enable bit. This causes the current AHB
transfer (if one is in progress) to complete and the channel is then disabled. Any data
in the FIFO of the relevant channel is lost. Restarting the channel by setting the
Channel Enable bit has unpredictable effects, the channel must be fully re-initialized.

Но это все для LPC на случай переключения руками. А что в этом проце фиг знает... Но я бы осцилом поглядел на SPI обмен, не возникает ли в момент переключения каких тупней, типа пропусков клоков, их дрожания и так далее... Проц в SPI слейв или мастер, не очень понятно из вводного сообщения. SPI железный или на прерываниях, есть ли у него ФИФО. То есть я бы поискал вокруг ДМА проблеммы

SPI железный, в режиме SLAVE, фифо есть он выключен
байты группируются в кадры по 12штук, те 3три 32бит слова

между кадрами интервал 30мкс
частота spi 2мгц
проц 10мгц
DMA перегружается автоматически. У нее есть регистры перегрузки MARR, TCRR
Одновременно срабытывает прерывание и в регистры перегрузки пишеться новое значение

А проблемы не со стороны DMA а со стороны проца
Потому что есть передавать константы то проблем нет. Это значит проц считывает не с того адреса поэтоиу если все константы то результат неискажается
То же самое - если DMA остановить то последние данные считывается без ошибок

Зачем выключен FIFO???


DMA-контроллер скорей всего тактируется от тех-же 10МГц и шина внутри МК - тож.
А 2МГц - это уже в таком случае должно хорошо нагружать шину.
По-крайней мере у меня на LPC1758 SPI на 2МГц работающий через DMA и CPU на 6МГц уже возникали иногда
overflow SPI.FIFO. И это при том что у меня FIFO включен! Правда у меня ещё параллельно несколько каналов DMA
работало. Но всё равно - пришлось снизить частоту SPI - помогло.
Какой у вашего CPU приоритет доступа к шине и какой приоритет у DMA-контроллера?

Подумайте что будет, если у CPU приоритет доступа выше, он делает fetching блока инструкций (из-за выполнения инструкции перехода например),
а в это время DMA надо в память записать, а вы ещё и FIFO отключили...
Ещё неизвестно - на какой шине сидит ваш SPI, и к каким шинам обращается CPU - возможно к низкочастотным и из-за этого
могут возникать ожидания. А у вас DMA-контроллеру срочно записать данные надо.
И вообще - вы обрабатываете события переполнения SPI?

Совет (в порядке убывания важности):
сделайте приоритет доступа к шине для DMA выше чем для CPU (если это позволяет SAM4L),
включайте FIFO, повышайте частоту CPU (шины), если есть возможность - понижайте частоту SPI.

PS: Да, у вас-же два DMA-канала используются - для SPI.TX и для SPI.RX. Надеюсь для TX-канала Вы поставили приоритет ниже, чем для RX-канала?

PPS: Также полезно строить циклы ожидания флага не так как у вас - while(!blocktowrite) - это-же загружает шину непрерывными бессмысленными транзакциями чтения -
одно только это может забивать шину (если у CPU приоритет доступа к шине выше чем у DMA).
Полезно в таком цикле выполнять инструкцию WFE (или WFI) если уж у вас без ОС. Или использовать ОС, выполняющую в Idle-процессе эти же WFE/WFI.