Приветствую!
Хочу реализовать программный сброс процессора, но не могу подобрать нужную команду.

Можно сделать что-то типа:

программа должна перезапуститься, но в моём случае не работает (только перейдёт на Entry и куда-то улетит), как понимаю надо ещё что-то почистить или сбросить, сделать аналог "System Reset" из CCS и перезапустить программу.

А как сделать, чтобы программа перешла на адреса встроенного ROM загрузчика и уже в соответствии с выбранным режимом загрузки перезагрузила прошивку и стартанула её?
Пока что-то не получается

Используйте встроенный сторожевик для сброса.

Это можно, но хочется чтобы была команда, которая приходит, например, по ethernet. Как-то ведь можно, используя ассм, это сделать (всегда делал для других процов от TI). Нужно только описать переход на адрес, думаю, адрес ROM загрузчика 0xFFFD0000 должен подойти, но пока не могу разобраться, какую команду (или несколько команд) использовать.
Например для с28346 было:

Вопрос, как сделать для данного процессора нечто подобное?

Пришла команда - пишете в WD недопустимую последовательность - сразу получаете аппаратный RESET.
В чём проблема?
Обратите внимание на выделенное жирным. Это в 100 раз надёжнее и достовернее любых программных рестартов, так как заведомо переводит весь МК в начальное состояние.
Чего Вы своим программным переходом не делаете.

Попробую такой вариант, спасибо, но всё же интересно, как ассмом можно его перенаправить на ROM загрузчик?
Пока делаю так:

попадаем:

Как правильно написать то, что после RstHandler: ?

Да, мне кажется (возможно ошибаюсь), если перейти на код и заставить выполниться встроенный ROM-загрузчик, то это и будет аналог аппаратного сброса???

Восстановить состояние регистров управления процессором в исходное состояние (такое, какое должно быть после подачи сигнала RESET).
Восстановить состояние периферии на исходное (прерывание, управление питанием, PLL, MPU/MMU, кеши и т.п.).
...(что-то ещё восстановить).
И только после этого можно делать RESET.

Я уже Вам написал что это в 100 раз сложнее чем 2 строчки которые у Вас, а Вы не верите....

Тут понятно, что это должно быть сделано. Поэтому мой переход на Entry и не запускается, что что-то там (всё) не очищено и не сброшено в начальное состояние.


Тут я понял, что использовать WD - это проще, но вот пока ещё хочется понять как его загнать на адреса встроенного загрузчика.
Две строчки - это рестарт того, что уже лежит в RAM, а вот две строчки, которые перенаправят его на встроенный загрузчик, думаю, спасли бы ситуацию, но пока не пойму какие команды и как использовать.

Это несложно.
Для Thumb-2 системы команд (Cortex-M):

Для ARM-системы команд - с ноликом в мл. бите.

Спасибо, то что надо. Это работает (прошивку перезаливает), но надо ему ещё что-то "обнулить", а то не стартанёт нормально загруженную прошивку. Не подскажете, что конкретно?


Нашёл кусок кода, что ему мешает после перезагрузки прошивки с внешней SPI-флэшки нормально работать. Проблема старая (спрашивал тут(сообщение №69), но никто не ответил), во всём оказывается виноват McBSP и его прерывания. Пробовал чистить все его регистры (McBSP), но не помогает, ещё что-то надо стереть. Что? Если убрать настройку прерываний от McBSP, то приведённый выше код перезальёт прошивку и она нормально запустится.

Ещё хочу спросить, что неправильно в моём коде и почему он не хочет компилиться?
Выше приводил переход на RstHandler: , это работает. Далее пытался сделать:

, но это компилиться не хочет, пишет
.
Почему так? Если нажму кнопку Reset на плате, процессор станет на адрес 0xFFFF0000.
Смотрю дизассм и вижу:

, т.е. что я и пытался сделать, используется та же инструкция, почему в моём случае не захотело компилиться?
Если далее нажму "F5" в CCS, то перейдёт на адрес 0xFFFD0000, где ещё один бранч на следующий адрес.
Где может быть проблема?

B - это прямой переход. В команде адрес назначения кодируется как смещение к PC.
А Вам нужен косвенный (BX):
LDR R0, p1
BX R0

для IAR:
p1 DC32 0xFFFD0000
для CCS:
p1 .long 0xFFFD0000
(если Thumb-2 - не забываем про мл. бит)

PS: Что ещё надо проинитить я не знаю. Не знаком с данным МК.

Проблема в расстоянии от команды перехода до точки назначения. Для далеких переходов следует использовать нечто типа:

LDR PC, JmpAddr

JmpAddr: .word 0xFFFD0000

или, если предполагается переключение ARM <=> THUMB, то

LDR R0, JmpAddr
BX R0
JmpAddr: .word 0xFFFD0000



UPD:
А вообще, я бы покопал на тему захода в SwRstDisable ARM-а (PSC0/LPSC14) - это было бы пожестче, если реализуемо.

