STM32: сброс всей периферии перед переходом из загрузчика в основную прошивку Опции

[k000858]

Достаточно ли отключить тактирование определенной шины, что бы сбросить всю периферию, сидящую на этой шине?

К примеру как это предлагается делать в HAL библиотеках:
RCC->APB1RSTR = 0xFFFFFFFF; // FORCE_RESET
RCC->APB1RSTR = 0x00; // RELEASE_RESET

[adnega]

Достаточно ли отключить тактирование определенной шины, что бы сбросить всю периферию, сидящую на этой шине?

К примеру как это предлагается делать в HAL библиотеках:
RCC->APB1RSTR = 0xFFFFFFFF; // FORCE_RESET
RCC->APB1RSTR = 0x00; // RELEASE_RESET

Есть регистр, отвечающий за тактирование, а есть регистр, отвечающий за сброс периферии. Вы их не путаете?

[k000858]

Есть регистр, отвечающий за тактирование, а есть регистр, отвечающий за сброс периферии. Вы их не путаете?

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

т.е. записав в эти регистры, сбросится вся периферия, сидящая на шине?

[scifi]

Самый кошерный способ - это сбросить МК полностью и сразу после сброса перейти в основную прошивку. Собственно, так я всегда и делаю.

[Axel]

Отключение тактирования точно ничего не сбрасывает. Так что - или регистры RSTR, или общий ресет.

[k000858]

Самый кошерный способ - это сбросить МК полностью и сразу после сброса перейти в основную прошивку. Собственно, так я всегда и делаю.

тогда попутный вопрос: при сбросе мк с помощью функции NVIC_SystemReset (из core_cm4.h CMSIS библиотеки) происходит полный сброс контроллера, включая сброс периферии (особенно интересуют прерывания) ?

[scifi]

тогда попутный вопрос: при сбросе мк с помощью функции NVIC_SystemReset (из core_cm4.h CMSIS библиотеки) происходит полный сброс контроллера, включая сброс периферии (особенно интересуют прерывания) ?

Да.

[k000858]

а есть способ запретить все прерывания, а не одно какое то конкретное?

[Golikov A.]

глобальным флагом?
#define INTERRUPT_DISABLE_STORE(flag1, flag2) (flag1) = __disable_irq(); (flag2) = __disable_fiq()
#define INTERRUPT_RESTORE(flag1, flag2) if(!(flag1)) __enable_irq(); if(!(flag2)) __enable_fiq()

[k000858]

глобальным флагом?
#define INTERRUPT_DISABLE_STORE(flag1, flag2) (flag1) = __disable_irq(); (flag2) = __disable_fiq()
#define INTERRUPT_RESTORE(flag1, flag2) if(!(flag1)) __enable_irq(); if(!(flag2)) __enable_fiq()

а. т.е. функция __disable_irq(); запрещает все прерывания?

[Golikov A.]

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

[scifi]

__disable_fiq() - остальные

Какой такой fiq? Это же Cortex-M, нет там никакого fiq. Уважаемый, не вводите общественность в заблуждение.

[Golikov A.]

я просто не в курсе, неужели STM32 - это только кортексы М? ну нет фик, и нет, плохого ничего не будет, можете запрещать, можете не запрещать

[A. Fig Lee]

тогда попутный вопрос: при сбросе мк с помощью функции NVIC_SystemReset (из core_cm4.h CMSIS библиотеки) происходит полный сброс контроллера, включая сброс периферии (особенно интересуют прерывания) ?

А каким образом по ресету Вы собираетесь переходить в основную программу?
Загрузчик разве не по начальному аддрессу?
Так Вы туда опять и попадете

[scifi]

А каким образом по ресету Вы собираетесь переходить в основную программу?
Загрузчик разве не по начальному аддрессу?
Так Вы туда опять и попадете

Это же совсем просто: в самом начале загрузчика проверять специальный флаг и прыгать в основную прошивку или продолжать выполнять загрузчик.

[adnega]

Это же совсем просто: в самом начале загрузчика проверять специальный флаг и прыгать в основную прошивку или продолжать выполнять загрузчик.

При этом не тронув никакой периферии.

[Golikov A.]

специальный флаг, целостность прошивки, и какие - либо коды безопасности....

[_Артём_]

Какой такой fiq? Это же Cortex-M, нет там никакого fiq.

Как же нет? А это что:

Код

/** \brief  Disable FIQ

    This function disables FIQ interrupts by setting the F-bit in the CPSR.
    Can only be executed in Privileged modes.
*/
#define __disable_fault_irq               __disable_fiq

