[megajohn 3]

вообщем, переделываю исходники чана для 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

[megajohn 3]

похоже, что натнкулся на это

 

Из-за багов в чипе (DMA останавливается раньше, чем вычитает весь FIFO) пришлось читать 120 двойных слов через DMA и потом остатки из FIFO выгребать вручную.

 

Далее, DMA реально останавливается, когда FIFO ещё не пустое - видать, при разводке чипа DMA прицепили к сигналу "FIFO наполовину заполнено". Вот он и не дочитывает. И подобного геммороя у NXP полно, странно то, что они не перевыпускают свои даташиты с исправлениями.

 

ссылка

[VslavX 0]

в памяти, куда был настроен DMA вижу весь свой сектор но кроме 32байт, и они лежат в фифо MCI

и не понимаю почему они не забираются DMA

Не сталкивался с таким, у меня на LPC1788 все работает, DMA настраиваю так:

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;

 

[haker_fox 60]

А я так DMA на LPC2478 в связке с MCI не запустил. Оно (ПДП) не вычитывает FIFO MCI до конца. Долго не мог разобраться. Потом чихнул, и читал ассемблерными вставками по прерыванию. Вставки взял в примере той же FatFS (имеется в виду проект под мой контроллер)... Что-то там мутно и темно...

[megajohn 3]

Не сталкивался с таким, у меня на LPC1788 все работает, DMA настраиваю так:

у вас пример MEM2MCI. Покажите плз еще обратно.

На данный момент подправил TranfreSize но так и остались не все завершенные трансферы.

 

 

На данный момент добился нормальной работы через DMA только задавая MCI->DATALENGTH = 512 + 32

[VslavX 0]

у вас пример MEM2MCI. Покажите плз еще обратно.

//
// Запрещаем и подготавливаем канал 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.

[Grape 0]

Подтверждаю, все корректно работает на LPC1778, LPC2468.

 

единственно, не стал использовать прерывания и сервисы RTOS - долго.

 

/Gr

[megajohn 3]

DMA_CH1_SRC = (DWORD)buf;

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
   }
}

 

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.

[jcxz 184]

вообщем, переделываю исходники чана для 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)? А также размерности пересылки и выравнивания.

 

Из-за багов в чипе (DMA останавливается раньше, чем вычитает весь FIFO) пришлось читать 120 двойных слов через DMA и потом остатки из FIFO выгребать вручную.

Далее, DMA реально останавливается, когда FIFO ещё не пустое - видать, при разводке чипа DMA прицепили к сигналу "FIFO наполовину заполнено". Вот он и не дочитывает. И подобного геммороя у NXP полно, странно то, что они не перевыпускают свои даташиты с исправлениями.

Уже много лет работаю с МК от NXP. LPC23xx, LPC17xx, LPC178x. Больше десятка разных устройств, работал с большей частью встроенной периферии - ну ни разу не натыкался на серьёзные баги, ну или что-то существенное, что запомнилось-бы.

И в то же время периодически слышу о багах в них у кого-то.... Вот почему такое??? Неужто мне так везёт, что я каждый раз использую только ту периферию, в которой нет багов, и только те её режимы, которые не глючат????? :laughing:

 

PS: Всегда стараюсь следовать правилу - 99% вероятности, что проблема у меня. И только после этого начинаю грешить на железо.

[megajohn 3]

А зачем их (исходники Чана) переделывать???

переделывалась работа с MCI + цеплялась ось. Где вы увидели что я написал про переделку FatFs ?

 

 

[jcxz 184]

переделывалась работа с MCI + цеплялась ось. Где вы увидели что я написал про переделку FatFs ?

Я вообще не переделывал - написал своё, взяв только собственно FatFS.