Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Вопрос о конфигурации JTAG LPC210x
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
defunct
На плате выведен JTAG primary port, соответственно для входа в режим отладки с использованием этого порта подаю 1 на DBGSEL и RTCK. Но в таком состоянии автоматически занимаются и пины JTAG secondary порта ETM модулем. Мне эти пины крайне необходимы под отладкой для других нужд. Имеется ли возможность отключить ETM модуль?

Спасибо за внимание ;>
zltigo
Цитата(defunct @ Apr 7 2006, 07:25) *
Но в таком состоянии автоматически занимаются и пины JTAG secondary порта ETM модулем.

Все очень просто - они не занимаются "автоматически". Проблемы нет.
defunct
Цитата(zltigo @ Apr 7 2006, 09:08) *
Цитата(defunct @ Apr 7 2006, 07:25) *

Но в таком состоянии автоматически занимаются и пины JTAG secondary порта ETM модулем.

Все очень просто - они не занимаются "автоматически". Проблемы нет.


А как же тогда понимать вот эту информацию из UM (Table 169: JTAG Pins Selection):

Табличку нарисовать нормально никак не получается :-(

1) DBGSEL (After Reset)
2) Latched RTCK Value
3) JTAG Primary Pins
4) JTAG Secondaty Pins
5) ETM
Код
1      1    Yes       No                  Yes
0      1    N         SW config*           No
1      0    No       SW config*           No
0      0    No       SW config*           No

*Start-up-code residing in Flash should configure port pins P0.27-P0.31 for JTAG function by setting appropriate bits in
PINSEL1 register.

Primary JTAG port and ETM can be selected for debugging only when DBGSEL and RTCK pins are high at reset (see Figure
42). If at least one of DBGSEL or RTCK lines is low at reset, neither primary JTAG nor ETM will be enabled, and they could not
be used for later debugging. However, in these cases user’s application can assign secondary JTAG functions to pins P0.27 to
P0.31. While user’s code can redirect JTAG communication to the secondary JTAG pins, ETM functionality will not be available,
since ETM and secondary JTAG interface are sharing the same pins and consequently are excluding one another.

На практике - пины получаются заняты. Может быть я что-то не так включаю?
Подскажите как быть.. Нужен Primary порт и нужно чтобы secondary port был свободен
zltigo
Цитата(defunct @ Apr 7 2006, 08:20) *
1. А как же тогда понимать вот эту информацию из UM (Table 169: JTAG Pins Selection):

2. На практике - пины получаются заняты. Может быть я что-то не так включаю?
Подскажите как быть.. Нужен Primary порт и нужно чтобы secondary port был свободен


1. 10pin ETM активизируются уже позже через JTAG

2. Мои практические испытания показали, что ETM пины при работе по JTAG остаются в распоряжении.
Более того, попытка активизировать ETM по JTAG кончилась сообщением - "да нету никакого ETM девайса" от JTAG RDI.


Повторите свой экперимент еще раз.
defunct
Цитата(zltigo @ Apr 7 2006, 09:31) *
Повторите свой экперимент еще раз.


Повторил.. Та же беда.
Возможно ошибка на плате. Схема такая:
RTCK через Pull-up - 4.7k на Vcc,
DBGSEL через 4.7k - к перемычке между GND и Pull-up - 10k на Vcc.
При старте перемычка снята на DBGSEL и RTCK - 1, пины ETM заняты, и на них присутствует 0. Хотя в программе четко выдаю 1. Если замкнуть перемычку - DBGSEL = 0, пины ETM освобождаются и все работает как положено даже без сброса устройства...

Выбросил с платы 4.7k с RTCK, т.е. RTCK теперь просто висит в воздухе. Ситуация осталась прежней.

Проверил на нескольких чипах LPC2105Bxx/LPC2106Fxx поведение одинаковое..

кусок программы инициализации:
#define ETMPINS (1 << 31)|(1 << 30)|...|(1 << 22)

PINSEL0 = 0x00050005;
IODIR0 = ETMPINS;
// тест
IOSET0 = ETMPINS;

Так вот все 10 пин заняты sad.gif
defunct
Хех боюсь, что мне попались чипы как раз с ETM модулем:

при запросе статуса ETM по JTAG возвращает:

> es
Ok
> etm
ETM V1.2: 1 pairs of addr.comp, 0 Data Comp, 4 Mem-map decoders, 1 Counters
Data Trace: OFF (default)
Port Size: 4-bit
ETM port selection (bit 11) =1: Trace port pins Enabled
Mode, Clocking: Normal, Half-rate (Data on both clock edges, DDR)
Status: Trace start/stop is OFF
Sequencer state: 1 (1..3)


Попробовал записывать в регистр ETM Control разные значения, максимум чего добился -
1. При записи в ETM Control значения 0x02 - статус ETM - Trace port pins disabled
2. При записи в ETM Control значения 0x01 получаю статус ETM - ETM Powered down.
Однако в обоих случаях пины ETM порта остаются занятыми, и освобождаются лишь только если на DBGSEL подать 0.
zltigo
Цитата(defunct @ Apr 7 2006, 08:59) *
Цитата(zltigo @ Apr 7 2006, 09:31) *

Повторите свой экперимент еще раз.


Проверил на нескольких чипах LPC2105Bxx/LPC2106Fxx поведение одинаковое..

Повторил.. Та же беда.


Проблема в том, что я не имел дела (и уже не буду) с 2106 а в теме увидел более привычное
21xx а не 210x.
Все мною относится к 211x, 212x, 22xx. А у 2106 и подобных очевидно или все или НИЧЕГО. Труба дело.
Упомянутые мной чипы активизируют JTAG через RTCK и РАБОТАЮТ при этом c P1.16..P1.25 безвариантно.
defunct
Цитата(zltigo @ Apr 7 2006, 13:32) *
А у 2106 и подобных очевидно или все или НИЧЕГО. Труба дело.

