[Budek 0]

Здравствуйте!
Не первый год с STM32, но наткнулся на грабли. Не потому что они появились, а потому что столкнулся.
После программирования микроконтроллера он не уходит в stop mode. Правильнее сказать, выходит сам по себе. И так в цикле бесконечно.
Хардварный ресет не помогает. Спасает только перевключение питания. 
Дополнительно: если пересбросить питание (для последующей нормальной работы), а потом ST-Link-ом сделать Connect -> Disconnect, то это не портит картину (прога продолжает нормально уходить в stop).
И всё бы ничего, но сейчас поделка, у кторой li-po аккум будет припаян. Не хочется потом при необходимости обновления прошивки отпаивать его.
На буржуинском форуме 3 страницы это обсуждалось, но решение так и не было найдено. 
Детали: примитивный F030 + примитивная прога (под cube32mx), компилю в Keil, шью китайским свистком из ST-Link Utility. Мои эксперименты:
1. В ST-Link Utility перепробовал все галки (например, Enable Debug in Low Power Mode)
2. Достал из закромов фирменные ST-Link и Keil-овский ULINK.
3. Для тупого сравнения (после прошивки и после перевключения питания) выводил в дебаг перед уходом в STOP все возможно причастные регистры (вроде и у CORE никого не забыл).
Разница только В бите софтварного сброса (что логично).
4. Пытался найти инфу, в каком регистре увидеть причину выхода из stop (по аналогии, как можем узныть причину сброса). Но, похоже, такого нет.
5. По проге: сделал даже тестовую, где только настроен пин на мигание светодиода (чтоб видеть процесс). Даже для выхода из stop ничего не делал (после перевключения питания его уже не разбудить). 
Вроде, ничего не забыл описать... Естественно, эксперименты не помогли.
Подозреваю, что при прошивке что то нарушается в ядре, но как это увидеть...
В общем, прошу помощи. Спасибо!
 

[HardEgor 113]

1 час назад, Budek сказал:

После программирования микроконтроллера он не уходит в stop mode. Правильнее сказать, выходит сам по себе. И так в цикле бесконечно.

Watchdog?

[Budek 0]

1 hour ago, HardEgor said:

Watchdog?

??? 
Вы про галку Option Bytes (WDG_SW) в ST Link Utility?
Если так, то я писал (п.1), что перепробовал все галки. Исключительно сейчас, чтобы ответить вам, снял её - тогда мк вообще не стартует, даже после перевключения питания.

[HardEgor 113]

1 час назад, Budek сказал:

Вы про галку Option Bytes (WDG_SW) в ST Link Utility?
Если так, то я писал (п.1), что перепробовал все галки. Исключительно сейчас, чтобы ответить вам, снял её - тогда мк вообще не стартует, даже после перевключения питания.

Да. Зачем все галки пробовать? Наверняка что лишнее включили.

Надо открыть Reference Manual и прочитать про Stop mode

Mode exit:

If WFI was used for entry:
– Any EXTI Line configured in Interrupt mode (the corresponding EXTI Interrupt vector must be enabled in the NVIC). Refer to Table 31: Vector table.
If WFE was used for entry: Any EXTI Line configured in event mode. Refer to Section 11.2.3: Event management on page 174

[Budek 0]

Вы бы хоть прочитали, что ч напмсал в самом начале...
1. Галки я ставлю ПО ОДНОЙ за раз. Не т результата - вернул ЕЕ (ОДНУ) на место. Так что ничего "понаставить" лишнего я не мог.
2. Зачем писать "умные" советы "почитай доки"? п.5: сделал ТЕСТОВУЮ прошивку. Абсолютно пустой проект! Какие EXTI... Нет там ничего. Только один пин на светодиод!!! Ничего не настроено для выхода из stop!!! То есть после подачи питания он вообще не выйдет из него никогда. Вот весь while:
while (1)  {
  HAL_GPIO_WritePin(GPIOA, GPIO_PIN_7, GPIO_PIN_RESET);
  HAL_Delay(10);
  HAL_GPIO_WritePin(GPIOA, GPIO_PIN_7, GPIO_PIN_SET);
  HAL_Delay(500);
      
  PWR->CR |= PWR_CR_CWUF;
  HAL_PWR_EnterSTOPMode(PWR_LOWPOWERREGULATOR_ON, PWR_STOPENTRY_WFE);     
}
Если вы ПО ДЕЛУ ничем помочь не можете, пожалуйста, не пишите "добрые" советы "почитай доки" и т.п.... Не отнимайте ни свое, ни мое время. 
А то как на том форуме. 3 страницы, и только еднственный дельный совет: попробовать сбросить DBG-регистр при старте.

