К1986ВЕ92, SWD, высвобождение остальных ножек JTAG Опции

[demiurg_spb]

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

[редактор]

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


Сообщение отредактировал редактор - Jun 3 2014, 04:51

[demiurg_spb]

Скорее всего можно, только надо библиотеки подправить.
Там библиотека сделана таким образом, что при записи в порт маскирует все ножки JTAG.

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

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

Нет слов.

[rus61]

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

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

[demiurg_spb]

Спасибо!

[demiurg_spb]

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

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

[rus61]

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

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

[demiurg_spb]

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

[rus61]

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

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

[DmitryM]

Да проглядел, что речь о 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,"

[AHTOXA]

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

Не бред, всё так и есть:

The System bus interface contains logic that controls bit-band accesses as follows:

• It remaps bit-band alias addresses to the bit-band region.
• For reads, it extracts the requested bit from the read byte, and returns this in the Least Significant Bit (LSB) of the read data returned to the core.
• For writes, it converts the write to an atomic read-modify-write operation.
• The processor does not stall during bit-band operations unless it attempts to access the System bus while the bit-band operation is being carried out.

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

[ViKo]

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

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

[DmitryM]

А для управления битами портов bitband не нужен. Хватает средств и без него.

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

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

The memory map has two 32-MB alias regions that map to two 1-MB bit-band regions:

• Accesses to the 32-MB SRAM alias region map to the 1-MB SRAM bit-band region.
• Accesses to the 32-MB peripheral alias region map to the 1-MB peripheral bit-band region.

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

[ViKo]

Не думаю, иначе зачем
...
Другой вопрос, использовать или нет.

Да, вы правы.

[Golikov A.]

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

REG |= VAL;
REG &= ~VAL;

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

[ViKo]

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

REG |= VAL;
REG &= ~VAL;

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

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

[Golikov A.]

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

[ViKo]

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

[Golikov A.]

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

[ViKo]

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

[rus61]

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

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

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

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

Сообщение отредактировал rus61 - Jul 25 2014, 08:01

[ViKo]

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

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

[mantech]

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

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

[rus61]

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

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

[mantech]

Для тех же целей что и STM и LPC но в военных приборах.

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

[AVR]

Ну при экспериментах будте готовы, что придется стирать МК через UART.

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

[LightElf]

А как это понимать? Микроконтроллеры от Миландр можно прошивать и стирать через UART?

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

т.е. я могу зашить свою программу не покупая программатор?

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

На каких официальных отладочных платах это работает?

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

[demiurg_spb]

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

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

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

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

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

[RuSTA]

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

[demiurg_spb]

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

[mik109]

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

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

[AVR]

Проверено на LDM-K1986BE92QI.

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

[AVR]

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

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

[rus61]

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

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