Jump to content

    

К1986ВЕ92

Recommended Posts

demiurg_spb

Начинаем осваивать ARM-CM3 от Миландр К1986ВЕ92.

Сразу возник вопрос.

Можно-ли, используя лишь SWD, высвободить остальные ножки JTAG для собственных нужд (так же как это было в STM32)?

Share this post


Link to post
Share on other sites

Edit2007

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

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

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

При прямой записи в порт с JTAG интерфейсом есть шанс завесить отладку. Местная грабля.

 

Edited by редактор

Share this post


Link to post
Share on other sites

demiurg_spb
Скорее всего можно, только надо библиотеки подправить.

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

Да, это я заметил.

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

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

При прямой записи в порт с JTAG интерфейсом есть шанс завесить отладку. Местная грабля.

Нет слов.

 

Share this post


Link to post
Share on other sites

rus61
Начинаем осваивать ARM-CM3 от Миландр К1986ВЕ92.

Сразу возник вопрос.

Можно-ли, используя лишь SWD, высвободить остальные ножки JTAG для собственных нужд (так же как это было в STM32)?

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

Share this post


Link to post
Share on other sites

demiurg_spb

Выяснился один интересный момент.

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

Об этом миландр не пишет в своих ератах, а стоило бы...

Поэтому пришлось делать костыль и работать с этим портом лишь через его регистры.

 

Ну и ещё из того что изумило или озадачило:

1) Нет возможности защитить от чтения Flash (крест на коммерческих применениях).

2) Нет события UART TXC, соответственно с RS485 танцы с бубном.

Share this post


Link to post
Share on other sites

rus61
Выяснился один интересный момент.

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

Об этом миландр не пишет в своих ератах, а стоило бы...

Поэтому пришлось делать костыль и работать с этим портом лишь через его регистры.

...

 

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

Share this post


Link to post
Share on other sites

demiurg_spb

У меня и так нет проблем. Я же говорю, что при использовании BITBAND происходит не очевидный "read modify write" всего порта, хотя обращение идёт к биту напрямую.

А при явной записи в регистры с маскированием ясно дело что всё нормально. Я про этот костыль и говорю - он спасает.

На мой взгляд BITBAND на то и придумывался чтобы избежать подобных проблем.

Но в миландре ИМХО его (BITBAND) кривовато реализовали.

Share this post


Link to post
Share on other sites

rus61
У меня и так нет проблем. Я же говорю, что при использовании BITBAND происходит не очевидный "read modify write" всего порта, хотя обращение идёт к биту напрямую.

А при явной записи в регистры с маскированием ясно дело что всё нормально. Я про этот костыль и говорю - он спасает.

На мой взгляд BITBAND на то и придумывался чтобы избежать подобных проблем.

Но в миландре ИМХО его (BITBAND) кривовато реализовали.

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

Share this post


Link to post
Share on other sites

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,"

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

ViKo

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

Похоже, нигде, кроме JTAG, это не проявится.

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

 

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

Share this post


Link to post
Share on other sites

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.

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

Share this post


Link to post
Share on other sites

Golikov

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

 

REG |= VAL;

REG &= ~VAL;

 

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.