Начинаем осваивать ARM-CM3 от Миландр К1986ВЕ92.
Сразу возник вопрос.
Можно-ли, используя лишь SWD, высвободить остальные ножки JTAG для собственных нужд (так же как это было в STM32)?

Скорее всего можно, только надо библиотеки подправить.
Там библиотека сделана таким образом, что при записи в порт маскирует все ножки JTAG.
Ну при экспериментах будте готовы, что придется стирать МК через UART.
При прямой записи в порт с JTAG интерфейсом есть шанс завесить отладку. Местная грабля.

Да, это я заметил.
И подумал про себя что за....
Нет слов.

Можно, не каких аппаратных проблем нет. Понадобятся только SWDIO (TMS), SWCLK (TCK) и GND. Если вдруг программой переназначите пины или остановите тактирование МК, то переведите МК в режим роботы с внешней ROM (с полным обесточиванием) и спокойно стирайте контроллер через SWD.

Спасибо!

Выяснился один интересный момент.
Если обращаться к порту (к не SWD пинам) в котором находятся линии SWD через BITBAND, то SWD отваливается, с JTAG аналогично.
Об этом миландр не пишет в своих ератах, а стоило бы...
Поэтому пришлось делать костыль и работать с этим портом лишь через его регистры.

Ну и ещё из того что изумило или озадачило:
1) Нет возможности защитить от чтения Flash (крест на коммерческих применениях).
2) Нет события UART TXC, соответственно с RS485 танцы с бубном.

Проблемы возникают при "read modify write" из за того что Вы пишите в JTAG пины "мусор" который вычитали во время стадии "read". Если перед "write" наложить маску на эти биты (обнулить), то проблем не будит. Как пример посмотрите SPL.

У меня и так нет проблем. Я же говорю, что при использовании BITBAND происходит не очевидный "read modify write" всего порта, хотя обращение идёт к биту напрямую.
А при явной записи в регистры с маскированием ясно дело что всё нормально. Я про этот костыль и говорю - он спасает.
На мой взгляд BITBAND на то и придумывался чтобы избежать подобных проблем.
Но в миландре ИМХО его (BITBAND) кривовато реализовали.

Да проглядел, что речь о Bit-band, но смысл от этого не изменился. По факту при записи в Bit-band регион ядро делает последовательность "read modify write", которая является атомарной (S-bus блокируется до окончания записи, но само ядро может продолжать выполнять команды если не требуется доступа к S-bus). Механизм Bit-band реализован не Миландром, а ARM и описан в TRM на Cortex-M3.

Бред. "Bit-banding provides atomic operations to bit data,"

Не бред, всё так и есть:
(И я не совсем понимаю, как Миландр мог накосячить в бит-банде, если это функция ядра.)

Значит, bitband представляется программной атомарной операцией, но это не означает аппаратного чтения-модификации-записи только одного бита.
Похоже, нигде, кроме JTAG, это не проявится.
А для управления битами портов bitband не нужен. Хватает средств и без него.

P.S. Можно прийти к выводу, что bitband имеет смысл использовать только для тех битов, которые устанавливаются (сбрасываются) программно - для битовых переменных.

Не думаю, иначе зачем

Другой вопрос, использовать или нет.

Да, вы правы.

я так понимаю основное назначение бит-банда это ускорение операций типа

REG |= VAL;
REG &= ~VAL;

замена чтение, изменения, записи (3 операций) на одну битбандвую... Я не прав?

Да. И, как выясняется, та же последовательность делается аппаратно, только программа этого не "видит".

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

LOAD и STORE выполняются за 2 такта. За сколько выполняется bitband запись, не сказано. Видимо, за столько же.

что делать тогда с атомарностью процедуры?
где то я читал что ногами шевелили через бит банд, потому что быстрее чем в порт писать, но может я что-то не верно помню...

С атомарностью ничего не делать, пользоваться.
Битбэнд быстрее, если обращаться к порту через ODR, но есть еще BSRR, безо всякого чтения-модификации-записи.

Минимум три такта системной частоты на read-modify-write плюс такты работы с памятью/периферией (выставление адреса, ожидание выставления данных и т.д.), на это время системная шина будит заблокирована, но выполнение команд продолжится(если не требуется доступ к шине иначе ядро будит ждать). Для программы операция на 100% атомрная и вероятно выполняется за один такт (т.к. не нужно ждать доступа к памяти/периферии).



BSRR в К1986ВЕ92 к сожалению нет.

Это печально. Объясняет...
Выходит, Миландр купили ядро Cotrex, а периферию "слепили из того, что было".

Сорри за оффтоп, но вот интересно, эти контроллеры для каких хоть целей используют? До "нормальных" мк ст или лпс они еще недотягивают по функционалу, а уж по цене - тут вообще без вариантов. Что у них есть такого "сильного", чтоб их выбирать?
ЗЫ Ну кроме указаний свыше - "использовать отечественную эл. базу"

Для тех же целей что и STM и LPC но в военных приборах. Если Вы думаете, что импортные МК милитари класса дешевле, то я Вас разочарую, они стоят также, а то и дороже. Посмотрите на стоимость микросхем от TI, к примеру http://www.ti.com/product/SMJ320C25/samplebuy - 388$ и это за древний 16-разрядный DSP при прямой поставке от 100 шт.

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

А как это понимать? Микроконтроллеры от Миландр можно прошивать и стирать через UART?
т.е. я могу зашить свою программу не покупая программатор? На каких официальных отладочных платах это работает?

Какбы да. Я даже уже и не припомню мелкий ARM без такой фичи.

Именно. Но возможности удобной отладки потеряете.

Да вроде на всех должно. Там надо ножки правильно выставить. Если разработчик платы не накосячил.

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

Кстати про уарт забыли как только поняли причину отваливания JTAG (писал об этом выше).

Ещё коллегой был пофикшен openocd в связке ST-LINK + K1986 (тип контроллера не принципиален) :
http://openocd.zylin.com/#/c/2217/

Теперь SWO-консоль не отваливается

Проблему с отваливающимся JTAG А и Б решал с помощью переключения на внешнию флеш. Стирается и записывается без проблем.

Судя по доке этот приём должен проходить лишь для JTAG Б.

Если на плате не выведены другие интерфейсы и нет возможности менять вариант загрузки применяю на стадии отладки перед инициализацией портов пустой
цикл секунды на две. Когда по недосмотру в программе валим JTAG, можно будет успеть стереть чип.

Спасибо за подсказку. Купил эту плату, действительно шьется по UART

У меня появился вопрос... их программа 1986WSD.exe действительно прошивает, однако требуется там нажать Run чтобы программа начала работать. А при сбросе питания - пусто, программы нет, не работает. Не представляю - куда же оно там зашилось, или надо что-то сделать чтобы оно начало работать при включении питания при таком способе прошивки? Подозреваю переключатели M0/M1/M2 на плате за это отвечают.

По видимому Вы после прошивки по UART не перевели МК в режим работы с Flesh (M0/M1/M2 = 0/0/0).