sad.gif
Тогда вопрос, если использовать secondary port (активировать его в стартапе), получится ли нормально отлаживать устройство?
т.е. не выйдет ли так, что порт будет закрываться при программном сбросе устройства по jtag?
goodwin
Цитата(defunct @ Apr 8 2006, 12:31) *
Цитата(zltigo @ Apr 7 2006, 13:32) *

А у 2106 и подобных очевидно или все или НИЧЕГО. Труба дело.

sad.gif
Тогда вопрос, если использовать secondary port (активировать его в стартапе), получится ли нормально отлаживать устройство?
т.е. не выйдет ли так, что порт будет закрываться при программном сбросе устройства по jtag?



На сахаре - http://www.caxapa.ru/faq/lpc2000.html пишут по этому поводу:

При использовании основного JTAG (ножки P0.17..P0.21) также
включается отладочный механизм "EMBEDDED ICE LOGIC", в результате
чего выводы P0.22..P0.31 становятся недоступными при отладке.
Этого можно избежать, если воспользоваться вторым JTAG, имеющимся
в кристалле. Он занимает ножки P0.27..P0.31 и при отладке через
него все остальные выводы доступны, включая и ноги первого JTAG.
Для отладки через него не требуется использовать вывод DBGSEL.
Единственное требование - процессор после включения должен в своей
программе разрешить использование второго JTAG.
Для этого достаточно написать простейшую программу, где при
инициализации контроллера выполняется строка вида
"PINSEL1 = (1 << 22) | (1 << 24) | (1 << 26) | (1 << 28) | (1 << 30);"
Согласно стр.79 User Manual это и даст доступ ко второму JTAG.
Программу с этой строчкой после компиляции зашить стандартным
способом через UART0. Естественно, если есть желание в реальных
программах иметь доступ к такой отладке, эти биты PINSEL1 должны
оставаться настроенными именно таким образом.
ссылка
defunct
Цитата(goodwin @ Apr 8 2006, 23:23) *
На сахаре - http://www.caxapa.ru/faq/lpc2000.html пишут по этому поводу:

...
Программу с этой строчкой после компиляции зашить стандартным
способом через UART0. Естественно, если есть желание в реальных
программах иметь доступ к такой отладке, эти биты PINSEL1 должны
оставаться настроенными именно таким образом.


goodwin и zltigo, искрене благодарен вам! Спасибо за участие в решении моей проблемы ;>
Теперь осталось только перекроить плату, о результатах напишу.
zltigo
Цитата(defunct @ Apr 9 2006, 00:56) *
Теперь осталось только перекроить плату, о результатах напишу.

Сразу готовтесь шаманить с задержкой после сброса со стороны JTAG.
Ну а результат интересует - 2106 хоть и "старый", но пока пекордсмен по соотношению RAM
и количесства выводов. Сижу в задумчивости для одного из проектов 2106 или 2138/48.
defunct
Цитата(zltigo @ Apr 9 2006, 01:07) *
Сразу готовтесь шаманить с задержкой после сброса со стороны JTAG.
Ну а результат интересует - 2106 хоть и "старый", но пока пекордсмен по соотношению RAM
и количесства выводов. Сижу в задумчивости для одного из проектов 2106 или 2138/48.


Пока перекроил только разъем для проверки.

Пошаманить и правда пришлось, но не долго. В настройках RDI указал Reset strategy - Hardware, halt after reset (normal) delay 50ms. Если указать меньшую задержку, то при сбросе под отладкой JTAG с некоторой вероятностью теряет девайс.
Кроме того пришлось включить режим флешевых точек останова (use flash breakpoints).
Есть одна проблемка - первый старт происходит кривовато, точка останова сразу после включения порта не срабатывает, но если в отладчике нажать сброс, то вроде бы все нормализуется и можно вести отладку непосредственно с точки входа в main().
В программе в main() первым делом включаю PINSEL1 = (30 << 1)|(28 << 1)|...|(22 << 1). Позже думаю внесу эту строку в startup.s.

В остальном все ничем не отличается от работы по Primary порту. Работать можно. Программу с включением JTAG порта достаточно единожды залить в девайс по UARTу или через Primary порт, дальше можно программировать по JTAG Secondary порту (лишь бы в отлаживаемой программе также первой строчкой было включение JTAG порта). DBGSEL можно оставить N/C у него судя по мануалу есть внутренний pull-down.
zltigo
Цитата(defunct @ Apr 9 2006, 13:34) *
Пошаманить и правда пришлось, но не долго. В настройках RDI указал Reset strategy - Hardware, halt after reset (normal) delay 50ms.
Если указать меньшую задержку, то при сбросе под отладкой JTAG с некоторой вероятностью теряет девайс.
Есть одна проблемка - первый старт происходит кривовато, точка останова сразу после включения порта не срабатывает, но если в отладчике нажать сброс, то вроде бы все нормализуется и можно вести отладку непосредственно с точки входа в main().

Так по идее и должно быть. А с задержкой надо еще играться :-( и на 100% стабильность не рассчитывать. И инициализацию, естественно, прямо в startup. Ну первую точку останова куда подальше относить.

Цитата
Кроме того пришлось включить режим флешевых точек останова (use flash breakpoints).

Как это понимать? Железные вообще не работают?
defunct
Цитата(zltigo @ Apr 9 2006, 14:15) *
Как это понимать? Железные вообще не работают?


Ложная тревога, железные тоже работают
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.