Проблема выявилась только после обновления Keil взамен v4.21 свежей v4.22 под J-Link, проц STM32F103RBT
После прошивки кода (кнопочкой LOAD) не стартует, помогает только сброс или передергивание питания.
Такая же ситуация и в режиме отладки - через неопределенный промежуток кода вываливается в Hard Fault.
Тот же самый код на том же проце без изменений отлично отлаживается и сразу запускается после прошивки в v4.21.
Настройки проекта не меняются, т.е. все один в один.
Дрова и dll-ка для J-Link (в папке Keil/BIN...) принудительно поменяна на свежие, взятые с Segger, в обоих версиях Keil.
Пробовал использовать под оригинальным фирмовым J-Link и MT-Link - все тоже самое.
Поэтому откатился обратно в 4.21, сразу же все стало как нужно.
На лицо - бага со сбросом проца после прошивки или чем-то еще.
Сам по себе компилируемый код практически не меняется и в обоих случаях работает.

Странно, вчера компилировал им проект для STM32F207, заливал MTLINK'ом. Не было такого ...

ого...
А у меня с предыдущим нарисовалась проблема (сейчас пост нарисую), я уже собрался попробовать обновиться...

Ситуация вылезла сразу после обновления на 4.22,
после этого обновления я открыл тот же проект, пересобрал, залил - не заводится,
передернул питание платы, завелось.
В отладку входит, но в процессе отладки вылетает в Hardfault.
Возможно, у меня сложный по построению проект -
закоментированы из стартапа startup_stm32f10x_md.s только три строчки:

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

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

Пару дней усиленно мучил 4.22 - действительно, есть такая фигня. На lpc1768, без всяких классов, в том числе на родных примерах типа \Keil\ARM\Boards\Keil\MCB1700\RL\TCPnet\LEDSwitch

Судя по моим лампочкам - программа стартует и где-то через полсекунды куда-то улетает.

Несколько раз при старте отладчика улетало в Hard Fault c такой же комбинацией лампочек, т.е. примерно в такое же время, но это оказалось последствием обычного обращения к элементу массива далеко за его пределами.

>Я так и не понял, где он вызывает конструкторы статических классов?

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

Похожая ситуация. Keil 4.22 & JLink-pro.
Рабочая программа (делалась в 4.20) после компиляции и прошивки в 4.22 переставала нормально работать, периодически зависала без подключенного программатора. Предположительно вываливалась в хардфаулт. Но выцепить это пока не получилось, т.к. происходило раз в полчаса и во время отладки не проявлялось.
И еще в 4.22 с ресетом проблемы, после StopDebug устройство висит даже если JLINK отключить от него. Нашел несколько решений:
1) передернуть питание.
2) в командной строке JLINK-а выполнить две команды: r0 и r1, что означает сбросить ногу RESET и установить ногу RESET, но при этом если вручную кнопкой на плате пытаться ресетить - безуспешно.

Может кто-нибудь знает нормальное решение этой проблемы?

Дополнение: c ULINK2 и ST-Link проблем ресета нет

Внимая нашим мольбам, вышел 4.22a ))
Но исправлен ли там этот косяк - я не проверял.

так что очень может быть

"The ST-LINKIII-Keil.dll MDK driver in folder ..\ARM\STLink\ has been updated to version 1.5.6.1." - т.е. откатили? У меня вчера кстати проблемма с ST-Link возникла неожиданно, т.к. позавчера этот же ST-Link работал. Тупо кейл его не видел. И СТМ32Дискавери перестали в кейле 4.22 работать. Два раза все сносил. Откатывал на кейл 4.20. Чистил реестр. Менял все драйвера на самые старые рабочие. Не работало. А заработало все само собой так же неожиданно, как и перестало)) Для меня это осталось загадкой.

toweroff, скоро обновление на рутрекере будет? Заранее спасибо.

как китайцы выложат пока не было

А смена свежих дров толку в 4.22 не дает (я проверял, делая это вручную заменяя dll-ки в keil).
Этот косяк скорее всего внутри самой среды.


зы. Я выложил обновку 4.22а на местный ftp.
Также как обычно обновку можно слить с офф сайта keil.

С кейла я тоже скачал. Только вот однажды (не помню на какой версии), кейловский вариант матерился на нормальный рабочий проект. Скачал у китайцев - все нормально заработало. Размер exe-шника сетапа был другой (!)

Проверил 4.22а - та же хрень. Похоже, действительно нужно ждать китайцев...

Короче, в Keil 4.22a проблемма с ресетом не решена. И у меня есть тому даже небольшое документальное подтверждение. Есть такой файлик JLinkLog.txt, в котором ведется лог JLINKa. Так вот Keil 4.22 и 4.22a в отличии от 4.20 завершает сессию отладки без JLINK_Close(). Т.е. дрова тут ни при чем.

я пока выложил версию с кейла. Возможно, там глюк и китайцы выложат корректную версию, или сам кейл позже выложит еще один апдейт
В данный момент сам отлаживаюсь через ULINK2, с моим LPC29xx у JLINK-Ultra давние бодания, хотя проверить надо с этими версиями
С STM вообще дела не имел, так что прокомментировать не смогу

>Updated: Segger J-Link driver for ARM devices to version 4.34.

Ага. Щаз. А кто пишет над зелёненькой иконкой Jlink в правом нижнем углу V4.35b ?!
Похоже эти (сенсоред) ребяты положили в релиз бету J-link'а или помесь 4.34 и 4.35b
У самих сеггеров на сайте лежит бета 4.35h... сейчас будем пробовать....не вляпаться бы опять

Драйверы и dll-ки тут ни при чем. Это уже тут упоминалось. Я тоже пробовал - без толку ((

Скачал у китайцев 4.22а
Подозрительно маленький архив (~300MB), что-то, думаю, тут не так
И действительно, в архиве спокойно себе лежит 4.21

Ждем других китайцев. Мне надоело шаманить с командной строкой, и я откатил до 4.20

А у меня стоит 4.21, взятая с местного фтп. В ней все ок.

Выложили китайцы нормальную версию. Нормальную - в смысле действительно 4.22а
Но хорошего мало - та же самая, что и у кейла на сайте

Ура, комрады! Вышла 4.23!
Там сабжевая бага, похоже, устранена - пока работает как нада!

А других засад там не появилось ?

Пока не заметил... Проверял, правда, на STM32F103.

Да вообще у этого кейла всегда плохо были дела с заливкой прошивки через J-Link.
Всегда с какими-то тормозами и "клиньями". Что на старом МТ-Линк, что на новом J-Link8.

IAR с тем же самым железом и отладчиком шьёт влёт без запинки.
Аналогично и сеггеровский JFlashARM - за несколько секунд 200 килобайт запишет и сверит.
Кейловскому же прошивальщику на это дело требуется около минуты...

Дрова обновил до самых последних - всё одно.
Зато название FlashOS звучит гордо, но на деле это как хромая курица

А кто нибудь в Кейле код под SAM3U писал\зашивал\отлаживал?

Что-то всё совсем грустно стало в Кейле.

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

Этого HSMCI нет даже в меню периферии отлпдчика - может, поэтому такие глюки?

Если отлаживаться в ИАРе - таких проблем нет.

Может, это только с SAM3 у кейла такие проблемы? Раньше приходилось работать в Кейле с STM32 - кроме тормозов при прошивке проблем не было, тем более при отладке...