?

[scifi]

Как же нет? А это что:

А это какая-то чушь (очевидно, перекочевала из кода для других процессоров ARM). Просто подтверждает, что этот код пишут простые смертные, вполне способные ошибаться.

[A. Fig Lee]

Это же совсем просто: в самом начале загрузчика проверять специальный флаг и прыгать в основную прошивку или продолжать выполнять загрузчик.

Флаг в EEPROM?
А почему сразу не прыгнуть? К чему эти танцы с бубном, если и так ясно что прыгать будем?

специальный флаг, целостность прошивки, и какие - либо коды безопасности....

А при чем здесь reset?
Программа бутлоадер стартанула, все проверила, теперь выставляет флаг, чтобы прыгнуть и делает ресет?
Бессмыслица

[ViKo]

Это какой-то "мудрец" переименовал fast_interrupt от ARM в fault_interrupt для Cortex-M.

[Golikov A.]

поглядел доки на кортекс - м
http://infocenter.arm.com/help/index.jsp?t...b/CHDBIBGJ.html
нашел только
PM
Prioritizable interrupt mask:
0 = no effect.
1 = prevents the activation of all exceptions with configurable priority.

то есть Reset, NMI, HardFault задушить этим битиком нельзя...

HardFault душиться егойным регистром
http://infocenter.arm.com/help/index.jsp?t...a/Cihieffb.html

Reset понятно никак не душиться,

[_Артём_]

А это какая-то чушь (очевидно, перекочевала из кода для других процессоров ARM).

Почему чушь? Код вполне имеет смысл:

Код

__attribute__( ( always_inline ) ) static __INLINE void __enable_fault_irq(void)
{
  __ASM volatile ("cpsie f");
}


/** \brief  Disable FIQ

    This function disables FIQ interrupts by setting the F-bit in the CPSR.
    Can only be executed in Privileged modes.
*/
__attribute__( ( always_inline ) ) static __INLINE void __disable_fault_irq(void)
{
  __ASM volatile ("cpsid f");
}

[Golikov A.]

А при чем здесь reset?
Программа бутлоадер стартанула, все проверила, теперь выставляет флаг, чтобы прыгнуть и делает ресет?
Бессмыслица

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

Почему чушь? Код вполне имеет смысл:

http://infocenter.arm.com/help/index.jsp?t...ch02s08s01.html

это от 7 арма...

в кортаксах - м только
CPSID i
http://infocenter.arm.com/help/index.jsp?t...a/BABHBAAB.html

[_Артём_]

поглядел доки на кортекс - м
http://infocenter.arm.com/help/index.jsp?t...b/CHDBIBGJ.html
нашел только
PM
Prioritizable interrupt mask:
0 = no effect.
1 = prevents the activation of all exceptions with configurable priority.

Не там смотрите: нужно в описании Cortex-M3 или M4 смотреть.

2.8. FAULTMASK register bit assignmentsBits Name Function
[31:1] - Reserved
[0] FAULTMASK
0 = no effect
1 = prevents the activation of all exceptions except for NMI.
The processor clears the FAULTMASK bit to 0 on exit from any exception handler except the NMI handler.

[Golikov A.]

все там
просто ссылки криво вставляются... я постом выше поправил ссылки...

в кортаксах - м только

CPSID i
http://infocenter.arm.com/help/index.jsp?t...a/BABHBAAB.html

отключает все крмое NMI и RESET, странно что про HardFault не упомянуто...

О прошу прощения. Чет криво у них написано, если взять набор инструкций кортекса м3

Examples
CPSID i ; Disable interrupts and configurable fault handlers (set PRIMASK)
CPSID f ; Disable interrupts and all fault handlers (set FAULTMASK)
CPSIE i ; Enable interrupts and configurable fault handlers (clear PRIMASK)
CPSIE f ; Enable interrupts and fault handlers (clear FAULTMASK).

[adnega]

Биты состояния прерывания (I и F) были заменены новым регистром PRIMASK (однобитный регистр, который будучи установлен в 1, разрешает генерацию только немаскируемого прерывания и исключения HardFault; все остальные прерывания и исключения маскируются).

Читаем Джозефа Ю.

[scifi]

Почему чушь? Код вполне имеет смысл:

Код имеет смысл, а вот комментарий не имеет:

This function disables FIQ interrupts by setting the F-bit in the CPSR.

Про комментарий я и написал - это чушь.

