P.S.S.S.
И всё-таки особенность есть. Я доделал в драйвере SSP всё, о чём говорилось тут. Но в редких-редких случаях всё равно наблюдается то, что я написал в самом первом сообщении: в канале DMA, напроенным на приём, остаётся транзакция на 4 байта. В регистре "сырых" прерываний стоят флаги RORRIS и RTRIS. Т.е. буфер переполнен, и ещё таймаут. Но DMA даже не собирается забирать от туда ничего. При этом клок на шине, как я понимаю, даже уже и не нужен. Ведь данные в фифо. Что интересно, если программно сформировать burst запрос, то флаги очищаются, а DMA рапортует об успешном завершении транзакции. Правда валидность данных я не проверял в таком режиме, думаю, что они не будут правильным, т.к. установлен "оверран". Вроде как проблему решило изменение burst rx на 1 байт вместо 4х. В документации не нашёл прямого ответа на свой вопрос: какие линии запроса заведены на DMA от SSP (burst, single или оба). Возможно невнимательно читал.

Вот именно.


Я уже несколько лет не работал с LPC17xx. Поднял свои старые исходники, посмотрел: у меня драйвер SSP для LPC1768 не использует burst, а для LPC1778 - использует. Код драйвера - один и тот же. Уже не помню с чем это связано, видимо тоже были какие-то проблемы. Драйвер этот я хорошо испытывал - интенсивный многозадачный псевдослучайный обмен с флешкой на SCLK==25...30МГц параллельно с таким же обменом с FRAM и другими DMA-транзакциями. Работает уже много лет в десятках тысяч выпущенных устройств у заказчиков. Без проблем.
 fram_flash.7z ( 4.84 килобайт ) Кол-во скачиваний: 25

Для LPC1778:
#define BURST_MODE 1
Для LPC1768:
#define BURST_MODE 0
ActDF()/ActFram() - собственно старт транзакции с программированием DMA.
isrDMA_dflash()/isrDMA_fram() - должны вызываться из общего ISR для GPDMA.
До любой транзакции вызывается инит: InitDFlashFram() (до старта ОС), а затем - ConfigureDFlashFram() (после старта ОС).

Спасибо, что выложили его сюда! Для меня это будет прекрасным примеров, ведь интересно посмотреть драйвер реально работающий, реально испытанный!!!

А так с burst rx = 1 уже с обеда без сбоев всё работает))) Я написал на форуме nxp вопрос, но там подобные без ответа лежат по нескольку месяцев)))

Пожалуйста. Пользуйтесь.


Возможно и мой будет работать - я его на LPC43xx не использовал, так как на LPC43xx флешку я подключал на SPIFI.
Файл fram_flash.h который в архиве - для устройства на LPC1778, для LPC1768 - он немного другой, но отличия там - в указанном дефайне, частоте SCLK, списке поддерживаемых чипов и ещё какой-то мелочи.

В нашем случае получилось лёгкое извращение, т.к. на одной SSP висит несколько устройств от слишком медленных сигма-дельта АЦП до одной N25Q128. В этом микроконтроллере есть ещё одна SSP, но она занята действительно под высокоскоростной обмен, и её трогать нельзя. А вот SSP0 пришлось через программный мультиплексор (набор виртуальных шин) поключить к нескольким дейвасам, а ОС в каждом потоке работает со своим устройством. Правда общая запись/чтение на флешку не превышает 45 кБ/сек. Возможно можно оптимизировать, но пока оставил так. Аппаратный SPIFI использовать не вышло по техническим причинам.

У меня указанный драйвер на каких-то устройствах работает с чипами FLASH и FRAM сидящими на одном SSP, на других - на разных SSP.
Для этого там и используются семафоры ОС.

Да, я заметил) А какие у вас скорости доступа к флеш, не помните на вскидку?))

SCLK? В хидере указана. Для LPC1778 == 30МГц.

Нет, я имел в виду скорость записи и чтения на флешку. Ну например, запись 1 Мб/сек, чтение 10 Мбайт/сек.

Те устройства, где тот мой драйвер используются, не нуждаются в реал-тайм записи потоков.
Там, где нужна была запись реал-тайм-потоков, я строил драйвер по-другому - с гарантированным временем доступа службе, требующей реал-тайм-записи.