Спасибо, почитал, кто такой , получается - это и есть переход на адрес, который содержится в Rm (затупил, несколько раз просматривал все бранчи, но не нашёл нужную инструкцию).
Тогда не понимаю почему после ресета по адресу 0xFFFF0000 лежит просто (согласно дизассму CCS), ведь это НЕПРАВИЛЬНАЯ инструкция!!?? Ведь B - это переход на label, а константа 0xFFFD0000 и будет для него illegal operand??? Или здесь он уже пересчитал адрес label и показал куда будет переходить?

Остаётся "старый" вопрос, что нужно почистить/занулить/сбросить, чтобы программа нормально стартовала после перезагрузки? Пытаюсь разобраться, если кто подскажет, буду благодарен.

Я выше написал - весь вопрос в расстоянии от команды перехода до точки, куда переходить. На "короткие" расстояния - дотягивает команда B/BX label. На длинные - уже B/BX Rx нужна, или LDR PC,xxxx

Не заметил Ваш пост выше

Это тоже работает, спасибо, не мог понять, как в программный счётчик запихнуть адрес 0xFFFD0000, пробовал почти то что и надо LDR PC, 0xFFFD0000, но немного не то


Тут что-то не понимаю, как оно может скомпилить код B 0xFFFD0000? Или это только то что я вижу в CCS Disassembly, на самом деле было что-то типа:


, где boot_label = 0xFFFD0000?

любая метка есть символьное обозначение какого-то, вполне определенного, числа... Это эквивалентно, что метку поставить, что метку определить через .set, что число указать. Однако, если комипилятор видит, что инструкция "не дотянется" до адреса, он ее и обругает.

А LDR можно еще написать как

LDR PC, =0xFFFD0000

компилятор должен сам это переделать в

LDR PC,label

[.....]
label: .word 0xFFFD0000

Счас понял, о чём Вы говорите. Я пытался сделать
,
но это неправильный синтаксис и оно ругалось. Можно сделать правильно:

, скомпилится, попробует перейти, но т.к. куда-то очень далеко - вылетит. Получается в коде из BootRoma и есть такой код, но там короткий переход, а отображается просто адрес. Спасибо.


А вот это я пробовал и ещё раз проверил, не компилится оно у меня!?

Да, скорей всего именно так. Он просто Вам показывает целевой адрес. Если-бы он показывал смещения (как в коде команды) было-бы очень неудобно высчитывать куда направлен переход.

BootRom: .long.set 0xFFFD0000
B BootRom

а что с "=" не компилируется, это уже компиляторозависимо. Не каждый транслятор это поймет.


UPD
или, вот так (GNU-тый as):
.set BootRom, 0xFFFD0000
я путаю разные синтаксисы от разных ассемблеров...

Затестил, всё просто, работает без очистки и установки регистров в начальное состояние.
Но, всё равно ещё интересно, что надо обнулять для нормального перезапуска и это:

проверил - компилируется (компилятор gcc 4.7.7, ассемблер из него)....

LDR PC, =0xFFFD0000

листинг:



отлично видно, что число 0xFFFD0000 он сам разместил в конце как слово данных. Кодов операции нету, что тоже понятно, их линкер только сформирует.


Надо, как минимум, перевести все LPSC в состояния "power-on", по сути, обресетить периферию.

У меня компилер TI v5.1.1 в настройках пректа стоит, наверное, поэтому и не компилится данная инструкция.


Попробовал перед переходом на BOOTROM загнать все PSC модули в состояние SwRstDisable state, работает, но иногда, при нескольких последовательных ресетах может повиснуть.

Ну надо не все, а по списку из TRM, только те, которые по дефолту в этом состоянии.

Ну не совсем все, SPI1 оставил - с него прошивка грузится и при его состоянии SwRstDisable загрузчик перестаёт работать, хотя должен был бы сам настроить его в нужное состояние (Enable). Проверю ещё кто должен быть по дефолту в состоянии сброса, спасибо.

Логично, но почему-то до бутописателей это не доходит....
Сам сталкивался на OMAP L137 с подобной проблемой:
Загрузка идёт с внешней SPI-Flash микросхемы, после старта firmware и чтения конфига с той-же flash, перевожу её командой в Power Down (вроде ведь логично если такая функция есть в микросхеме и она больше не нужна ?). Но после этого, если подать HW RESET на OMAP, он больше не грузится с flash (грузится только после выкл./вкл. питания).
Если не подавать Power Down, то всё ок (а если она в Power Down, то она не отвечает ни на какие команды до команды Power Up).
Значит писатели встроенного бутлоадера не додумались, что флешка может быть в Power Down. (((((
А вроде такая очевидная вещь....

Согласно даташиту на мой процессор, его SPI1 по дефолту находится в состоянии SwRstDisable. Вот тут-то и вопрос - кто его загнал в это состояние? Если это ROM загрузчик до передачи управления моей программе (т.е. для ROM загрузчика дефолтное состояние - включено), тогда всё понятно, если я его выключаю и передаю управление ROM загрузчику, то он и дохнет. Но если дефолтное состояние SwRstDisable - это для загрузчика, то он должен включать данный модуль и моё выключение на него влиять не должно.

Скорее всего, загрузчик считывает, что за резет был, и если это не POR, то делает значительно меньше инициализаций. Однако, без дизассемблера это не понять.