Шины данных и адреса в проце rm9200 используют sdram и sram-like девайс. Цепляю картинки с (1) правильными циклами чтения-записи и (2) со сбоями. Во втором случае ОС задерживает циклы, обрабатывая другие задачи или прерывания и в результате происходит сбой, данные в следующих циклах читаются нормально. В чем может быть проблема?

Верхний сигнал SC на sram, нижний бит данных.

Какие сигналы показаны на осциллограммах? Вернее что смущает в бите данных? Двойной прыжок?
SC наверное CS?

SC - CS?
Напишите, что именно неправильно на второй картинке.

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

Тем не менее, к картинкам придраться трудно, ничего подозрительного они не содержат.
Что за девайс подключен к шине?

Подключен Циклон2. Он тоже под подозрением, ищу ошибку в коде.

Ляпа у вас, скорее всего аппаратная, а не программная. Надо внимательно проверить как у вас sram-like устройство подключено. Второе. Задержка на второй осциллограмме очень мала, если вы считаете, что в этот момент возникло прерывание. Интересно, при обращении к Циклону у вас всегда считывается "1"?

> Интересно, при обращении к Циклону у вас всегда считывается "1"?

да, каждый раз после задержки цикла чтения.

Учитывая то, что на картинке не видно ни малейших попыток с его стороны выставить '0', то я бы тоже грешил на ошибку в коде.

Нашел один баг. В свежескачанном даташите на rm9200, стр.182 Fig.18-39 нарисована диаграмма обмена, которую я повторил. Но почему-то адрес по которому должно размещаться старшее слово (второй) контроллером памяти не изменяется, т.е. addr+1 не выставляется. У меня в результате сбой в алгоритме. И что делать теперь - читать словами что-ли? Даташит вроде перепахал полностью, ничего нет на эту тему.

Скорее всего CS для этого устройства запрограммирован как для 16-разрядного устройства, а ваше устройство - 8-битное.

Вот конфиг:

//* Configure register for CS5
AT91C_BASE_SMC2->SMC2_CSR[5] = AT91C_SMC2_WS_EN // 1 - Wait State Enabled
| AT91C_SMC2_NWS_1 // Number of Wait States = 1
| AT91C_SMC2_TDF_0 // Data Float Time = 0
| AT91C_SMC2_BAT_16 // 1 - Byte Access Type 16 bit
| AT91C_SMC2_DBW_16 // 01 - Data Bus With 16 bit
| AT91C_SMC2_DRP_STD // 0 - Standart Data Read Protocol
| AT91C_SMC2_RWSETUP_0 // Read and Write Setup Time = 0
| AT91C_SMC2_RWHOLD_0; // Read and Write Hold Time = 0


Девайс (Циклон) программируемый, разрядность обмена ограничивается только шинами АРМа. Сейчас сконфигурирован под 16 бит. Читается регистр int (т.е. 2 слова или 4 байта).

Надо настроить вывод PC11 как CS5:


в самом начале до загрузки AT91_SYS->EBI_SMC2_CSR[5]

PC11/NCS5/CFCE1 по ресету в NCS5, а иначе бы я не смог показать CS на картинках. Конфигурировать дополнительно пробовал, безрезультатно.

По reset'у - это вход, как и все порты. В моем проекте я использую CS7 и делаю все так, как вам рассказал - без проблем.

Вопрос снимается.

Для тех кто соберется использовать Memory Controller в rm9200: имейте в виду что процессор очень критичен к моментам перевода шины данных в высокоимпедансное состояние. Все диаграммы обмена по шине данных должны соответствовать один-в-один нарисованным в даташите. У меня в коде была инструкция vhdl (loop) которая не синтезировалась за один такт, что приводило к сбоям в обмене.

ps т.е. отпускание шины в Z-состояние должно происходить быстрее, чем 1/4 клока (по переходу RD в '1'). Не каждым осциллографом это можно увидеть.

Для этого и предусмотрены программируемые задержки при формировании CS.

Вобщем да, но мне нужна максимальная скорость обмена, лишние задержки при этом не нужны.

Так и не понял - сами ведь пишете, что циклон не успевает выполнить операцию при определенных условиях. Значит задержка нужна.

Когда разместил вопрос, то не успевал, теперь успевает. Тактовая частота циклона (чип 8 speed grade) 250МГц , единственная задержка которую пришлось пока оставить это Wait State = 1 clk. Если буду применять более быстрый чип, и эту задержку можно будет убрать.

Интересно, а в вашем проекте какие параметры удалось получить?

Я использую настоящую sram с батарейкой. Соответственно количество wait state было выбрано исходя из быстродействия памяти, все остальные задержки по нулям.