[Golikov A.]

вот хрень какая-то, что же их официальный сайт то никак не определиться:?

ну то есть надо понимать что осталось одно
__disable_irq();
которое глушит все кроме ресета и NMI?

[A. Fig Lee]

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

Не будет "со всеми регистрами".
Флаг надо както передать. EEPROM?
Его надо будет както прочтать, значит инициализировать регистры, сделать какието действия,
то есть все равно ни как про ресете.

[Golikov A.]

ножка? Одна единственная на кнопке? Которая и в основной программе остается такой же?

Ну вообще да флаг через EEPROM, Еще PLL настроить, но это делается и в основной проге, просто данный момент пропускается...

[scifi]

Флаг надо както передать. EEPROM?

Зачем EEPROM? При "теплом" сбросе содержимое ОЗУ на чипе сохраняется.

[A. Fig Lee]

ножка? Одна единственная на кнопке? Которая и в основной программе остается такой же?

Ну вообще да флаг через EEPROM, Еще PLL настроить, но это делается и в основной проге, просто данный момент пропускается...

Не только ножка. Состояние прерываний остается тем же.
То есть, если они запрещены, то в основной программе надо explicitly разрешать.
По прежнему не вижу большого смысла в выполенении ресета

Зачем EEPROM? При "теплом" сбросе содержимое ОЗУ на чипе сохраняется.

А в чем разница?
Разве не по офному и тому же аддрессу переход происходит пристарте?
Каким волшебным образом при холодном старте обнуляется RAM, если
не самой программой?

[Golikov A.]

от ресета внутренне спокойно...


вот что кеил написал в хелпе

__disable_fiq

Typically, this intrinsic disables FIQ interrupts by setting the F-bit in the CPSR. However, for v7-M it sets the fault mask register (FAULTMASK). FIQ interrupts are not supported in v6-M.

то есть на самом деле это от 7 армов тянется, и несмотря что FIQ сменилось с быстрых на ошибочные, это все равно не для кортексов М

[_Артём_]

ну то есть надо понимать что осталось одно
__disable_irq();
которое глушит все кроме ресета и NMI?

Почему? __disable_irq() это :

Код

CPSID i ; Disable interrupts and configurable fault handlers (set PRIMASK)

HardFault не запрещается после __disable_irq.
HardFault запретится после CPSID f.
Вроде так выходит...

А в чем разница?
Разве не по офному и тому же аддрессу переход происходит пристарте?
Каким волшебным образом при холодном старте обнуляется RAM, если
не самой программой?

Обнуляется программой...Можно зарезервировать ячейку в ОЗУ и проверять её на старте и в зависимости от её значения решать что делать дальше - запускать программу, запускать бут или ещё что-то.

[ViKo]

Из User Guide на Cortex-M

Эскизы прикрепленных изображений

 

[Golikov A.]

путано написано, в описании на проц LPC1768, в части про кортекс м3 есть запись про HARDFAULTMASK, в наборе инструкций кортекса м3 есть такое... В описании на серию кортексов М0-4, нету... даже нет HardFaule Mask регистра....

и как это понимать?
поправочка-------------

http://infocenter.arm.com/help/index.jsp?t...a/CHDBIBGJ.html
у М3, и М4 есть, называется FAULTMASK, и флажочек тоже есть

The FAULTMASK register prevents activation of all exceptions except for Non-Maskable Interrupt (NMI). See the register summary in Table 2.2 for its attributes. The bit assignments are:

получается его одного достаточно чтобы все выключить? даже примаск?

[_Артём_]

путано написано, в описании на проц LPC1768, в части про кортекс м3 есть запись про HARDFAULTMASK, в наборе инструкций кортекса м3 есть такое...

В каком пункте мануала про HARDFAULTMASK написано?

получается его одного достаточно чтобы все выключить? даже примаск?

Получается достаточно - кроме NMI и Reset.

[A. Fig Lee]

Обнуляется программой...Можно зарезервировать ячейку в ОЗУ и проверять её на старте и в зависимости от её значения решать что делать дальше - запускать программу, запускать бут или ещё что-то.

Это значит надо писать собственный startup файл.
Тоже можно, конечно.. Но по мне так это уже извращения пошли.

[scifi]

Это значит надо писать собственный startup файл.
Тоже можно, конечно.. Но по мне так это уже извращения пошли.

Стартапа бояться - загрузчик не писать. Ну что за цирк, ей-богу :-)

[A. Fig Lee]

