Цитата(haker_fox @ Apr 28 2018, 09:22)
Tx Burst 4 байта, Rx Burst 1 байт (4 работает неустойчиво, этом мы с вам в предыдущей теме по ссылке выше выяснили).
Об этом ничего не знаю... Что за блокировка? И как про кеши узнать?
Я не точно выразился: не кеши, а FIFO в DMA канале и FIFO в SSP.
Я уже давно не работал с LPC, уже подзабыл как там устроено. Но раз используете burst-пересылки, то прежде Вам нужно изучить как там формируются DMA-запросы от периферии. Именно с этим я думаю у Вас как раз и проблемы.
Почти год назад писал драйвер для SPI-FLASH на XMC4700. И у меня были очень похожие проблемы. Это было связано именно с формированием DMA-запросов от SPI-контроллера и их обработкой. В XMC в регистрах TX-FIFO и RX-FIFO программируется по какому уровню заполнения FIFO формировать DMA-event. Когда DMA-event генерируется, он запоминается триггером до момента начала обслуживания DMA-каналом. Вот в таком механизме как раз и кроется проблема.
Например: имею RX-FIFO == 16 слов, уровень генерации DMA-event-а при > 7 слов, размер RX-burst == 8 слов. Вроде бы всё нормально и должно работать? А нет - будет глючить! И чем выше скорость SPI-потока - тем чаще. Как раз и будет возникать событие RX-underrun. С TX-каналом всё аналогично, только будет событие TX-overflow.
Что происходит (как я понял)?: когда в RX-FIFO появляется 8-е слово, генерится RX-DMA-event, который запоминается триггером. Но RX-SPI ведь продолжает в это время работать и уже вдвигает биты следующего слова! DMA-контроллер освобождается, переходит к обслуживанию этого event-а (триггер сбрасывается), т.е. - начинает пересылку burst-а. Но он burst ведь считывает не сразу целиком атомарно из FIFO, а по словам. Например считывает 1-е слово. В FIFO теперь 7 слов. И в этот момент заканчивается вдвигание битов следующего слова. Оно поступает в FIFO, там опять >7 - т.е. генерится новый DMA-event, запоминаемый в триггере. А ведь чтение текущего burst ещё не закончено! И когда чтение закончится, в FIFO останется всего 1 слово (если за это время не успеет прийти ещё слов), а в триггере стоит запрос на чтение следующего burst размером ==8слов. Вот когда DMA начнёт обслуживание этого event-а, вот тогда и случится RX-underrun.
Такова природа проблем была у меня в XMC. У Вас возможно аналогично.
Я решил её уменьшением burst до 4 (1/4 от размера FIFO), но уровень формирования DMA-event сделал == 6 (event формируется при появлении 7-го слова в FIFO).
Для TX-канала всё аналогично, но наоборот.
Ну или вообще отказаться от burst (что мне было нежелательно).
Блокировка - это например DMA-контроллер XMC умеет выставлять сигнал LOCK на шину на время проведения burst-транзакции. Т.е. - никакие другие пересылки по шине не будут выполняться до завершения текущего burst DMA. Правда вышеописанной проблемы с формированием DMA-event-ов это никак не решает, хотя несколько уменьшает вероятность появления таких сбоев.
DMA-контроллер в Tiva (например) полностью лишён данной проблемы, так как там DMA-event-ы формируются совершенно по другому (более грамотно).
Цитата(haker_fox @ Apr 28 2018, 09:22)
Так был удобно, ибо на шине кроме флешек висит ещё с десяток устройств.
Насколько я помню - в LPC43xx SPIFI по ногам совмещён с одним из SSP, так что ничего не мешает для каких-то пересылок использовать SPIFI, а для других - SSP. Используя средства блокировки. Когда требуется выполнить транзакцию с другим устройством (или запись во FLASH): включаем блокировку, отключаем отображение SPIFI на адресное пространство, выполняем транзакцию, восстанавливаем отображение, снимаем блокировку.
Хотя - дело Ваше.
И снова LPC4337 + SSP + DMA, При выполнении memset, std::fill валится связь
Apr 28 2018, 01:11