И главное: не работает как надо именно только после прошивки микроконтроллера. Пересбросил питание - все становится хорошо. Ежу понятно, что прога рабочая.
Просто программатор, видимо, что то испортил.

Похожая картина: я уже давно для нашего производства сделал тест-плату (с автономным программатором). Но тогда инфы по протоколу не нашел и все познавал сам...
Так вот тоже после прошивки или еще чего иногда не "достучишься" до испытуемого - пересбросил питание ему - пошел дальше. И вот здесь я абсолютно не грешу на микроконтроллер,
а только на свой "программатор", потому как он запросто может начудить. 

 

[HardEgor 113]

25 минут назад, Budek сказал:

То есть после подачи питания он вообще не выйдет из него никогда. Вот весь while:

Зачем этот while? надо заглянуть в отладчик и проверить включены опции WFI или какой-нибудь вход на event?

[jcxz 279]

45 минут назад, Budek сказал:

Если вы ПО ДЕЛУ ничем помочь не можете, пожалуйста, не пишите "добрые" советы "почитай доки" и т.п.... Не отнимайте ни свое, ни мое время. 

Не читая доки проблему не найдёте. Читаем:

Цитата

WFE wakeup events
The following events are WFE wakeup events:
• The execution of an SEV instruction on any processor in the multiprocessor system.
• Any exception entering the Pending state if SEVONPEND in the System Control Register is set.
• An asynchronous exception at a priority that preempts any currently active exceptions.
• A debug event with debug enabled.

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

Надо проверять все флаги прерываний в NVIC.

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

45 минут назад, Budek сказал:

А то как на том форуме. 3 страницы, и только еднственный дельный совет: попробовать сбросить DBG-регистр при старте.

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

45 минут назад, Budek сказал:

И главное: не работает как надо именно только после прошивки микроконтроллера. Пересбросил питание - все становится хорошо. Ежу понятно, что прога рабочая.

Очевидно, что прога не рабочая. Она ведь не работает как надо.

И искать проблему надо в первую очередь - у себя. А не у отладчика.

45 минут назад, Budek сказал:

HAL_PWR_EnterSTOPMode(PWR_LOWPOWERREGULATOR_ON, PWR_STOPENTRY_WFE); 

Слепая вера в куб до добра не доводит. Надо попробовать самостоятельно перевести процессор в сон. Не надеясь на куб.

И нужно не "галки ставить", а биты регистров менять.

15 минут назад, HardEgor сказал:

надо заглянуть в отладчик и проверить включены опции WFI или какой-нибудь вход на event?

Вангую, что ТС использует не WFI, а WFE. Но это не точно....

[Budek 0]

1 hour ago, jcxz said:

Не читая доки проблему не найдёте. Читаем:

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

Надо проверять все флаги прерываний в NVIC.

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

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

Очевидно, что прога не рабочая. Она ведь не работает как надо.

И искать проблему надо в первую очередь - у себя. А не у отладчика.

Слепая вера в куб до добра не доводит. Надо попробовать самостоятельно перевести процессор в сон. Не надеясь на куб.

И нужно не "галки ставить", а биты регистров менять.

Вангую, что ТС использует не WFI, а WFE. Но это не точно....

Спасибо!
Буду копать в сторону дебаггера. Это для меня абсолютно новая тема. Никогда не приходилось, всегда хватала своего пина по уарт.
Но: как может программа быть нерабочей, если она работает? Не работает она только после "воздействия" на мк программатора. Пересбросил питание - все работает.
Именно по этому я считаю, что WFE это или WFI, скажем, в данном случае не имеет значения. Если только, например, (повторюсь) программатор мозг ядру стряхнул так, что одна из этих инструкций стала нерабочей.
И опять...: пмтание перектнул - ядро (например) оклемалось и забыло, что над ним ранее издевались. 

[jcxz 279]

48 минут назад, Budek сказал:

Но: как может программа быть нерабочей, если она работает? Не работает она только после "воздействия" на мк программатора. Пересбросил питание - все работает.
Именно по этому я считаю, что WFE это или WFI, скажем, в данном случае не имеет значения. Если только, например, (повторюсь) программатор мозг ядру стряхнул так, что одна из этих инструкций стала нерабочей.