Стартапа бояться - загрузчик не писать. Ну что за цирк, ей-богу :-)

А мы без всяких самодельных стартапов и ресетов обошлись.
Чем больше меняешь, тем больше багов.

[_Артём_]

Это значит надо писать собственный startup файл.
Тоже можно, конечно.. Но по мне так это уже извращения пошли.

Можно отредактировать startup, который есть: всего-то несколько строк добавить.

Код

               if ((FlashCrcOk()) && (StartType==START_APPLICATION)) {
        __disable_irq();
        __set_MSP(*(uint32_t *)0x1008);
        ISRPtr application_reset_handler=(ISRPtr)(*(uint32_t *)0x100C);
        goto *application_reset_handler;
              
                }

[scifi]

А мы без всяких самодельных стартапов и ресетов обошлись.
Чем больше меняешь, тем больше багов.

На самом деле бывает полезно разбираться в стартапе. Тем более на Cortex-M минимальный стартап - это всего несколько строчек:

CODE

#include <string.h>

extern char __etext, __data_start__, __data_end__, __bss_start__, __bss_end__;
extern int main();

void __attribute((used))
Reset_Handler(void)
{
/* copy-init variables */
memcpy(&__data_start__, &__etext, &__data_end__ - &__data_start__);
/* zero-init variables */
memset(&__bss_start__, 0, &__bss_end__ - &__bss_start__);
(void)main();
}

[A. Fig Lee]

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

В любом случае, как обслуживать ситуацию,
когда в данной ячейке при холодном старте флаг случайно совпал с тем, который выставляется
для прыгания в главную программу?
Может еще один флаг добавим?
Может, CRC считать начнем?

[_Артём_]

Это не стартап, это ресет хэндлер.

Ну так стартап состоит из двух частей - таблицы векторов и Reset_Handler-а. Таблица у каждого МК своя и её менять не надо.

В любом случае, как обслуживать ситуацию,
когда в данной ячейке при холодном старте флаг случайно совпал с тем, который выставляется
для прыгания в главную программу?

Маловероятно...

Может еще один флаг добавим?
Может, CRC считать начнем?

К тому же CRC прошивки посчитать всё равно желательно, а то вдруг там пусто.

[A. Fig Lee]

Маловероятно...

Ну.. Если так программировать..
Программирование должно быть детерминистик как возможно.
В общем, с ресетом больше граблей, дольше и выгоды не вижу.
Проще прыгнуть сразу, без всяких вероятностей

[_Артём_]

Ну.. Если так программировать..
Программирование должно быть детерминистик как возможно.

Согласен - не дело это. Хотя и каких-то нежелательных эффектов тоже сразу не видно. Хотя наверное можно придумать.

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

Согласен, так и лучше и проще.

[Golikov A.]

а мне понравилась идея)

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

получается я могу сделать флаг в RAM, и переходить через ресет на бут если в флаге стоит кодовое слово, иначе уходить в основную прогу. И оставить EEPROM в покое, интересно...

[Сергей Борщ]

получается я могу сделать флаг в RAM, и переходить через ресет на бут если в флаге стоит кодовое слово, иначе уходить в основную прогу. И оставить EEPROM в покое, интересно...

Не плодите сущностей. Вы сбрасываться как собираетесть? Программно? Вот и проверяйте флаг программного сброса в соответствующем регистре ядра. И не нужно ни EEPROM, ни ячейки в ОЗУ резервировать. А еще лучше сбрасываться после прошивки собакой и по отсутствию флага программного сброса делать проверку целостности прошивки и прыжок в нее. А по флагу программного сброса или при ошибке целостности уходить в загрузчик. Тогда вы получите возможность запуска загрузчика из основной программы программным сбросом и загрузчик при этом будет запускаться тоже со сброшенной периферией.
Я делаю именно так и нахожу это очень простым и удобным.

[Golikov A.]

Сбрасывать собакой - чтобы сброс был железным?
Если любой программный сброс - уход в загрузчик, то для удаленной перезагрузки устройства тоже делать фокус с вачдогом?

[scifi]

В любом случае, как обслуживать ситуацию,
когда в данной ячейке при холодном старте флаг случайно совпал с тем, который выставляется
для прыгания в главную программу?

Нужно пользоваться регистром, который показывает причину сброса. Можно совместно с ячейкой ОЗУ (и никаких случайных совпадений там уже быть не может), а можно и без неё, как отметил Сергей Борщ.

[A. Fig Lee]

