Всем доброго дня!

Вопрос уже задавал в ветке "ARM32 для начинающих".

Проблема с записью в SDRAM массивов. Ошибки происходят либо при инициализации массива, либо при непрерывной записи в массив.
Сняли осциллограмму. На ней циклы записи в память идут очень плотно, даже без соблюдения правильной длительности отдельной операции записи. Если не добавлять в программе NOP между записью в конкретную ячейку памяти, то заполнение массива гибнет. Притом всегда в одном и том же месте при данных настройках.

При изменении таймингов место "краха" изменяется. И что особенно непонятно для меня - чем более длительные тайминги задаешь, тем больше NOP я должен поставить в программе.

Т.е. проблема не в несоблюдении таймингов в конкретной операции, а в том - что контроллер работает быстрее, чем память и пытается записать значения чаще, чем это допустимо, хотя в регистрах управления SDRAM вся информация о быстродействии памяти контроллеру "известна". Неужели необходимо снижение тактовой частоты контроллера, без снижения частоты работы SDRAM ? По-моему это маловероятно. А как "объяснить" контроллеру, что записывать чаще нельзя - я не могу найти.

Это лично мой взгляд на проблему. Высказывалась версия, что контроллер не может "впихнуть" команду REFRESH (64ms/8kb). Что тоже возможно. Но, опять же, где это задается в контроллере LPC3250, я что-то пока не нашел.

Еще, если есть возможность, киньте ссылку на литературу или хорошую статью по SDRAM.

Наверно это полумера, но сравнял частоту HCLK и частоту ядра. Сейчас 130МГц и то и другое. Видеопамять так и не получилось разместить в SDRAM. Какие то полоски на экране и помехи. В IRAM видеопамять работает.

А так в общем все работает.

Чтобы не было выпадения картинки когда видеопамять в SDRAM, надо разместить её в кэшированной областе. Честно говоря я не помню как конкретно, но кажется вот так
int16 Array[VIDEOSIZE];
#define VIDEOMEMORY Array+0x4000
В понедельник загляну на работе к свой код и исправлю если что.
А по поводу SDRAM, у меня ядро на 208 а память если память не изменяет на 104MHz и всё работает. Я скопировал настройки и железо с платы Phytek. Могу поделиться в понедельник если надо

Подобные полосы наблюдал на плате с DDR SDRAM (CPU - 260MHz, DDR - 130*2MHz). Проявлялись при плотненькой нагрузке с участием VFP и очень частых прерываний(откуда исполнялся код - уже не помню). Пока остановился на гипотезе, что прерванная инструкция VFP абортится (это как раз в доках описано) и происходит какая-то хрень на шине/буфере записи. После избавления от плавучки в прерываниях - больше полосок вроде не было. Дальнейший НИР не проводил. Видимо не только VFP может вызывать такую бяку.

scorp2011

По поводу кэширования видеобуфера - вовсе не гарантированно; может помочь, а может и нет. Всё это - для организации burst-write в SDRAM при рисовании (иначе на каждую операцию записи будет генериться отдельное обращение к SDRAM), контроллеру LCD до кэша нет дела - читать он будет из SDRAM.

Честно говоря с этим кешированием я не очень разобрался, но вот так работает лучше. Кстати cf7k, вы правы, у меня бяка была при анимации
__no_init static U16 _aVRAM[VRAM_SIZE*2];
#define LCD_VRAM ((U32)&_aVRAM[0] + 0x4000000) // write to non cached SDRAM area

Проблем в LPC3250 с SDRAM нет никаких.
Также почти не заметно влияние на производительность работы буфера TFT из внешней SDRAM.
Много раз испытано.

Сейчас как раз на выставке демонстрируется мой встраиваемый дивайс с TFT на базе LPC3250 и реализованной на нем embedded GUI.
Выставка - Lift Expo Russia 2011 в выставочном центре (ВДНХ) c 15-го по 17-е июня, стенд F5. Расскажем и покажем как сделать надежной работу с LPC3250 с SDRAM