Budek

А вы бы просто читать научились... В самом начале писал: "выводил в дебаг перед уходом в STOP все возможно причастные регистры (вроде и у CORE никого не забыл" Ясен пень, RCC, FLASH... в первую очередь.

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

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

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

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

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

Здравствуйте! Не первый год с 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 ничего не делал (после перевключения питания его уже не разбудить). Вроде, ничего не забыл описать... Естественно, эксперименты не помогли. Подозреваю, что при прошивке что то нарушается в ядре, но как это увидеть... В общем, прошу помощи. Спасибо!

Спасибо откликнувшимся. Стартовать со своего загрузчика не представляется возможным. Он тогда должен будет размером с само приложение (скачать прошивку с ftp-сервера gsm-модулем - далеко не килобайт кода). Конечно, в этом случае полезные функции загрузчика (например, работа с gsm-модулем) можно использовать и в самом приложении (для экономии flash микроконтроллера). Но тогда они должны быть железно работоспособными. А это нереально.

Здравствуйте! Возникла проблема. Мой проект (STM32L) на сегодняшний день имеет 3 способа обновлять свою прошивку в процессе работы. Сначала обновленная версия помещается во внешнюю M25P, а затем входим непосредственно в процедуру самопрограммирования: запускается мой собственный "программатор" (находящийся в конце flash микроконтроллера по жестко заданному адресу). И вот именно в этот момент может произойти ошибка. Например, стерли очередную страницу flash, а записать (без ошибок) не получается. В конечном счете, пишем как уж получилось (выбора то уже нет) и надеемся, что приложение уж хоть как то будет функционировать. Можно, конечно, в eeprom писать флаг фатальной ошибки, но это не выход из положения (много об этом думал). Остается один вариант - уметь самим приложение посчитать crc "самого себя". Но для этого необходимо знать последний адрес текущей прошивки. И необходимо узнать его именно самим работающим приложением. Вариант "до конца" flash не подходит - все, что выше полезного для приложения адреса может быть рандомно заполнено (остатки чего то предыдущего). Так вот вопрос: как бы узнать приложению, какой у него последний адрес. Спасибо.

Сам и отвечу...: 81. Всем спасибо!

Здравствуйте все! При отправке на "+7....." перед номером ставим "91" (интернациональный формат). А что если надо отправить на "8..." (без плюса)? Перепробовал вроде самое логичное: A1 / A8 / 98 / 91 - ошибка (без кода, а просто ERROR). Причем не сразу, а секунд 20-30 модуль думает. Модуль - SIM800H (хотя какая тут разница...). Единственное, вроде раньше модули (не помню какие) отправляли на "8..." с типом "91" (при ошибке записи номера). И смс вроде уходили. Только стоили огромных денег (видимо слал на "+8..."). А SIM800H (или оператор, сейчас, а не "тогда") не хочет даже так. Спасибо.

Ну почему же обозвал. Даже в кавычки взял. Мы здесь вроде одно общее дело делаем (пытаемся уж точно).

Спасибо. Будем пробовать...

Да нет, конечно. Жду "нормальную" прошивку для 800-го... Может это поможет. Отгадывать китайские головоломки сил больше нет (да и не для этого меня родили).

Всем здравствуйте. at+cimi 250018527894350 at+cops=? +COPS: ,(0-4),(0-2) at+cops? +COPS: 1 at+cops=1,2,"25001" ERROR Симчип готов (+CPIN READY) При этом модуль явно продолжает попытки достучаться до оператора (судя по току потреблению и цикличности ответов на at+creg? : 2 - 3 - 0 - 2 - 3......)