Comments 28
Задача не верно поставлена. Первым делом нужно было посетить производственную линию и посмотреть как этот вопрос решают другие. Не нужно изобретать велосипед.
1) Нужно делать тестинг джиг. Внутри размещается ардуино для проведения тестов и J-Link. Если финансы позволяют, то можно поставить даже оригинальный J-Link. Но обычно ставят китайца.
2) Покупается обычный ноутбук и к нему подключается тестинг джиг.
3) У нордика скачивается SDK для работы с J-Link. Или можно купить у Segger SDK
4) В Visual studio пишется софт для автотестирования и установки прошивки.
5) Если используется китайская версия J-Link. То нужно скачать старую версию коммандера и поставить старую прошивку.
Все. Не нужно изобретать велосипед. Так можно сэкономить много времени и денег
Не нужно быть таким категоричным.
Реализация оффлайн программера без ноутбука и специального загрузчика с помощью автономного дополнительного блока очень хорошая вещь, так как серьезно уменьшает трудоемкость данной операции и значительно понижает требования к персоналу (которому достаточно вставить разъем и нажать кнопку для обновления прошивки).
Ок. Сходите на производство. "которому достаточно вставить разъем" эта фраза выдает то, что вы не видели конвейер.
С чем конкретно вы не согласны? Или считаете, что не может быть задач, для которых простой оффлайн программатор значительно лучше, чем ноутбук?
Я же написал. Для производственной линии. Ваше решение не будет работать так как вы думаете.
1) Вам начнут задавать кучу вопросов на тему, что и куда воткнуть. Ваше устройство не стандартное. Для работы нужен специалист.
2) "воткнуть кабель". Кабель для программирования очень быстро выйдет из строя и как вы будете это мониторить не ясно.
3) Ваше устройство о наличии ошибки максимум сообщит миганием светодиодов. Это не информативно. Вы не поймете где именно проблема.
4) Для крупной серии невозможно купить одинаковые компоненты. Всегда закупаются аналоги. Все комбинации компонентов протестировать невозможно. Нужно всегда вести лог файл. В котором будет записано какое устройство и какой дефект. Если есть лог фай, тогда можно вычислить какая комбинация элементов дала такую ошибку.
5) "воткнуть кабель" невозможно автоматизировать. Для автоматизации тестингджига используют обычный пневмопресс. И обычный софт под винду.
6) специализированное устройство всегда дороже. Ноутбук за 1к$ всегда дешевле. В случае с ноутбуком одни и теже проверенные наработки можно использовать везде и со всеми устройствами.
Если вы будете предлагать на производстве свое решение, то после спора с вами вам предложат прислать своего инженера на завод который будет заниматься установкой прошивки. Это влетит в немалые деньги. Одна экскурсия на завод стоит гораздо дешевле чем производственный ад.
Вы написали, как сделали вы. Да, для крупных партий с квалифицированным персоналом это действительно имеет смысл.
Но почему вы считаете, что ваше решение единственно верное? Только потому, что у вас оно на малинке не получилось? Ну так на распбери однозначно не самое лучшее для этого решение.
Может быть кому-то гораздо выгоднее унифицировать процесс установки и обновления прошивки на производстве и в полях, причем сделать его повторяемым для сборщиков и тестировщиков и в тоже время максимально простым даже для самых низкоквалифицированных работников (которые гайки вертят для снятия блоков).
В нашем случае производитель контрактный. На вопрос "А есть ли у вас стандартная процедура проверки (например при помощи станции периферийного сканирования JTAG)?" ответ был вроде: "Пришлите нам тестовую оснастку с кнопкой СТАРТ и двумя светодиодами". Я молчу про экскурсию на производство. Поэтому был выбран описанный способ решения задачи. Кроме того наши устройства достаточно простые, и лог хода теста через USB выводится на ПК.
Еще из опыта. Работая с контрактником из Китая, мы также предоставили им оснастку с логированием. На что получили вопрос, можно ли не подключать её к компьютеру. Т.е. речь в скорости проверки и квалификации персонала, если изделия простые и процент брака невысок, то pogo pins и светодиодов ДА, НЕТ, вполне достаточно.
Купить пк гораздо дешевле, чем платить за специализированное решение. Сколько времени и денег ушло на разработку? Я обычно на тестинг джиг трачу от 3 до 5 дней. Софт из готовых наработок собрать ну неделька, две. Причем этот тестинг джиг проверяет напряжение, ток, пины, внутренние компоненты.
Я однозначно изучу тестинг джиг более подробно, с таким решением не доводилось работать. Разработка специализированной оснастки занимает около месяца + некоторое время, чтобы получить стабильный результат. В ходе испытаний на серии уточняется алгоритм проверки.
Зато те же самые китайские коллеги сами делают нужное число проверочных устройство по готовому проекту. Экономия n-числа ноутбуков. Или другой пример из жизни. Довелось делать аналогичную специализированную плату (без программирования) для автоматизированной линии. Проверяемые устройства перемещаются по конвейеру, а оснастка опускается сверху. На выходе сигналы для робота WAIT, DONE, STEP и т.п.
В общем все зависит как от задачи, так и производителя, каждый подход хорош по своему.
Интересно, а не проще ли было взять какой-нибудь одноплатник или даже VoCore, и запустить на нем OpenOCD?
Можно и одноплатник, на котором запускать скрипт для ноутбука.
Просто в этом случае решение получается более тяжеловесным (linux, драйверы, скрипты и т.д. с применением дополнительного оборудования (отдельный программатор).
Решение с автономным SWD программатором сложнее в реализации, но значительно проще и дешевле в поддержка и эксплуатации, особенно при работе "в полях".
Я так делал. Не проще. Я один раз слепил тестинг джиг на распберри и тысячу раз пожалел.
1) пины у распбери вялые и горят при каждом чихе. Пришлось городить защиту.
2) как оказалось у расбери все ужасно с бит бендингом. Пришлось каждый расбери каллибровать вручную с осциллографом.
3) SD карты как оказалось разные. Нельзя просто взять и скопировать образ. Пришлось натурально по почте высылать SD карты с нужным размером блока.
3) У нордика скачивается SDK для работы с J-Link.
А можно ссылку для загрузки этого SDK ?
https://www.nordicsemi.com/Products/Development-tools/nrf-command-line-tools
Все, что нужно для интеграции J-Link, в свое приложение, находится в папках lib и include. Также у них на сайте можно почитать более развернутое описание функций. Это усеченная версия, работает с Cortex-M3. Но зато бесплатная
В поиске яндекса не нашёл никакой хорошей статьи о "тестинг джиг".
Предлагаю вам написать статью, где вы описали бы что это, для чегои как используется. Приемущества. Вдруг вы втянетесь и напишите цикл полезных и достаточно уникальных статей)
У микросхем нету/небывает ножек, есть ВЫВОДЫ.
Спасибо! Интересная статья и тема и что из этого выйдет!? Жду продолжения!
Интересно, автор добавил в комплект программатора щуп от осциллографа или нет? Просто базавая инициализация, использованная в этом коде DAPProg дает (приблизительно 50%/50%) успешной инициализации. Что предполагает повторное выполнение инициализации, если она была неуспешна. Это выглядит как костыль, но скорей всего в профессиональных программаторах выполнено также. Мне кажется, что именно это стало причиной нестабильной работы, а не проблемы целостности сигналов. Ведь проблема в коде точно есть.
ножка SWCLK была настроена на Very High Speed, а частота линии составляла несколько сотен килогерц. После обнуления регистра OSPEEDR все заработало как надо...
В моём случае проблема решилась настройкой ножки SWCLK. При эксплуатации мы несколько раз сталкивались с конструктивными проблемами (соосность иголок и тестовых точек, надежность иголок, окисления и т.п.). Т.е. основные проблемы были связаны с плохими контактами.
Расскажите об участках кода, в которых, по вашему мнению, есть проблемы. Возможно, информация будет полезна сообществу.
В чем суть проблемы: иногда инициализация завершается неудачно. Характер поведения очень похож на то, что описал автор. Но присоединенные щупы никак не влияют. Пробывал в LOW speed и ножки SWDIO и CLK загонять - не помогает. А вот то, что все выглядит именно как проблема целостности сигналов, - это да.
Подшаманил: длину шины сократил и провода все вместе собрал и подтяжку напаял, да и последовательно на десятки Ом резисторы всегда добавляю - ничего не помогает. Да, практики работы с данным интерфейсом ( в качестве пользователя) у меня много, бывало, что и по полметра шнурки делал и проблем не было.
Но заметил, что если инициализация прошла успешно, то пишет/читает/ стирает без проблем, что все таки указывает на проблемы в коде. Разобрался с инициализацией - последовательность выглядит корректно и должна работать. Там в самом коде инициализация вызывается два раза. Что уже повышает шанс на успешную инициализацию. Но не всегда. У меня на некоторых попытках приходилось до 7 попыток делать.
Как результат target_flash_init() загнал в цикл, с выходом, когда инициализация прошла успешно. swd_init_debug() удалил за ненадобностью. Она повторно вызывается в target_flash_init(). CODEID читаю после.
Конечно, это все выглядит как костыль, но мне попадались источники, которые говорят, что применение правильной последовательности и кода не гарантирует 100% подключения к ядру и памяти. И что в проф. устройствах также сделано. Да, к DP подключится проблем нет. И CODEID всегда читается идеально, но что дальше через AP будет - неизвестно. Выходит, что и не костыль.
Ну и добавил между кадрами небольшие паузы - и мне разбираться проще и подчиненному жить. Еще добавил в конец кадра так называемы "трэйлинг биты" - 8 бит тактирования при низком на DATA - для большей стабильности. Под кадром понимаю единичное сообщение SWD.
Автономный программатор SWD