Не плодите сущностей. Вы сбрасываться как собираетесть? Программно? Вот и проверяйте флаг программного сброса в соответствующем регистре ядра. И не нужно ни EEPROM, ни ячейки в ОЗУ резервировать. А еще лучше сбрасываться после прошивки собакой и по отсутствию флага программного сброса делать проверку целостности прошивки и прыжок в нее. А по флагу программного сброса или при ошибке целостности уходить в загрузчик. Тогда вы получите возможность запуска загрузчика из основной программы программным сбросом и загрузчик при этом будет запускаться тоже со сброшенной периферией.
Я делаю именно так и нахожу это очень простым и удобным.

А зачем "сброс собакой"? Что, без сброса чтото изменится? В любом случае все теже самые регистры задействованы записи/чтения флаша.
Залил, проверил и прыгнул.
Тогда и уходить никуда не надо..

Нужно пользоваться регистром, который показывает причину сброса. Можно совместно с ячейкой ОЗУ (и никаких случайных совпадений там уже быть не может), а можно и без неё, как отметил Сергей Борщ.

Случайные совпадения в ОЗУ могут быть всегда.

[scifi]

Случайные совпадения в ОЗУ могут быть всегда.

Как страшно жыть... Так никакая программа работать не сможет :-)
Случайные совпадения в моей схеме исключены. Вы просто не разобрались до конца.

[A. Fig Lee]

Как страшно жыть... Так никакая программа работать не сможет :-)
Случайные совпадения в моей схеме исключены. Вы просто не разобрались до конца.

Почему не разобрался? 2 никому не нужных движения: ресет и использование РАМ

[Сергей Борщ]

2 никому не нужных движения: ресет

Вам не нужны - не используйте. А я одним легким движением уверен, что у меня не продолжает молотить АЦП загаживая по DMA уже не свою память, мне не нужно затыкать таймера, генерящие прерывания с несуществующими в загрузчике обработчиками, что однократно запускаемая в LPC2xxx собака и в загрузчике и в приложении работает с разными настройками. Вы же можете все эти действия проводить вручную и на очередной версии приложения вдруг обнаружить, что не можете обновить прошивку потому что когда-то давно проектируя загрузчик, забыли заткнуть какую-то не использовавшуюся тогда периферию, а теперь, в новой версии, эта периферия мешает работать загрузчику. Пожалуйста! Каждый сам себе злобный Буратина.

[A. Fig Lee]

Вам не нужны - не используйте. А я одним легким движением уверен, что у меня не продолжает молотить АЦП загаживая по DMA уже не свою память, мне не нужно затыкать таймера, генерящие прерывания с несуществующими в загрузчике обработчиками, что однократно запускаемая в LPC2xxx собака и в загрузчике и в приложении работает с разными настройками. Вы же можете все эти действия проводить вручную и на очередной версии приложения вдруг обнаружить, что не можете обновить прошивку потому что когда-то давно проектируя загрузчик, забыли заткнуть какую-то не использовавшуюся тогда периферию, а теперь, в новой версии, эта периферия мешает работать загрузчику. Пожалуйста! Каждый сам себе злобный Буратина.

А.. А я в бутлоадере не пользую АЦП и тому подобное.
Канал для записи во флеш и обмена данными - один из USB/RS232 и так далее... Все.

А! Собака! Вот оно где порылось. Вотчдог - зло, его использовать плохая привычка.
Тем более в бутлоадере. Он должен быть прост и бронебоен.
Если там нужен вотчдог, чтото не так.

[Сергей Борщ]

А.. А я в бутлоадере не пользую АЦП и тому подобное.

А для обновления прошивки вам нужно вручную выключить и включить устройство, или все же предусмотрена возможность запуска загрузчика по команде работающему приложению? Если предусмотрена - то где и как вы затыкаете периферию, которую перед запуском загрузчика использовало приложение?

Канал для записи во флеш и обмена данными - один из USB/RS232 и так далее... Все.

И их затыкать после окончания перепрошивки перед запуском приложения тоже не нужно?

Тем более в бутлоадере. Он должен быть прост и бронебоен. Если там нужен вотчдог, что-то не так.

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

[Golikov A.]

Все же переход в загрузчик из основного приложения прыжком - реально зло... Надо в загрузчик переходить с чистого листа.
Так же и в приложение хорошо бы перейти с чистого листа, ну мало ли что... мое ИМХО

[Сергей Борщ]

Надо в загрузчик переходить с чистого листа.
Так же и в приложение хорошо бы перейти с чистого листа, ну мало ли что

