У меня ST-LINK/2 , отладчик отваливается при любом удобном случае, задетектировать место зависания не удается, импульс и полный сбой, что с отладчиком что без него. Даже когда отладку делаешь через ноутбук работающих от своих батарей в режиме полной гальваноразвязки, збои - реже. Разрабатываемое устройство работает с реактивными цепями накапливающими токи в свою индуктивность до одного-полутора килоампера. Поэтому E = (L * (I*I)) / 2; - (L = 5 - 20 uh) большие импульсные помехи. Слив всю энергию в емкость 10 нанофарад можем получить 67 Кволльта на нем, все зависит от добротности реактивности пораждающюю обратною ЭДС. Длина волны (скорость нарастания/спада) пораждаемая этим разрядом уже три раза превысила импульс пораждаемые гармоники рентгеновского спекта. Поэтому длина полны может быть и сантиметр и миллиметр, все зависит от магнитной проницаемости среды и формы конструкции.
Главная ошибка это отсутствие гальваноразвязки, искушение использовать встроенные в ARM ADC периферию ! Схему разрабатывал не я. Неоднократно предупреждал и расчитывал возможные помехи.

О, экспериментальная физика высоких энергий или лазерная техника. Отличное поле для топтания по граблям. ST-LINK/2 и сам отвалится может, и USB подохнуть. В таком случае ставили отладчик на линухе под openOCD, экарнировали его вместе с отлаживаемым устройством в многослойном медно-пермаллоевом экране, источники питания типа свницовых батаерй от UPS тоже были внутри. А наружу выходила только пара световодов от медиаконвертора эзернета, по которому и общались и с отладчиком, и с отлаживаемым устройством.

начать с замены программатора на с эзернетом, программатор заэкранировать в одном ящике с таргетом, кабель тоже заэкранировать

Вам немного не про это. Пускай отваливается. Хоть вообще его не подключать. ПОСЛЕ зависания подключится отладчиком удается?

Нет. Не удается. Даже при неправильной конфигурации периферии, если забыл законфигурировать CLK или обратился в несуществующей памяти, частенько бывает чтобы вывести STM32 из состояния внутрененего покоя, нужно на BOOT0 - 1 подать, чтоб злокод написаный не выполнялся. Это касательно отладки через SWD, не JTAG. Ввиду творческого порыва и смелого духа, на JTAG пинов не резервируем, только SWD.

Забавно. Судя по вашим словам периодическое срабатывание ватчдога не мешает вашей программе. А вот внешний сброс нежелателен.

А что вы собственно делаете в ватчдоге для восстановления работы программы?
Да и что делает сама программа полезно узнать.

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

Есть также хитрозадый вариант с детектором помехи, блокирующим (приостанавливающим, перезапускающим и т.п.) работу процессора.

А кто-нибудь изолированный SWD использовал? Вот это https://www.lpcware.com/content/blog/isolat...d-debug-adapter работоспособно ли? И можно ли вообще сделать SWD на 3-4 длинных световодах?

Мы так софт делали для своей железки. Софт был написан так, что ему было все равно в какой момент был подан сброс или убрано питание.

Ну а запитать проц в своем домене питания, поставить трансилы по входным линиям, или вообще полностью развязать входные\выходные сигналы оптопарами с защитой от бросков с помощью тех-же трансилов или разрядников...Заземлить все, что можно ... В свое время делали табло по такому принципу, так оно даже при ударе молнии работало...

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

Покупали как-то ST-LINK/V2-ISOL. Сдох за 2 дня на ровном месте, пришлось вернуться к обычному, те годами работают. А этот всё руки не доходят починить.
Мне кажется, более универсальный вариант - коробочка с изолированным USB. Вроде такой http://mcutool.ru/products/isousb/slusbiso1.aspx

Вас там не уважают как спеца или схемотехник чей-то родственник?
На заре моей карьеры работал я в конторе, где тоже местный царёк ни в какую не хотел менять схемотехнику заведомо ущербную (что было очевидно всем коллегам). Он на использовании старого кривого оборудования получал хорошие откаты не вкладывая ни копья в исправление схемных проблем.
А мне также приходилось бороться с ветряными мельницами - ставил костыль за костылём, а баги всё новые вылезали. На простой задаче пришлось наворотить такого....
Один хрен - прошло совсем немного времени с моего ухода оттуда и всё то оборудование заказчикам пришлось выкинуть - из говна конфетку не сделаешь ни какими программными ухищрениями.
Сейчас жалею только что раньше не уволился. Жалею о бессмысленно потраченном времени, которое мог-бы посвятить полезным делам.
Так что - если такое отношение - не теряйте времени зря.

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

на трех-четырёх - лучше сделать jtag

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

Jtag сделан давно, там же нет двунаправленных линий и скорость может быть любая. Так что просто взяли пачку приемопередатчиков от цифрового аудио для световодов. Свободно отлаживались под потенциалом таргета 10-15 кв относительно земли.
Проблема в том, что в новых таргетах Jtag не выведен, только SWD.

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

