Часто чтобы приконнектиться нужно несколько раз перезапустить всё: передёрнуть USB жетлинка, питание платы и даже перезапустить ИАР.
Отваливается тоже достаточно быстро.
Причём кажется эта проблема нарастает по мере усложнения программы в арме.
Что он может такого делать чтобы мешать отладчику?
Если вместо программы пустышка, то всё значительно стабильнее.
ИАР сам тоже хорош: вот зачем при отвале коннекта (или изначальном обломе) столько раз нужно надавить на эти мусорные месседж-боксы? Неужели одного недостаточно??

Иногда помогает включить flash download. Но не всегда.

Работаю из под виртуалки, хрюши. Основная семёрка. Брыкается но редко. Проект "война и мир". Заливка и отладка - в пределах раздражения - т.е. отваливания редки.
От объёма кода зависимости не нашёл, но вот сам проект с сетевым диском работать не захотел - отваливается стабильно. Пришлось проект держать на диске "C"
внутри виртуалки и батничком сваливать изменения. Тупо, но дышит вроде как...

А давным давно на ИАР для MSP, надо было штатный проводок JTAG (выходной шлейф с коробочки на плату) укоротить до 5 см, и сразу становилось легче... может вам тоже поможет?

Питание платы, JLink-а проверили? Может БП не держит нагрузку?


Да, кстати - у меня тоже были проблемы с некоторыми USB-кабелями (от кмопа к JLink) - глючило, отваливалось.
Поменяешь на другой, толстый - работает как вкопанный. Сейчас стараюсь подключать только толстыми и короткими.

Ещё вопрос::

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

Что это за нафиг?

Можно делать отладочную печать в RS232 по printf и не пользоваться пошаговым отладчиком. При этом программа получается релизная и в неё не нужно включать мусор для дебагера. Но это дело пристрастий.

Вопрос не в этом. А в принципе. Что именно происходит с брекпойнтами/степами и можно ли этого избежать.

Читать
https://www.segger.com/jlink-unlimited-flas...reakpoints.html
Там написано, что на ARM 7/9 2 быстрых брекпойнта, на Cortex-M 4-6, а больше только через перешивку флеша...

Спасибо. Но странно. Мне казалось он у меня всего один. Может быть "забытые" где-то сидят, которые никогда не срабатывают........

Ну в свойствах проекта "Debugger->Run to main" стоит галка? Стоит. Одного брякпойнта как не бывало. И еще по проекту пошарить не забыть "Debugger->J-Link/J-trace->Breakpoints"...

Это-то стоит. Но вот нашёл такую фигню как "Breakpoint Usage", и она действительно показывает установленные бряки. Но лишнего там нет. Изначально список пустой. Ставишь бряк - сразу появляется в списке.

Ну дык сними эту галку, толку от нее немного, зато появится лишний бряк. Все как-то чуть легче выкручиваться будет...
И еще, используй хороший, толстый УСБ кабель, на тонких китайских кабелях возможны глюки.
И еще, между J-Link и отлаживаемой схемой провода должны быть, как можно короче, вплоть до того, что стандартный шлейф снимается, а вместо него подсоединяются отдельные проводники длиной 40-50мм.
И еще, если контроллер толстый, и размер ОЗУ позволяет разместить код и данные в ОЗУ, на период отладки скомпилируй проект полностью в ОЗУ. Это намного упростит отладку и снимет проблемы с количеством точек останова...
Вот так...

Тоже так делаю когда есть возможность
Делаю обычно две дополнительные конфигурации: RAM_DEBUG и RAM_RELEASE + связанный с ними ram.icf.
А если есть возможность - и sdram.icf, хотя там код значительно медленнее исполняется.
И скорость загрузки новой прошивки выше и программные бряки не надо перешивать - отладка так гораздо быстрее идёт.