Именно. Тем более что реализуется это гораздо проще, чем все остальные пути.

[A. Fig Lee]

А для обновления прошивки вам нужно вручную выключить и включить устройство, или все же предусмотрена возможность запуска загрузчика по команде работающему приложению?

Нет. Есть комманда, по ней делается програмный ресет.
И по ресету мы в бутлоадере. Если кнопка не была нажата при ресете, опять уходим в главную программу.

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

Дык - програмный ресет, ничего не надо затыкать.
А вот перед прыжком в программу USB затыкаем.
И надо в главной программе explicitly сделать __enable_interrupt()
Все, больше телодвижений не надо.

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

Все же переход в загрузчик из основного приложения прыжком - реально зло... Надо в загрузчик переходить с чистого листа.
Так же и в приложение хорошо бы перейти с чистого листа, ну мало ли что... мое ИМХО

Правильно. Но в приложение не обязательно

[Сергей Борщ]

Нет. Есть комманда, по ней делается програмный ресет.

То есть все-таки ресет?

Если кнопка не была нажата при ресете, опять уходим в главную программу.

Ага, то есть цена вашего велосипеда - необходимо присутствие вблизи устройства homo sapiens, нажимающего на кнопку. И необходимость у устройства иметь эту кнопку (снаружи или внутри, в последнем случае еще и корпус вскрывать надо). Понятно.

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

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

[Allregia]

Это значит надо писать собственный startup файл.
Тоже можно, конечно.. Но по мне так это уже извращения пошли.

Зачем? Достаточно обьявить переменную как __noinit и по абсолютному адресу.

В Ф4 я через backup SRAM передаю. Для перехода из основной программы в бутлоадер и обратно.

[A. Fig Lee]

То есть все-таки ресет?

В боотлоадер всегда по ресету, я никогда обратное не утверждал, а в главную программу просто прыжком.

Ага, то есть цена вашего велосипеда - необходимо присутствие вблизи устройства homo sapiens, нажимающего на кнопку. И необходимость у устройства иметь эту кнопку (снаружи или внутри, в последнем случае еще и корпус вскрывать надо). Понятно.

Да. Подсоединять то все равно ктото должен к компьютеру.
Кстати, сегодня заказали сделать с переходом в бутлоадер по команде.
Буду в главной программе писать 0xFE в EEPROM на старте, если там 0xFF.
Перед рестартом в бутлоадер сотру на 0xFF.
Бутлоадер при 0xFF прыгать не будет.
При дисконнекте USB будет прыгать в главную.
Но человек там все равно должен быть.

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

У нас тоже в случае неудачи (удачи тоже) всегда можно перепрошить.
Связь по USB, не вижу смысла обрабатывать обрыв связи.
Таймаут возможен при плохой микросхеме.
Тогда везти придется.

Зачем? Достаточно обьявить переменную как __noinit и по абсолютному адресу.

В Ф4 я через backup SRAM передаю. Для перехода из основной программы в бутлоадер и обратно.

Ух ты! Класс. Не знал про __no_init.
Да, про SRAM бакапную тоже забыл, но аксесс к ней нетривиальный тоже.


Так, что мы имеем?
STM32 имеет SRAM, то бишь статик RAM.
На триггерах, надо понимать.
Если погуглить на "sram initial state" то выпадает множество статей на тему "Initial SRAM State as a Fingerprint and Source of True Random Numbers..."
из чего можно сделать вывод, что как и следовало ожидать RAM на старте может быть в каком угодно состоянии.
На ней rely нельзя.
Буду делать через EEPROM.

[Golikov A.]

ну можно же не 8 бит, а 32 бита взять, да и положить не FF - FE , а что-то позаковыристей, например название фирмы в 4 32 битных числа положить, что такое будет случайно - настолько маловероятный факт, что если произойдет будет неплохой рекламой фирмы%)

[A. Fig Lee]

ну можно же не 8 бит, а 32 бита взять, да и положить не FF - FE , а что-то позаковыристей, например название фирмы в 4 32 битных числа положить, что такое будет случайно - настолько маловероятный факт, что если произойдет будет неплохой рекламой фирмы%)

Можно. И прошивку поставить куда нибудь в пассажирский самолет.
Будет "настолько маловероятный факт", что он грохнется..

"Мы пойдем другим путем" (с)

[scifi]

из чего можно сделать вывод, что как и следовало ожидать RAM на старте может быть в каком угодно состоянии.
На ней rely нельзя.

Толстый намёк (уже третий раз в этом топике): есть регистр, показывающий причину сброса.
Совсем-совсем толсто: если сброс программный, то есть гарантия, что в нужной ячейке ОЗУ не мусор, а то, что нужно. Почему? Потому что программа записала туда то, что нужно перед тем, как вызвать программный сброс.
Народ совсем не сообразительный пошёл нынче... Я в печали :-(

[Golikov A.]

Ну ваще не аргумент,...
то есть если вероятность того что 16 символов по 256 позиций на каждый сложились в правильную фразу для человека возможны (вероятность 1.1479437019748901445007192746311e-41), то где гарантия что не пролетит космической частицы, которая изменит именно этот флаг в вашем регистре... это же событие, тогда по вероятности просто каждый день происходит...

Правда та же причина не дает реально рассчитывать и на достоверную запись в ЕЕПРОМ, но к своим идеям человек относится менее критически))

[A. Fig Lee]

Толстый намёк (уже третий раз в этом топике): есть регистр, показывающий причину сброса.
Совсем-совсем толсто: если сброс программный, то есть гарантия, что в нужной ячейке ОЗУ не мусор, а то, что нужно. Почему? Потому что программа записала туда то, что нужно перед тем, как вызвать программный сброс.
Народ совсем не сообразительный пошёл нынче... Я в печали :-(

Да я уже давно ответил: нет смысла ничего писать в РАМ если и так ясно что ресет программный!

Ну ваще не аргумент,...
то есть если вероятность того что 16 символов по 256 позиций на каждый сложились в правильную фразу для человека возможны (вероятность 1.1479437019748901445007192746311e-41), то где гарантия что не пролетит космической частицы, которая изменит именно этот флаг в вашем регистре... это же событие, тогда по вероятности просто каждый день происходит...

Правда та же причина не дает реально рассчитывать и на достоверную запись в ЕЕПРОМ, но к своим идеям человек относится менее критически))

Комиссии попробуйте объяснить, что "скорее всего самолет не грохнется".
2. Это бессмыслица. Если есть програмный ресет, нечего возится с РАМ.

Кстати, Су100 не на таком же принципе сделан?
Думаю что и ракета с которой спутник грохнулся, была спроектирована аналогично

[Golikov A.]

Как вы победили вероятность сбоя из за попадания космических частиц? Мне просто интересно, если вы настолько скрупулезны, то вы наверняка и это учли... Я вот был в германии в институте, там стоит детектор космических частиц, да их толпы летают, как вы защищаете свои устройства?

[A. Fig Lee]

Как вы победили вероятность сбоя из за попадания космических частиц? Мне просто интересно, если вы настолько скрупулезны, то вы наверняка и это учли... Я вот был в германии в институте, там стоит детектор космических частиц, да их толпы летают, как вы защищаете свои устройства?

А что, у РАМ иммунитет к космическим частицам?
Везде могут быть проблемы, нет смысла искусственно их увеличивать.

[Golikov A.]

так это ваша позиция что так жить нельзя, и надо быть защищенным даже от вероятности 10^-14

[Terminator]

У меня переход делается если во внешней flash нет новой прошивки. Возможно это сильно сложно. Зато не требует участия человека.

[Golikov A.]

сильно опасно, можно сделать кирпич из прибора...

[Terminator]

сильно опасно, можно сделать кирпич из прибора...

Ничего подобного. Кирпич можно сделать только при обновлении загрузчика, если он разрешён.

Мой алгоритм действий такой:
- если во внешней flash есть валидная прошивка, то сравниваем её с текущей и перешиваем если отличается. Затем запускаем основную прошивку.
- если нет новой прошивки, то сразу запускаем основную прошивку.

[Golikov A.]

а... 2 флэшки...

[Terminator]

Я же сразу сказал про внешнюю flash

[A. Fig Lee]

так это ваша позиция что так жить нельзя, и надо быть защищенным даже от вероятности 10^-14

Моя позиция - не стоит плодить баги без необходимости.
Все. Больше отвечать "по кругу" не буду.

[vlad_new]

Я в своём загрузчике напоролся на проблемму с SysTick. Как я не старался, мне не удалось его "полностью блокировать". Запретил глобальное прерывание, остановил SysTick, сбросил все флаги в энвике, поставил маленькую задержку и тем не менее после глобального разрешения прерывания, изредко, возникало ещё одно прерывание от SysTick. Собственно проблемму решил добавив ещё один сброс энвика с задержкой.
Я это к тому, что в каждом конкретном случае, подводные камни имеют место быть и "сбросить всё" без резета, не всегда так просто, как кажется на первый взгляд.

