Собственно при отладке программы наблюдаю спецэффекты, из которых напрашивается вывод о наличии этого самого кэширования. Оно действительно есть? Если да, то где про него почитать?
По ARM Architecture Reference Manual у меня создалось впечатление, что кэш присутствует у процессоров c MMU либо MPU, а разве LPC2478 к таким относится? В user manual'е на сам МК ни слова не нашел про это.

Сообщение отредактировал murug - Oct 20 2015, 11:30

Классический механизм "posted write" ("отложенная запись"), всё правильно, процессор имеет право не исполнять физическую запись в устройство (в данном случае - это оперативная память) до следующей операции с ним, перед чтением вся очередь записей должна быть исполнена. Причём чтение может быть из любого другого адреса, а не обязательно того, куда производилась запись.
С кэшированием этот механиз имеет мало общего, так как в случае с кэшем отслеживается именно адрес доступа. Поэтому процессор может не иметь механизма кэширования, но запросто иметь отложенную запись.

Вот этому верю, чего-то подобного и ожидал.
Встает вопрос, однако, где можно найти так сказать официальную инфу о наличии такой штуки в ARM7TDMI?

Да. Такие изменения делает какой-то конкретный кусок кода. Противное было-бы чисто чудом. Чудес в 21 веке не бывает. Я лично использую подобный подход - занесение массива данных и считывания его после перезапуска, достаточно широко. Например, в любом моем загрузчике используется область памяти для сохранения картины exception. Тоже пишется массив, записывается сигнатура наличия данных. При запуске основной программы распечатывается. Нималейших проблем, в том числе и на LPC2468.
А чем вызвано фиксированное и причем в очень странном месте - середине памяти месторасположение этой сигнатуры? Нет, это как бы не криминал, но странно. Официально нельзя располагать подобное только в прследних 32 байтах памяти, которые используются заводским загрузчиком.



Нет такой штуки у несчастного ARM7. Не говоря уже о том, что после этой записи контроллер по любому у Вас производит неоднократные записи при манипуляции с WD.

В ядре ничего подобного нет.

Буфер записи мог бы быть у контроллера встроенной SRAM, но:
- Об этом нигде не говорится
- Нет смысла в его наличии

Я бы понял, если бы этот кусок какое-то фиксированное значение в ячейку заносил. Но он угадывает, что там было до последней записи... Что по-моему является еще бОльшим чудом )

А такая ситуация, что после последней записи и перед перезагрузкой нет обращений к on-chip static RAM, у Вас возникает?

Это уже в процессе экспериментов туда переместил, изначально как раз перед упомянутыми 32 байтами было.

Эти записи в область AHB или APB peripherals, а не on-chip static RAM, видимо дело в этом.


Вообще вроде удалось найти инфу (несколько зыбкую), что даже и кэш имеется:

Вот здесь:


А что 2478 - это ARM720T - например вот здесь

Нет, 2478 - это именно ARM7TDMI-S.

Вообще-то сама "перезагрузка" это ВХОД В ЗАВОДСКОЙ загрузчик, где этих обращений явно хватает. Это раз. А то, что Ваши чудотворно действующие нопы это никак не обращение к памяти - это два.


А это ничего, что ПРОИЗВОДИТЕЛЬ конроллера пишет о своем изделии в Product data sheet - ARM7TDMI-S processor, running at up to 72 MHz

Ну, "перезагрузка" - это еще и сброс, который мог бы очистить буфер записи при его наличии.

При наличии - да. Но его нет, а есть напротив куча команд - ну тот-же вечный цикл продолжающийся 5 секунд и команды в нем выпоняющиеся как-бы ничем не хуже несеольких нопов, которые типа "помогают".

Вообще-то таинственные явления в NXP есть - я не далее месяца тому назад в старом модернизируемом изделии на LPC2103 локализовал эффект, кода при работе SPI находящемся в режиме slave и тактирующимся софтовым мастером контроллер прерываний формировал нулевой вектор раз в несколько суток. Ничего из описанного в errata под этот эффект подогнать не удалось. Пришлось предпринимать близкие к шаманским действия


А если к этому добавить:

то есть перезепуск без 5 секунд?
И еще, инициализация WD и в случае Monopoly=FALSE должна производиться при запрещенном прерывании, ибо любое вкоинивание прерывания это мгновенный перезапуск.

Давно уже работал с LPC2378, но вроде смутно помнится, что был подобный баг в контроллере прерываний. И он был описан в еррата. И даже в соотв. порту uCOS было указано.
Если это конечно он.
Заключался он в том, что при чтении адреса вектора прерывания из VIC, мог считаться ноль - это ложное прерывание.
Фрагмент моего ISR для IRQ где это проверяется:

Нет, я же написал, что нопы как раз не помогают.


Полагал, что 720T и TDMI-S - понятия из разных классификаций, собственно из той же пдф, на которую давал ссылку - там указано, что 720T это частный случай ARM7TDMI-S. Ну я сразу написал, что инфа зыбкая.



О, действительно. Спасибо!

Помимо ядра процессора с памятью может работать и периферия, посредством DMA, возможно, сразу несколько каналов. При отсутствии механизма "posted write" процессору после каждого запроса операции чтения/записи пришлось бы ожидать завершения транзакции, открытой каким-нибудь каналом DMA. С чтением ничего не поделаешь - придется ждать, т. к. продолжение программы без прочитанного значения бессмысленно. А запись на дальнейшее исполнение кода не влияет (до ближайшего чтения), поэтому глупо "стоять в очереди" и ждать, когда можно "записать и забыть".
А не описан в руководстве на процессор он, видимо, потому, что имеет отношение скорее к внутренней шине типа AHB, APB, чем к самому ядру. Также как, например, механизм posted write на шине PCI - это фича PCI, а не процессора.

Память, на которой наблюдаются эффект, подключена к локальной шине процессора. Периферия к ней как раз доступа не имеет. Так что смысла нет буферизировать запись.

http://electronix.ru/forum/index.php?showt...=131278&hl=

Мда... есть в документации на 21xx, но нет (либо еще не найдено) на 24xx.
Ну в любом случае вопрос можно считать закрытым.
Спасибо всем, кстати )