вообщем, переделываю исходники чана для LPC23 на свой LPC1778 + делаю под TNkernel и на DMA.
Вот с чем столкнулся. Карта иннициализируется нормально
настраиваю DMA на прием 512 байт
SRC_BURST_SIZE_1 + DST_BURST_SIZE_1 + SRC_32 + DST_32 + DST_INC и включаю канал
настраиваю
MCI_DATA_LEN=512
MCI_DATA_TMR=дофига
MCI_CLEAR = 0x72A; // далее все как у чана
MCI_MASK0 = 0x72A;
MCI_DATA_CTRL
шлю карте команду CMD17 и жду прерывания от MCI
приходит со статусом
00000000 00100000 10100101 01000000
где выставлено, типо все завершено но в фифо есть данные
в памяти, куда был настроен DMA вижу весь свой сектор но кроме 32байт, и они лежат в фифо MCI
и не понимаю почему они не забираются DMA
на данный момент, пересмотрел исходники чана, томаса, IAR NXP и Nemuisan и там не вижу чтобы ручками вычитывали данные.
Может под конец рабочего дня уже всё перегрелось: и я и MCU
Полная версия этой страницы: LPC1778 DMA не вычитывает последние данные из FIFO MCI
похоже, что натнкулся на это
Из-за багов в чипе (DMA останавливается раньше, чем вычитает весь FIFO) пришлось читать 120 двойных слов через DMA и потом остатки из FIFO выгребать вручную.
Далее, DMA реально останавливается, когда FIFO ещё не пустое - видать, при разводке чипа DMA прицепили к сигналу "FIFO наполовину заполнено". Вот он и не дочитывает. И подобного геммороя у NXP полно, странно то, что они не перевыпускают свои даташиты с исправлениями.
ссылка
Из-за багов в чипе (DMA останавливается раньше, чем вычитает весь FIFO) пришлось читать 120 двойных слов через DMA и потом остатки из FIFO выгребать вручную.
Далее, DMA реально останавливается, когда FIFO ещё не пустое - видать, при разводке чипа DMA прицепили к сигналу "FIFO наполовину заполнено". Вот он и не дочитывает. И подобного геммороя у NXP полно, странно то, что они не перевыпускают свои даташиты с исправлениями.
ссылка
Цитата(megajohn @ Mar 15 2013, 19:37) 
в памяти, куда был настроен DMA вижу весь свой сектор но кроме 32байт, и они лежат в фифо MCI
и не понимаю почему они не забираются DMA
и не понимаю почему они не забираются DMA
Не сталкивался с таким, у меня на LPC1788 все работает, DMA настраиваю так:
CODE
MCI_DATA_CTRL = 0;
//
// Запрещаем и подготавливаем канал 1 модуля GP DMA
//
DMA_CH1_CFG = 0;
DMA_INT_TC_CLR = bDMA_TC_INT1;
DMA_INT_ERR_CLR = bDMA_ERR_INT1;
DMA_CH1_SRC = (DWORD)buf;
DMA_CH1_DEST = (DWORD)&MCI_FIFO[0];
DMA_CH1_LLI = NULL;
DMA_CH1_CTRL = IO_SDMMC_BLOCK_SIZE/sizeof(DWORD) // число не байтов
| bDMA_SBSIZE_8 // а трансферов
| bDMA_DBSIZE_8 // на стороне источника
| bDMA_SWIDTH_32
| bDMA_DWIDTH_32
| bDMA_SI
| bDMA_I;
А я так DMA на LPC2478 в связке с MCI не запустил. Оно (ПДП) не вычитывает FIFO MCI до конца. Долго не мог разобраться. Потом чихнул, и читал ассемблерными вставками по прерыванию. Вставки взял в примере той же FatFS (имеется в виду проект под мой контроллер)... Что-то там мутно и темно...
Цитата(VslavX @ Mar 18 2013, 22:32)
Не сталкивался с таким, у меня на LPC1788 все работает, DMA настраиваю так:
у вас пример MEM2MCI. Покажите плз еще обратно.
На данный момент подправил TranfreSize но так и остались не все завершенные трансферы.
На данный момент добился нормальной работы через DMA только задавая MCI->DATALENGTH = 512 + 32
Цитата(megajohn @ Mar 19 2013, 08:28)
у вас пример MEM2MCI. Покажите плз еще обратно.
CODE
//
// Запрещаем и подготавливаем канал 1 модуля GP DMA
//
DMA_CH1_CFG = 0;
DMA_INT_TC_CLR = bDMA_TC_INT1;
DMA_INT_ERR_CLR = bDMA_ERR_INT1;
DMA_CH1_SRC = (DWORD)&MCI_FIFO[0];
DMA_CH1_DEST = (DWORD)buf;
DMA_CH1_LLI = NULL;
DMA_CH1_CTRL = IO_SDMMC_BLOCK_SIZE/sizeof(DWORD) // число не байтов
| bDMA_SBSIZE_8 // а трансферов
| bDMA_DBSIZE_8 // на стороне источника
| bDMA_SWIDTH_32
| bDMA_DWIDTH_32
| bDMA_DI
| bDMA_I;
Там то же самое. Причем работают как варианты с одиночным сектором, так и с непрерывным чтением.
Специально сейчас после окончания транзакции распечатал DMA_CH1_CTRL - в поле счетчика светится 0, все данные корректно переданы в буфер. А то я уже сомневаться начал - с 1788 еще прикладники плотно не работали, может там ошибка. Но вроде нет, все нормально. Этот же код успешно работает на 2368/88.
Подтверждаю, все корректно работает на LPC1778, LPC2468.
единственно, не стал использовать прерывания и сервисы RTOS - долго.
/Gr
единственно, не стал использовать прерывания и сервисы RTOS - долго.
/Gr
Цитата(VslavX @ Mar 18 2013, 21:32)
DMA_CH1_SRC = (DWORD)buf;
DMA_CH1_CTRL = bDMA_SWIDTH_32
DMA_CH1_CTRL = bDMA_SWIDTH_32
в такой конфигурации при работе через FatFS возможны проблемы: исходные данные могут быть невыровнены на 32 и тогда сбой в записываемом файле.
Это особенность работы FatFS когда данных у пользователя не менее одного сектора и указатель "убежал" на некратное число
Вот псевдокод
Код
aligned4 u8 user_data[];
aligned4 u8 FATFS_win[];
void main ( void )
{
memset( user_data, 70, 0xD1 );
f_write( user_data, 70 );
{// FatFS
memcpy( FATFS_win, user_data, 70 );
}
memset( user_data, 1024, 0xD2 );
f_write( user_data, 1024 );
{// FatFS
memcpy( &FATFS_win[70], user_data, 512-70=442 ); // Fit partial sector
disk_write( FATFS_win, 1_sector ) // Write-back sector cache
disk_write( &user_data[ 442 ], 1_sector ) // ERROR ! &user_data[ 442 ] not aligned 4, and "LPC->MCI:MMC_disk_write" write shift data
}
}
aligned4 u8 FATFS_win[];
void main ( void )
{
memset( user_data, 70, 0xD1 );
f_write( user_data, 70 );
{// FatFS
memcpy( FATFS_win, user_data, 70 );
}
memset( user_data, 1024, 0xD2 );
f_write( user_data, 1024 );
{// FatFS
memcpy( &FATFS_win[70], user_data, 512-70=442 ); // Fit partial sector
disk_write( FATFS_win, 1_sector ) // Write-back sector cache
disk_write( &user_data[ 442 ], 1_sector ) // ERROR ! &user_data[ 442 ] not aligned 4, and "LPC->MCI:MMC_disk_write" write shift data
}
}
Add: вот в доке написано требование
The memory address specified by buff is not that always aligned to word boundary because the argument is defined as BYTE*. The misaligned read/write request can occure at direct transfer. If the bus architecture, especially DMA controller, does not allow misaligned memory access, it should be solved in this function.
Цитата(megajohn @ Mar 15 2013, 23:37)
вообщем, переделываю исходники чана для LPC23 на свой LPC1778 + делаю под TNkernel и на DMA.
А зачем их (исходники Чана) переделывать??? Их же как раз трогать не надо, надо только прописать низкоуровневую прослойку абстрагирования от аппаратуры (HAL-драйвер - hardware abstraction level).
Про работу через MCI сказать ничего не могу - не пользовал. Но я сам недавно прописывал HAL для связки FatFS+SPI+LPC1788+uCOS.
Мой HAL-драйвер помимо работы через DMA, поддерживает одновременную работу через функции FatFS и низкоуровенвое обращение на чтение/запись к массиву данных SD-карты
(можно работать одновременно двум задачам прикладного уровня не мешая друг другу).
Никаких проблем не обнаружил - всё работает чётко. Чтение SD в обход FatFS через низкоуровневое API == ~1.3МБ/сек.
Могу только посоветовать проверить, что Вы пишете в CONTROL-регистр DMA-канала: размер пакета - соответствует-ли выбранной периферии (MCI)? А также размерности пересылки и выравнивания.
Цитата(megajohn @ Mar 18 2013, 20:15)
Из-за багов в чипе (DMA останавливается раньше, чем вычитает весь FIFO) пришлось читать 120 двойных слов через DMA и потом остатки из FIFO выгребать вручную.
Далее, DMA реально останавливается, когда FIFO ещё не пустое - видать, при разводке чипа DMA прицепили к сигналу "FIFO наполовину заполнено". Вот он и не дочитывает. И подобного геммороя у NXP полно, странно то, что они не перевыпускают свои даташиты с исправлениями.
Далее, DMA реально останавливается, когда FIFO ещё не пустое - видать, при разводке чипа DMA прицепили к сигналу "FIFO наполовину заполнено". Вот он и не дочитывает. И подобного геммороя у NXP полно, странно то, что они не перевыпускают свои даташиты с исправлениями.
Уже много лет работаю с МК от NXP. LPC23xx, LPC17xx, LPC178x. Больше десятка разных устройств, работал с большей частью встроенной периферии - ну ни разу не натыкался на серьёзные баги, ну или что-то существенное, что запомнилось-бы.
И в то же время периодически слышу о багах в них у кого-то.... Вот почему такое??? Неужто мне так везёт, что я каждый раз использую только ту периферию, в которой нет багов, и только те её режимы, которые не глючат?????
PS: Всегда стараюсь следовать правилу - 99% вероятности, что проблема у меня. И только после этого начинаю грешить на железо.
Цитата(jcxz @ Mar 20 2015, 10:07)
А зачем их (исходники Чана) переделывать???
переделывалась работа с MCI + цеплялась ось. Где вы увидели что я написал про переделку FatFs ?
Цитата(megajohn @ Mar 20 2015, 12:54)
переделывалась работа с MCI + цеплялась ось. Где вы увидели что я написал про переделку FatFs ?
Я вообще не переделывал - написал своё, взяв только собственно FatFS.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.