k155la3 27 29 декабря, 2016 Опубликовано 29 декабря, 2016 · Жалоба Как правильно сделать программный рестарт в MSP430F5438A ? (IAR, MODEL == LARGE) То, что работало на F2618, не прокатывает: void SystemReStart() { __disable_interrupt(); asm ("push &0xfffe"); asm ("ret"); }; Код этой функции размещен в "за-64К" области. Насколько удается посмотреть на отладчике, после этой процедуры идет влет в пустую область памяти 0xFF. Изменил на asm для 20-битного адреса (pushx.a, reta) - "рояль не заиграл". Ресет успешно выполняется способами - старта WDT - "подсовывания" перехода на команду, находящуюся не в программной памяти а в области адресов регистров (fetch) (?) что может быть не так с "прямым" вызовом push+ret ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
controller_m30 1 29 декабря, 2016 Опубликовано 29 декабря, 2016 (изменено) · Жалоба Сам пока не пробовал делать программный reset, но вот что нашел. Сброс контроллера можно вызвать: 1. Сброс PUC происходит при записи в FCTL1 (Flash Memory Controller) пароля, отличного от 0xa5. 2. Тоже при неправильном пароле для WDTCTL, отличном от 0х5а. 3. Тоже самое для регистра PMMCTL0 (отличие пароля от 0ха5). 4. Ещё в регистре PMMCTL0 есть биты PMMSWPOR и PMMSWBOR, которые программно (если правильно понял) вызывают Reset типа POR и BOR соотв. 5. При выборке команды из адресного пространства ввода/вывода. А чего оно не выбирает адрес сброса... Можно после команды asm ("push &0xfffe") посмотреть отладчиком, что на вершине стека оказалось. Или, чтоб не искать ту вершину стека, следующей-же командой снять данные с вершины в какой-нить регистр (напр. asm ("pop r4")), и посмотреть, что оказалось в регистре (PC ведь тоже регистр - R0, так что разница только в номере). Ещё варианты без обращения в стек: mov &0xfffe,r14 mov r14,PC ;-------------- или так mov #0xfffe,r14 mov @r14,PC ;------------- или совсем напрямую mov &0xfffe,PC Изменено 29 декабря, 2016 пользователем controller_m30 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
amiller 2 30 декабря, 2016 Опубликовано 30 декабря, 2016 · Жалоба Мне кажется поиск уникальных особенностей процессора для того, чтобы вызвать фатальное исключение - тупиковый путь. Да и зачем? Программный reset весьма редкая и не требующая скорости операция. Это не то место, которое нужно оптимизировать. Чем Вам не нравится сброс через таймер-сторож? Этот способ уж точно работает на всех архитектурах. Даже там, где нет встроенного WDT, всё равно ведь придётся ставить внешний WDT, без него никак. Я лично просто запрещаю сброс WDT и жду reset. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 27 30 декабря, 2016 Опубликовано 30 декабря, 2016 (изменено) · Жалоба ... Сброс контроллера можно вызвать: 1. Сброс PUC происходит при записи в FCTL1 (Flash Memory Controller) пароля, отличного от 0xa5. 2. Тоже при неправильном пароле для WDTCTL, отличном от 0х5а. 3. Тоже самое для регистра PMMCTL0 (отличие пароля от 0ха5). 4. Ещё в регистре PMMCTL0 есть биты PMMSWPOR и PMMSWBOR, которые программно (если правильно понял) вызывают Reset типа POR и BOR соотв. 5. При выборке команды из адресного пространства ввода/вывода. . . . . По Вашей номерации на F5438A у меня отрабатывает (2) и (5). Я остановился на (5). Выглядит ОНО так (из техасских примеров) ((void (*)())0x350)(); Для решения задачи, думаю, следует использовать WDT в штатном режиме (2) но вариант с (5) более "компактен". Предложенные Вами варианты "отлова" проверю. Спасибо за инф. По ушлости характера я не могу остваить это "простотак" :) (1) Мне кажется поиск уникальных особенностей процессора для того, чтобы вызвать фатальное исключение - тупиковый путь. (2) Да и зачем? Программный reset весьма редкая и не требующая скорости операция. (3) Чем Вам не нравится сброс через таймер-сторож? Этот способ уж точно работает на всех архитектурах. . . . . (1) да вроде исключение/ресет по выборке команды "неоттуда" это далеко не уникальная особенность. Почему бы ей не воспользоваться ? (2) тут я с Вами категорически не согласен. Как минимум 3 вызова. - мне через внешний терминал (USART) надо (ну так получилось) рестатануть прибор. - после перепрошивки FW требуется рестарт - в процессе работы прибора софт начинает понимать, что "все пропало" и единственный шанс на нормализацию работы - рестарт. (каким образом это будет сделано - не принципиально) (3) WDT полностью устраивает. ps - вот разбор причин рестарта для F5438A (может кому потребуется) int main(void) { WDTCTL = WDTPW | WDTHOLD; switch ( __even_in_range( SYSRSTIV, SYSRSTIV_PMMKEY ) ) { case SYSRSTIV_NONE: ResetSign = 0x00; break; // No Interrupt pending case SYSRSTIV_BOR: ResetSign = 0x01; break; // BOR case SYSRSTIV_RSTNMI: ResetSign = 0x02; break; // RST/NMI case SYSRSTIV_DOBOR: ResetSign = 0x03; break; // Do BOR case SYSRSTIV_LPM5WU: ResetSign = 0x04; break; // Port LPM5 Wake Up case SYSRSTIV_SECYV: ResetSign = 0x05; break; // Security violation case SYSRSTIV_SVSL: ResetSign = 0x06; break; // SVSL case SYSRSTIV_SVSH: ResetSign = 0x07; break; // SVSH case SYSRSTIV_SVML_OVP: ResetSign = 0x08; break; // SVML_OVP case SYSRSTIV_SVMH_OVP: ResetSign = 0x09; break; // SVMH_OVP case SYSRSTIV_DOPOR: ResetSign = 0x0A; break; // Do POR case SYSRSTIV_WDTTO: ResetSign = 0x0B; break; // WDT Time out case SYSRSTIV_WDTKEY: ResetSign = 0x0C; break; // WDTKEY violation case SYSRSTIV_KEYV: ResetSign = 0x0D; break; // Flash Key violation case SYSRSTIV_PLLUL: ResetSign = 0x0E; break; // PLL unlock case SYSRSTIV_PERF: ResetSign = 0x0F; break; // peripheral/config area fetch case SYSRSTIV_PMMKEY: ResetSign = 0x10; break; // PMMKEY violation = (0x0020u) = SYSRSTIV_PSSKEY default: ResetSign = 0xFF; break; } Изменено 30 декабря, 2016 пользователем k155la3 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MrYuran 23 30 декабря, 2016 Опубликовано 30 декабря, 2016 · Жалоба jmp reset не катит? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 27 30 декабря, 2016 Опубликовано 30 декабря, 2016 · Жалоба jmp reset не катит? Шас проверил еще раз (только на отладчике) (controller_m30) или совсем напрямую mov &0xfffe,PC а тк код сишный __no_operation(); << BP asm("mov &0xfffe,PC"); Прошагал отладчиком по asm - все ресетится. Проверю еще на Release. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 27 30 декабря, 2016 Опубликовано 30 декабря, 2016 · Жалоба Шас проверил еще раз (только на отладчике) (controller_m30) или совсем напрямую mov &0xfffe,PC а тк код сишный __no_operation(); << BP asm("mov &0xfffe,PC"); Прошагал отладчиком по asm - все ресетится. Проверю еще на Release. ====== Исследования показали, что переход по ресету проходит (на адрес, куда указывает ресетный вектор) и далее в начало main(). По непонятной для меня причине при таком "ресете" происходит зацикл в ф-ии инициализации UCS (тактовой системы). При ресете через WDT, fetch или аппаратном - этот блок не циклит. . . . . do { UCSCTL7 &= ~( XT2OFFG + XT1LFOFFG + XT1HFOFFG + DCOFFG); // Clear XT2,XT1,DCO fault flags __no_operation(); SFRIFG1 &= ~OFIFG; // Clear fault flags } while ( SFRIFG1 & OFIFG ); // Test oscillator fault flag . . . . (функция XT2 выводов отключена, генератор XT2 не исползуется и физически кварца нет) Упорно устанавливается (при программном ресете по JMP) флаг XT2OFFG в UCSCTL7 и соотв-но общий флаг (SFRIFG1 & OFIFG). Делаю для себя вывод, что для такого "рестарта" требуется начальная подготовка процессора, чтобы все прошло корректно. (установка UCS и возможно, PMM в определенное состояние) Итак. Ресетится проще всего: (1) - через WDT (2) - через peripheral/config area fetch Шас использую (2), потом переделаю на (1) (сугобо IMHO) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
093 0 12 сентября, 2017 Опубликовано 12 сентября, 2017 · Жалоба Вот такой способ работает на MSP430F5438A: PMMCTL0 |= PMMSWBOR; Вход в BSL при этом не будет происходить, регистры обнулятся. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться