Микроконтролери и електроника
http://mcu-bg.com/mcu_site/

LPC ARM7 JTAG debugging
http://mcu-bg.com/mcu_site/viewtopic.php?f=2&t=9058		 Страница 1 от 3
Автор:  harleybg [ Чет Юли 28, 2011 5:33 pm ]
Заглавие:  LPC ARM7 JTAG debugging
Здравейте.
До сега съм се занимавал само с PIC-ове и реших да премина към LPC. Те се програмират и дебъгват през JTAG и тук нещата не са ми много ясни. За дебъгваща и програмираща среда ще ползвам Eclipse, тъй като е безплатен. Проблема е хардуерната връзка. Нямам паралелен порт и вероятно ще трябва да използвам FT245. Мога ли да дебъгвам микроконтролера, ако е закачен директно към FT245? Каква ще бъде горе-долу скоростта на лоудване на програмата? Какво е по-специалното при заводските дебъгери? Май някой JTAG команди се изпълняват по-бързо... има ли значителна разлика в скоростта на запис? Ако не е удачен вариант само използването на FT245, можете ли да ми покажете някоя добра схема.

Благодаря. :)
Автор:  miro_atc [ Чет Юли 28, 2011 6:43 pm ]
Заглавие: 
1. ARM7 няма да се развива повече, защото се заменя с Cortex M3. Вторият е за препоръчване ако тепърва започваш.

2. Еклипс е само среда. Към него трябва да интегрираш компилатор+линкер+дебъгер. Този комплект се нарича тулчейн. Предполагам ще използваш някакъв GNU тулчейн. Аз ти препоръчвам ягарто (www.yagarto.de). Има една тема за "изпитан тулчен" в тоя форум, може да я прочетеш...

3. Към дебъгера ти трябва и някакво "желязо" за джейтага, което се нарича "Jtag емулатор". Има много "заводски" и незаводски... Ако търсиш решение с FTDI чип виж OpenOCD - има схеми в нета, всичко е опън сорс. Към о-це-де-то върви и софтуер който трябва да свалиш/компилираш/инсталираш/конфигурираш...
След това ако ще ползваш Еклипс като потребителски интерфейс може да му инсталираш и един плъгин (zylin) за връзка с дебъгера и с емулатора. Оригиналният плъгин на Еклипса не е много добър.

4. Скоростта на download не я мисли. Ограничава се първо от USB-то (няма как да е по-висока) и второ от jtag клока, който пък няма как да е по-висок от клока с който работи проца ти в момента. А като пишеш по флаша се ограничава от скоростта на писане и т.н. Но в общия случай се постига 30-40kB/s т.е. в най-лошия случай за няколко секунди ще "лоадваш"...

ОЦД-то има проблем със скоростта на трейсване.. При ARM7 има DCC канал, а при Куртекс ако искаш трейс по-добре си предвиди двоен FTDI чип за да хванеш SWO-трейса, пък ще дебъгваш по SWD (вместо jtag).

5. За повече информация виж тук ;-)
Автор:  harleybg [ Чет Юли 28, 2011 10:08 pm ]
Заглавие: 
Благодаря за отговорите.
"Emulation trace module supports real-time trace."
Това е от документацията на процесора. Не означава ли, че не ми е необходим допълнителен хардуерен емулатор?
Автор:  miro_atc [ Чет Юли 28, 2011 10:38 pm ]
Заглавие: 
"трейс" е общо понятие... означава проследяване и има много неща за проследяване.

Най-просто (това което имах предвид) в възможността в софтуера да си оставяш "следички" от типа:
Код:
printf("тук май сгазих лука");


При АРМ7 за това може да се ползва DCC (debug communication chanel) и не изисква нищо повече от JTAG. При Cortex се ползва SWO пин и изисква хардуер (поне UART). Разбира се ти винаги може да ползваш UART, USB или нещо друго за трейсване, но наличието на "безплатен" и стандартен начин е голямо улеснение.

Друг, много по-сложен трейс е възможността процесора да трейсва какви инструкции изпълнява, от какви адреси и т.н. Тоя тип трейсове обикновено се записват и ако успееш да запишеш всичко след това може да се възпроизведе всичко каквото е правил процесора. Но дори и да не е всичко пак е полезно, щото може да направиш статистика каква част от кода се изпълнява най-често и т.н.
За тоя тип трейсове при АРМ7 ти трябва да имаш изведен ЕТМ порт, което е голяма рядкост. Трябва и специализиран (скъп) хардуер и софтуер.
При кортексите трейса може да се изкарва през SWО-то, т.е. на теория може да ползваш и решението с двоен FTDI чип. На практика обаче ще хванеш много малко данни. Изобщо за тоя тип трейсове си трябва специализиран хардуер (трейс емулатор).
Автор:  harleybg [ Чет Юли 28, 2011 10:50 pm ]
Заглавие: 
"За тоя тип трейсове при АРМ7 ти трябва да имаш изведен ЕТМ порт, което е голяма рядкост. Трябва и специализиран (скъп) хардуер и софтуер. "
На мен ми е нужно да мога да наблюдавам променливите и да мога да изпълнявам на места програмата стъпка по стъпка.
"Emulation trace module supports real-time trace."
Както се има предвид emulation
Автор:  miro_atc [ Пет Юли 29, 2011 7:42 am ]
Заглавие: 
нямаш грижи...
Автор:  Zdrav [ Пет Юли 29, 2011 8:38 am ]
Заглавие: 
ETM - Embedded Trace Macrocell, това е различно от EmbeddedICE към който се закача JTAG. (Сега виждам че в документацията на по-новите LPC2000 е въведен и термина "embedded trace module" и "emulation trace module".)
Миро ти е посочил един от вариантите - YAGARTO + OpenOCD. Ще трябва и доста четене от твоя страна.
Като удариш на камък питай тук :)
Автор:  Цецо [ Пет Юли 29, 2011 9:52 am ]
Заглавие: 
miro_atc написа:
1. ARM7 няма да се развива повече, защото се заменя с Cortex M3. Вторият е за препоръчване ако тепърва започваш.


Миро ти го е казал - не се занимавай с ARM7 ако не ти го налага нещо отвън - задание, шеф и т.н. Ако можеш да избираш вземи ядро с Кортекс М3 - по нови са, по евтини, по-по-.... и т.н. АРМ7 е пътник, т.е. на доизживяване.
Автор:  harleybg [ Съб Юли 30, 2011 9:43 pm ]
Заглавие: 
Убдеихте ме :D ще ползвам кортекс.
Но поне в началото смятам да ползвам Keil uVision.
http://elk.informatik.fh-augsburg.de/hh ... bjtag.html
Тези FTDI чипове могат ли да се подкарат с опция "Cortex-M/R J-LINK/J-TRACE" или няма да се получат нещата?
Автор:  miro_atc [ Нед Юли 31, 2011 11:40 am ]
Заглавие: 
harleybg написа:
Но поне в началото смятам да ползвам Keil uVision.


Странна логика... Все едно от София да тръгнеш към Видин, но в "началото" да минеш през Бургас.
Отдели малко повече време за проучване и реши накъде точно искаш да тръгнеш...

Цитат:
Тези FTDI чипове могат ли да се подкарат с опция "Cortex-M/R J-LINK/J-TRACE" или няма да се получат нещата?

С FTDI се прави OpenOCD, това е различно от JLink, камо ли от JTRACE

Ако искаш JLink има клонинги, даже май беше изтекла и схемата и фърмуера тъй че ако много държиш може да си го направиш сам. За Jtrace не съм чувал да има схеми, но мисля че братята китайци продават клонинги. Но аз не ползвам продуктите на segger и не съм в час с последните слухове ;-)
Автор:  Zdrav [ Нед Юли 31, 2011 2:10 pm ]
Заглавие: 
harleybg, вземи си нещо подобно на това:
http://www.st.com/internet/evalboard/product/250863.jsp
http://www.emcu.it/STM32Discovery/STM32 ... overy.html
Сега има толкова достъпни развойни платки. Ще загубиш време в лепене на FTDI JTAG сонди.
Автор:  Цецо [ Пон Авг 01, 2011 10:16 am ]
Заглавие: 
Ако минеш на keil ще трябва да се оправяш сам. Тук във форума никой не го ползва... май.

Основно се ползва GCC+Eclipsе или IAR.

Като дебъгер OpenOCD+FTDI (най-евтиния и достъпен вариант) или J-link. Това е което ние ползваме и можем да окажем подкрепа. За другото си сам.
Автор:  michev [ Пон Авг 01, 2011 11:07 am ]
Заглавие: 
Имам разработка на орязан (липсва само допълнителния сериен порт) "flyswatter" - OpenOCD+FTDI, проектирана платка за изпълнение в домашни условия (2 странна).
Ако някой проявява интерес - да пише.
Автор:  [ Пон Авг 01, 2011 9:43 pm ]
Заглавие: 
Сега погледнах какво използвам :) , нарича се Ride7 + GCC 4.3.xxx + RLink. Средата e шарения като Eclipse, като за без пари е добре. Не съм видял да има поддръжка на Version Control ( използвам SVN в MPLAB и ме дразни липсата ). Не може да генерира или да използва makefile, само с неговия си формат. Поддържа всички STM32/STM7/STM9 + LPC17/21/24xxx. Не поддържа друго желязо освен RLink. Гледам, че в OpenOCD е вкарана поддръжка на RLink, тия дни ще го видя работи ли. RLink е ограничен до 32kB Debug, отключването струва 70 евро. Горе-долу стабилна среда, средно гърми веднъж на ден...

Като цяло дебъгването/програмирането е мнооого бавно, то първо се свързва с GDB, после изскача нещо с надпис Jungo-Мунго драйвер, после докато изтрие паметта, докато програмира и брада се хваща. Към 50 секунди трае процедурата от натискането на Debug до реалното стартиране на програмата ( размера на програмата в Flash е около 150kB ). Не знам дали и при останалите ARM среди и дебъгери е така ( просто това ми направи впечатление, щото примерно при MPLAB с RealICE & PICKit2/3 при сходен размер на програмата всичко става за няколко секунди ). А може би е доста бавно щото в вързано по SWD. Веднъж обаче като захапе дебъгването е с прилична скорост, да речем нещо като PICKit2.
Автор:  harleybg [ Вто Авг 02, 2011 12:51 am ]
Заглавие: 
¶ написа:
... Не знам дали и при останалите ARM среди и дебъгери е така...

Това вече е интересно. Нека споделят хората :)
Страница 1 от 3 Часовете са според зоната UTC + 2 часа [ DST ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/