[adnega]

Я в своём загрузчике напоролся на проблемму с SysTick. Как я не старался, мне не удалось его "полностью блокировать". Запретил глобальное прерывание, остановил SysTick, сбросил все флаги в энвике, поставил маленькую задержку и тем не менее после глобального разрешения прерывания, изредко, возникало ещё одно прерывание от SysTick. Собственно проблемму решил добавив ещё один сброс энвика с задержкой.
Я это к тому, что в каждом конкретном случае, подводные камни имеют место быть и "сбросить всё" без резета, не всегда так просто, как кажется на первый взгляд.

В NVIC можно сбросить не только разрешение прерывания, но и флаг отложенного прерывания - периферия взвела,
но в данный момент прерывание выполниться не может, т.к. запрещено. "Все не просто", но некоторые вещи вполне можно решить.

[jcxz]

Добавлю свои 5 копеек касательно сброса периферии:

Только что напоролся на проблему в LPC1758 с UART1 с включённым аппаратным управлением потока
(в составе UART1 имеются CTS/RTS). И проявилась она именно при рестарте прошивки обычным
переходом на вектор сброса (ну естественно с выполнением всех условий по переключению режимов
thread->handler, текущего стека и пр.).
А именно: если включено управление потоком (UART1 сам формирует RTS) и FIFO заполнилось до
уровня установки RTS-стоп и в этот момент выполнить рестарт, а после рестарта идёт отключение всей
периферии с последующим включением и инициализацией, в том числе - сброс FIFO через FCR, то
после этого после включения управления потоком опять, RTS остаётся в состоянии "стоп" хотя FIFO пуст.
И никакие сбросы UART, отключения его питания в PCONP - не помогают.
Не помогает даже снижение FIFO-level до низкого уровня.
Единственный способ - отключить временно FlowControl, принять N байт в FIFO до его заполнения до
того уровня FIFO, который был ранее и только после этого опять включить - после этого начинает
работать.

А если сделать аппаратный сброс CPU (например - через WDT), то проблемы не возникает.
Похоже в составе UART есть триггер, который устанавливается при превышении заполненности
FIFO выше уровня и сбрасывается только при понижении в обратную сторону, а командами
очистки FIFO - не сбрасывается.

Ещё аналогичная проблема была у меня давно на техасском CC5502 с FIFO DMA-каналов:
при программном сбросе, если в этот момент в FIFO были данные (DMA-канал успел
выполнить чтение источника, но не успел выполнить запись), DMA-контроллер запрещается, но не
сбрасывается. И, при последующем его разрешении, при старте передачи, перед пересылаемыми данными
вылазили те застрявшие байты.
FIFO DMA-канала программно недоступна и сбросить её нельзя. Так что пришлось при старте ПО, вначале делать одну
фиктивную транзакцию (чтобы "продуть" FIFO), и только потом запускать канал в работу.

[andrewlekar]

Я в своём загрузчике напоролся на проблемму с SysTick. Как я не старался, мне не удалось его "полностью блокировать".

У меня то же самое было. SysTick я поборол, а вот прыжок из работающей ОС у меня так и не завёлся. То есть бут у меня работает под осью, как и основное приложение, а ось, вероятно, постоянно сидит в режиме обработчика прерывания и прыгнуть толком не может.

[jcxz]

У меня то же самое было. SysTick я поборол, а вот прыжок из работающей ОС у меня так и не завёлся. То есть бут у меня работает под осью, как и основное приложение, а ось, вероятно, постоянно сидит в режиме обработчика прерывания и прыгнуть толком не может.

ОС не "сидит постоянно в режиме обработчика прерывания". Cortex-M под ОС находится или в handler- или в thread-mode.
И, если это знать, то проблем с Cortex-ядром при перезагрузке быть не должно.
У меня рестарт хоть из под ОС хоть без - работает нормально (за исключением вышеописаной проблемы с периферией). Проблемы могут быть только в периферии.

[andrewlekar]

Ну вам виднее. У меня с периферией проблем не было, а у запускаемого приложения - были. Когда стал прыгать до старта оси, всё стало работать как надо.

[ViKo]

ОС не "сидит постоянно в режиме обработчика прерывания". Cortex-M под ОС находится или в handler- или в thread-mode.

А также с привилегированным или пользовательским уровнями thread.