Кэширование записи в RAM в LPC2478? Опции

[murug]

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

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

[aaarrr]

У ARM7TDMI нет ни кэша ни буфера записи.

[murug]

У ARM7TDMI нет ни кэша ни буфера записи.

Ну я это подозревал. Тогда придется изложить, что же я наблюдаю.

Код такой

В *.h-файле:

Код

__no_init volatile unsigned long ForceReprogrammingSignature @ 0x40008000;

В *.cpp-файле функция:

Код

void ForceReprogramming(bool Monopoly)
{
  ForceReprogrammingSignature = 0x085D0B75;
  
//  asm("nop"); // маленькая задержка в пять ассемблерных команд - если раскомментировать, не помогает (возвращается старое значение)
//  asm("nop");
//  asm("nop");
//  asm("nop");
//  asm("nop");
  
//  volatile unsigned long x = ForceReprogrammingSignature; // чтение (в ассемблере две команды) - если раскомментировать, помогает (сохраняется записанное значение)

//  vTaskDelay(10/portTICK_RATE_MS); // большая задержка в 10 мс - если раскомментировать, помогает (сохраняется записанное значение)

  if (Monopoly)
      __disable_interrupt(); // при Monopoly == true запрещаем прерывания

  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;

  if (Monopoly) // при Monopoly == true из функции не возвращаемся
      while (1);
}

Так вот, изначально в ForceReprogrammingSignature некое значение, назовем его "старым значением". Далее разные варианты:
1. Вызываем ForceReprogramming(false), она записывает в ForceReprogrammingSignature сигнатуру 0x085D0B75, назовем это "записанное значение", запускает WDT, возвращается, через 5 секунд программа перезапускается, видим в ForceReprogrammingSignature "записанное значение", все ок, вопросов нет.
2. Вызываем ForceReprogramming(true), она записывает в ForceReprogrammingSignature сигнатуру, без задержки запрещает прерывания (тем самым в частности останавливает планировщик FreeRTOS), запускает WDT, виснет в бесконечном цикле, через 5 секунд программа перезапускается, видим в ForceReprogrammingSignature "старое значение", офигеваем.
3. Вызываем ForceReprogramming(true) с раскомментированной задержкой на 10 мс, она записывает в ForceReprogrammingSignature сигнатуру, через 10 мс запрещает прерывания, запускает WDT, виснет в бесконечном цикле, через 5 секунд программа перезапускается, видим в ForceReprogrammingSignature "сохраненное значение".
4. Вызываем ForceReprogramming(true) с закомментированной задержкой на 10 мс, но с раскомментированным чтением, она записывает в ForceReprogrammingSignature сигнатуру, тут же считывает ее (две ассемблерные команды), запускает WDT, виснет в бесконечном цикле, через 5 секунд программа перезапускается, видим в ForceReprogrammingSignature "сохраненное значение".
5. Вызываем ForceReprogramming(true) с закомментированными задержкой на 10 мс и чтением, но с раскомментированной задержкой из пяти nop'ов, она записывает в ForceReprogrammingSignature сигнатуру, выполняет 5 пустых команд, запускает WDT, виснет в бесконечном цикле, через 5 секунд программа перезапускается, видим в ForceReprogrammingSignature "старое значение".

Вот и создается такое впечатление, как будто оператор

Код

ForceReprogrammingSignature = 0x085D0B75;

пишет физически в кэш, и если после этого сразу отключить прерывания, то значение из кэша не успевает сброситься в "настоящий" RAM, поэтому после перезагрузки по WDT снова читаем оттуда старое значение. Звучит бредово, поэтому ищу другую версию )

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

[jcxz]

2. Вызываем ForceReprogramming(true), она записывает в ForceReprogrammingSignature сигнатуру, без задержки запрещает прерывания (тем самым в частности останавливает планировщик FreeRTOS), запускает WDT, виснет в бесконечном цикле, через 5 секунд программа перезапускается, видим в ForceReprogrammingSignature "старое значение", офигеваем.

И что?
Очевидно, что startup инитит эту Вашу ForceReprogramming неким значением, либо эта область используется ROM-загрузчиком, либо используется самим startup на какие-то его нужды, ...
Эксперимент проведён некорректно. Читайте юзермануал на предмет: какие области используются ROM-загрузчиком. И ставьте бряк не в функции main(), а сразу после вектора сброса.
Чудес не бывает.

[murug]

И что?
Очевидно, что startup инитит эту Вашу ForceReprogramming неким значением, либо эта область используется ROM-загрузчиком, либо используется самим startup на какие-то его нужды, ...
Эксперимент проведён некорректно. Читайте юзермануал на предмет: какие области используются ROM-загрузчиком. И ставьте бряк не в функции main(), а сразу после вектора сброса.
Чудес не бывает.

По-моему Вы невнимательно читали. В переменной ForceReprogrammingSignature восстанавливается значение, которое там было до вызова функции ForceReprogramming. Каким бы это значение не было.
Ну и помимо того:
1. переменная помечена __no_init;
2. секция, в которую она помещена, указана для линкера do not initialize;
3. бряк ставил на первые выполняемые ассемблерные команды, уже там видел в отладчике "старое" значение в ForceReprogrammingSignature;
4. пробовал размещать переменную по двум разным адресам, результат один и тот же;
5. ну и в конце концов в случае описанных заплаток-то значение сохраняется.

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

Попробую.
Кстати, вспомнил - под отладчиком видел что внутри функции сигнатура 0x085D0B75 в переменную кладется. А вот после перезагрузки в самом начале cstartup.s - уже снова старое значение.

[zltigo]

...видел в отладчике "старое" значение в ForceReprogrammingSignature;

То есть весь этот вынос мозга Вы устраиваете по причине того, что сие оказывается "видит" отладчик?!

[murug]

То есть весь этот вынос мозга Вы устраиваете по причине того, что сие оказывается "видит" отладчик?!

Не совсем.
То, что в ячейке "старое" значение, я вижу и без отладчика, но смотрю уже не на этапе выполнения cstartup.s, а после, когда все инициализации прошли и работает графический интерфейс у программы.

[zltigo]

Не совсем.
То, что в ячейке "старое" значение, я вижу и без отладчика, но смотрю уже не на этапе выполнения cstartup.s, а после, когда все инициализации прошли и работает графический интерфейс у программы.

Тем неменее
1) Никаких отладчиков для разборок с эффектом НЕ применять.
2) Никаких отображений далеко после старта через графический интерефейс - тоже.
Тупо и просто в startup НИЧЕГО сложнее, чем изменить состояние какого-нибудь пина не предпринимать. Причем изменеие состояния пина обязательно контролировать по времени от снятия сброса с контроллера.

[murug]

Тем неменее
1) Никаких отладчиков для разборок с эффектом НЕ применять.
2) Никаких отображений далеко после старта через графический интерефейс - тоже.
Тупо и просто в startup НИЧЕГО сложнее, чем изменить состояние какого-нибудь пина не предпринимать. Причем изменеие состояния пина обязательно контролировать по времени от снятия сброса с контроллера.

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

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

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

[zltigo]

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

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

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

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

[murug]

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

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

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

А такая ситуация, что после последней записи и перед перезагрузкой нет обращений к 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 - например вот здесь

[zltigo]

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

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

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

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

[aaarrr]

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

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

[zltigo]

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

При наличии - да. Но его нет, а есть напротив куча команд - ну тот-же вечный цикл продолжающийся 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;

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

CODE

  WDFEED = 0xAA;
  WDFEED = 0x5A;

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

[jcxz]

Вообще-то таинственные явления в 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}^;выйти если нет сис. вызовов
                ...

[zltigo]

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

Посмотрел еще раз в свежайшие errata - увы, ничего подобного не описано.

И даже в соотв. порту uCOS было указано.

Очень бы хотелось взглянуть на то, что в uCOS написано. Это было просто в исходниках откомментировано, или какой то документ?

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

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

Часто в векторе IRQ стоит что-то вроде LDR PC,[PC, #-xxx]. Оптимальнее будет ложный нулевой адрес "ловить" в ResetVector-е по значению младших пяти бит CPSR, равных режиму IRQ.

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