Пример (это не про ваш случай, это просто пример воздействия эмулятора, после которого как бы "рабочая" программа, оказывается по факту "нерабочей"):

Программа использует таймер DWT.CYCCNT. Всё ок. Удобный таймер, 32-битный, считает с частотой клоков CPU. Но есть нюанс: Его используют отладчики. При подключении к МК они его могут включать, при отключении - могут выключать. Просто безусловно выключают и всё. Поэтому, чтобы программа могла его использовать (например - для измерения временных интервалов), и возможны подключения/отключения отладчика без рестарта программы, программа должна следить за этим таймером. И, если вдруг таймер оказывается выкл. - включать его (авто-включение).

 

Если отключения отладчика без пересброса программы невозможны, то можно не следить за включённостью этого таймера. Таймер включается при старте программы и он не выключится самопроизвольно.  И программа и без авто-включений - "рабочая".

Если отключения отладчика без пересброса программы возможны - программа без авто-включений - "нерабочая".

Вопрос лишь - условий эксплуатации устройства. Вы сами пишете про:

48 минут назад, Budek сказал:

Не работает она только после "воздействия" на мк программатора. Пересбросил питание - все работает.

Но зачем это нужно (чтобы программа после прошивки через эмулятор могла работать без выкл./вкл. питания)? Обычно это не требуется. И не составляет никакого труда передёрнуть питание после прошивки. Даже желательно так сделать. И вашу программу можно считать рабочей.

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

48 минут назад, Budek сказал:

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

Не программатор, а "отладочный эмулятор" наверное. Речь ведь про SWD-эмулятор? Прошивка - это только одна из его функций.

Эмуляторы, при прошивке флеши МК или даже просто - при заливке программы на исполнение в ОЗУ МК, пишут во многие периферийные регистры и регистры CPU. Без этого они просто не смогут прошить флешь вашего МК. Для программирования флеши STM32 эмуляторы пишут/читают регистры блока FLASH периферии МК. Естественно - они меняют содержимое этих регистров. И скорее всего - и каких-то других регистров.

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

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

[Budek 0]

5 hours ago, jcxz said:

Но зачем это нужно (чтобы программа после прошивки через эмулятор могла работать без выкл./вкл. питания)? Обычно это не требуется. И не составляет никакого труда передёрнуть питание после прошивки. Даже желательно так сделать. И вашу программу можно считать рабочей.

Сам пишу... сам читаю.. 6-я строка моей темы:
И всё бы ничего, но сейчас поделка, у кторой li-po аккум будет припаян. Не хочется потом при необходимости обновления прошивки отпаивать его.

[Plain 280]

19 часов назад, Budek сказал:

Абсолютно пустой проект!

Если так, покажите дизасм.

[EdgeAligned 88]

Есои в ST Utility включили Hardware Watchdog, то он ничем не отменяется, даже полным стиранием МК. И микроконтроллер будет постоянно перезапускаться, даже с полностью пустым проектом. Выход - через СТ-утилиту выключить хардварный вачдог

[Arlleex 255]

Защиты всякие от чтения не включаются?

[Budek 0]

Здравствуйте все! Всем огромное спасибо за участие!
Правда очень жаль, что советы начинаются с "учи матчасть"... "да у тебя программа кривая"... Можно начинать такое в любой новой теме.
Я понимаю, что кто то может поднять вой "у меня мк не прошивается", забыв тупо подать питание на него. Но у меня "немного" не тот случай.
А теперь о том, как проблема разрешилась. Конечно, не без совета. А именно: подключай дебаггер.
Повторюсь, никогда в жизни не  было необходимости в этом. Начал... Keil просит: обнови st-link. Хорошо (как я сам не попробовал этот вариант...).
И думаю, дай ка попробую... И вот, свершилось! Теперь после прошивки микроконтроллеру по прежнему не спится.
Но достаточно  сделать хардварный ресет или даже connect -> disconnect и всё работает!
Еще раз, всем спасибо!

[EdgeAligned 88]

Ну дак с матчасти то всё и начинается.

16 минут назад, Budek сказал:

Но достаточно  сделать хардварный ресет или даже connect -> disconnect и всё работает!

Проблема то всё равно осталась, и ресет - это не решение проблемы, а временная затычка.

 

В 13.03.2025 в 08:36, Budek сказал:

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

Учите матчасть. Регистр Control/status register (RCC_CSR)