В общем тема такая: есть lpc4357 на нем крутится freertos, под ней несколько задач. Втом числе lwip с ftp клиентом под ним. Так же есть i2s драйвер в задачи которого входит выделялять память под аудиобуффер из пула буферов(память под пул выделена статически) и добавлять его (выделенный буффер) в цепочку связанных списков дма, которая потом по мере опустошения хардварного fifo вываливается в i2s. Теперь собственно проблема: в некоторые моменты дма как бы зависает. изза чего на i2s формируются провалы. но если сформировать и забить всю цепочку списков дма данными, и в процессе работы системы остановить отладчиком камень, то сигнал на i2s не рвется. Сначала грешил на прерывания ethernet. но потом попробовал забивать буффера стат. данными из флешь. т.е. без участия сети. ситуация не изменилась. Сейчас скллоняюсь к тому что все это происходит изза наличия в коде критических секций, во время которых отключаются преравания. Но практического решения придумать немогу. Поэтому прошу совета......

Если правильном приготовлении DMA как бы вообще не должны мешать кратковременные (и не очень) запреты прерываний.
Не работал с LPC43x, но обычно в DMA контроллерах (в том числе LPC-ых) имеется возможность запускать DMA в режиме связных списков к примеру.
Программируете DMA на передачу цепочки связных блоков, с прерыванием после передачи каждого блока и в этом прерывании на лету дописываете следующий блок в цепочку.
Следите чтобы в каждый момент времени у DMA-контроллера кроме текущего был на готове уже следующий блок цепочки.
Ну и еще могут быть проблемы с загрузкой шины (и арбитражём шины между DMA и ЦПУ и из-за этого underflow DMA), но это при высокой скорости потока на DMA. С какой скоростью у вас идёт поток в i2s?
Поищите в контроллере регистр управляющий приоритетами доступа к шине bus-masters и поставьте для DMA выше чем для CPU.

Настроено-то как раз все именно так, как предложено. с той лишь разницей, что новые блоки добавляются не в прерывании, т.к. буферов много. В прерывании щелкает счетный семафор, который недает перезаписывать еще не отправленные блоки. Проблемы с шиной: да , может быть, но в этом камне я ненашел регистра приоритетов арбитража шины. Это СМ4. В СМ3 lpc17xx он есть, и сильно помогал, а сдесь нет, или не указан в UM. Но вряд ли засада в этом, т.к. я писал что пробовал грузить данные из флешь, (в этом камне их 2 на разных шинах) . так что вряд ли. По поводу скорости: поток достаточно быстрый (выводится звук в ф-те 24бита 192 кгц), запас по скорости работы декодера аудио где-то раз в 10, но дефект проявляется и на меньшей скорости вплоть до 16бит 44100гц. просто он не так ярко выражен, время задержки меньше. пробовал так-же циклическую ссылку (когда 2 элемента списка ссылаются друг на друга). дефект все равно есть.