Так в том то и проблема- как разобраться с двунаправленностью линии. Я же не даром ссылку кинул на https://www.lpcware.com/system/files/Isolat...g%20adapter.zip- там на микросхеме-изоляторе хитрая резистивная цепь для двунаправленности.

Нет там никакой проблемы. Посмотрите как SWD вешается на обычный JTAG - если у Вас есть решение для JTAGa то чтобы сделать из него SWD нужен аж один резистор (по крайней мере если через OpenOCD работаете).

а на самом деле таки да, только не один, а два - с двух сторон - линия же двунаправленная

На самом деле достаточно одного

Как работает думаю понятно из "схемы". Я уже не один раз воспользовался таким методом, ибо у меня только JTAG адаптер на FT2232D, а нужно было работать с контроллерами у которых только SWD.

вообще, вроде бы вопрос был про swd-swd, а не про jtag-swd

khach писал:

Я просто предложил вариант решения этой проблемы с помощью давно сделанного JTAGa и резистора

отлично, теперь у нас есть решения на все случаи жизни
остаётся только оптоволоконный канал в обе стороны запилить ;

Ну и как это решение трансформировать в оптическую световодную развязку? Что то не приходилось наблюдать двунаправленных световодов, если не использовать совсем уж навороченные приемопередатчики. Еще задержка в световоде приводит к неработоспособности таких простых схем на резисторах- получаем кольцевой генератор а не линию связи. Ну и с фронтами не все так хорошо- дешевые оптические конверторы затягивают фронта, надо их восстанавливать до подачи в SWD таргета. Моменты семплирования данных SWD в отладчике тоже проблема, т.к там весьма жесткая привязка к фронтам клока, а в реале на световодах и двух преобразованиях электричество-оптика- электричество задержка под 20-30 нс получается, что вылазит из спецификации.
В JTAGe с этим разобрались используя адаптивный клокинг, а в SWD как быть?

Может я Вас не правильно понял, но Вы сказали, что JTAG с опторазвязкой у Вас уже есть? Если так, то предложенное решение успешно конвертирует имеющийся JTAG в SWD. В JTAGe нет двунаправленных линий, потому откуда появляются двунаправленные световоды мне не понятно. В схеме задействовано две линии в направлении от JTAGa к SWD и одна обратно, все однонаправленные.


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


Может просто попробовать ? Как по мне это можно было сделать быстрее, чем ушло времени на описание проблем.

JTAG оптический то есть, но на новых таргетах JTAG-а нет. Только SWD. Никакой конверсии JTAG в SWD нет- то что сигналы разведены на одном и том же разьеме это никакя не конверсия, т.к алгоритм работы интерфейса совсем другой, т.е просто процессор отладчика программируется по-другому при смене режимов. Соотвествено SWD c развязкой не работает.
Я пробовал повторить схему гальваноразвязанного SWD не на Si8662BC, как в оригинале, а на ADUM- не заработало, да и по напряжению развязка на микросхемах слабовата- максимум до 1 КВ в реале, очень полезна отлаживать силовые преобразователи, но все равно бесполезна при отладке контроллеров тиратронов или БП азотных импульсных лазеров.

От же ж, а прочитать внимательно то, что я написал? Может несколько раз Я указал с чем это работает, и я в курсе, что JTAG и SWD это разные вещи, но вот связи с тем, почему оно работать не должно не вижу.
Используется три линии JTAGa, в штатном режиме, а чем они управляются это уже другой вопрос (у меня оно работает с OpenOCD/FT2232D). Подключите Вашу опторазвязку к указанному мной варианту и все заработает, вот так:

gdb<->OpenOCD<->USB<->FT2232D<->JTAG<->развязка<->JTAG<->схема с резистором<->SWD

Надеюсь теперь понятно (в этом варианте двухнаправленная развязка НЕ НУЖНА - только в одну сторону)? Если нет, то у меня закончились варианты как объяснить еще...

P.S. Если Вас раздражает слово JTAG можете его заменить на что угодно, т.к. в данном случае это просто набор сигналов .

Да не работает оно так.
Читаем для SWD http://infocenter.arm.com/help/index.jsp?t...b/BEHCBIJE.html

Вот эти времена и не выполняются из за задержек в оптике.
В обычном JTAG http://infocenter.arm.com/help/index.jsp?t...h/Babfagff.html

ограничения по времени более мягкие и главное действуют только в одну сторону по времени, и их можно оботи с помощью adaptive clocking
http://infocenter.arm.com/help/index.jsp?t...f/I1011184.html
Хотя это надо только для длинных световодов или медленных оптических преобразователей.

Вы пробовали? (Да/Нет)?


Это совсем не при делах, ибо задержки PROBE->TARGET на всех линиях одинаковые.


Эти требования легко выполняются при снижении частоты SWDCLK. Нет там никаких проблем.

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