[gerber 8]

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

С кэшированием этот механиз имеет мало общего, так как в случае с кэшем отслеживается именно адрес доступа. Поэтому процессор может не иметь механизма кэширования, но запросто иметь отложенную запись.

[murug 0]

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

Вот этому верю, чего-то подобного и ожидал.

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

 

[zltigo 0]

Такие рекомендации исходя из предположения, что значение в ячейке все-таки какой-то программной инициализацией меняется, правильно я Вас понимаю?

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

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

 

 

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

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

 

[aaarrr 68]

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

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

 

Буфер записи мог бы быть у контроллера встроенной SRAM, но:

- Об этом нигде не говорится

- Нет смысла в его наличии

[murug 0]

Да. Такие изменения делает какой-то конкретный кусок кода. Противное было-бы чисто чудом.

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

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

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

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

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

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

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

 

 

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

 

Вот здесь:

Naming Conventions

...

ARMx2z (e.g. ARM720T) indicates cache, MMU & Process ID support

 

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

[aaarrr 68]

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

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

[zltigo 0]

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

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

 

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

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

[aaarrr 68]

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

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

[zltigo 0]

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

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

 

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

 

PCLKSEL0_bit.PCLK_WDT = 1; // далее взводим WDT

WDTC = CCLK / 4 * 5; // на 5 секунд

WDMOD_bit.WDEN = 1;

WDMOD_bit.WDRESET = 1;

WDCLKSEL_bit.WDSEL = 1;

WDFEED = 0xAA;

WDFEED = 0x55;

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

  WDFEED = 0xAA;
  WDFEED = 0x5A;

то есть перезепуск без 5 секунд?

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

[jcxz 191]

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

Давно уже работал с LPC2378, но вроде смутно помнится, что был подобный баг в контроллере прерываний. И он был описан в еррата. И даже в соотв. порту uCOS было указано.

Если это конечно он.

Заключался он в том, что при чтении адреса вектора прерывания из VIC, мог считаться ноль - это ложное прерывание.

Фрагмент моего ISR для IRQ где это проверяется:

ISRirq:         SUB      LR, LR, #4
                STMFD    SP!, {R0-R3, R12, LR}
                MVN      R1, #255            ;VICAddress
                LDR      R0, [R1]
                CMP      R0, #0        ;проверка на ложное IRQ
                STRNE    R1, [R1]            ;acknowlege IRQ
                MOVNE    LR, PC
                BXNE     R0
                CMP      R0, #0
                LDMFDEQ  SP!, {R0-R3, R12, PC}^;выйти если нет сис. вызовов
                ...

[murug 0]

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

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

 

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

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

 

 

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

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

 

[gerber 8]

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

А не описан в руководстве на процессор он, видимо, потому, что имеет отношение скорее к внутренней шине типа AHB, APB, чем к самому ядру. Также как, например, механизм posted write на шине PCI - это фича PCI, а не процессора.

[aaarrr 68]

А не описан в руководстве на процессор он, видимо, потому, что имеет отношение скорее к внутренней шине типа AHB, APB, чем к самому ядру.

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

[zltigo 0]

 

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

 

[murug 0]

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

Мда... есть в документации на 21xx, но нет (либо еще не найдено) на 24xx.

Ну в любом случае вопрос можно считать закрытым.

Спасибо всем, кстати )