Ако проблемът ти е че не можеш да флашваш, ремапването там не играе. Позабравил съм ги нещата щото от доста време не съм използвал wiggler. А за CrossWorks имам само откъслечни спомени. Имаше някакъв конфигурационен файл, за съответния процесор, който трябваше да се укаже в настройките на CrossWorks-а. Понеже 23хх са сравнително нови и имат някои коренни разлики с предишните 2ххх, трябва да търсиш в папките на Cross-a конфигурационен файл точно за тази серия. Много вероятно е този конфигурационен файл да има грешки, направени волно или неволно и да не тръгва от първия път. При флашването на LPC2xxx се ползват команди към вградения bootloader, който от своя страна задължително иска да му се подаде като параметър клока на ядрото. Тук може да има засечки. Защото ако в момента процесора е програмиран трябва да знаеш как кода в него е конфигурирал клока. Ако не го знаеш можеш да го вкараш в bottloader режим преди да се закачиш към таргета(с pulldown на P2.10 за LPC23xx и ресет). Така ще знаеш с какъв клок е в момента таргета. Клока също май се указваше някъде по настройките на Cross-a.
Най-ясния ми спомен от комбинацията CrossWorks и wiggler е че като го нагласиш да работи и работи много добре, не ти се налага да се занимаваш с конфигурации и т.н. Но ако нещо не е наред нямаш много информация нито какво точно се опитва да прави, нито къде се дъни. Флашването го подкарах сравнително лесно, но когато исках да зареждам код във външна памет закачена за процесора ударих на камък. Това същото упражнение през OpenOCD не беше никаква грижа.
Ти като си решил да ползваш "кълбо от жици" за дебъгер що не пробваш да флашнеш процесора с FlahMagic през UART0. Да си сигурен че по платката с процесора нямаш проблеми, процесора е читав, не е заключен, кода е наред, чексумата на адрес 0x14 е коректна и т.н.
После може да пробваш само изтриване от CrossWorks и да провериш с FlashMagic дали изтриването е минало успешно. После пробваш флашване през CrossWorks и проверяваш с FlashMagic какво е записано в процесора. Малко дървено, но така се работи с "евтинджос" развойните средства.
Токущо пробвах при мен флашване на LPC2378 с wiggler-а от OLIMEX, OpenOCD и HyperTerminal. Всичко мина успешно. Това също е вариант да си провериш дали всичко освен настройките на CrossWorks е наред.

Щом разпознава, чете и пише значи много малка вероятност да е проблем с кабела. По-скоро ако pnp на windows нещо се обажда и чете/пише от порта или някаква подобна простотия.
За разлика от Zdrav смело мога да ти препоръчам yagarto. Последната версия има много голям напредък, бих казал невероятен напредък всичко е ново - нов Eclise, който по шарения надминава повечето комерсиални среди, нова весия на компилатора (GCC), в дебъгера (GDB) са махнали бая трески... а плъгин-а на GDB-то в Eclipse е направо като истински и да ти е кеф да дебъгваш
Наскоро излезе и по-прясна версия която вече поддържа и последния Insight но не съм я пробвал. Иначе ако ползваш OCD вече има конзола, което много би те улеснило точно с тези проблеми. През конзолата може да четеш/пишеш от таргета и да разбереш къде е проблема. Примерно ако всеки път четеш една и съща памет и четеш едни и същи стойности значи малко вероятно да имаш проблем с кабелите. Също може да провериш дали пишеш правилно в RAM и ако да, тогава вече може да мъчиш флаша. При флаша винаги има вероятност за проблем с агентите, дали си сложил правилни настройки за конкретния чип и т.н. Ако има проблем, добре е да видиш дали е случаен, т.е. дали бърка на случаен адрес или точно на определен адрес не става писането.
Изобщо конзолката е много полезно нещо когато искаш да локализираш проблема. Иначе дава ти някакъв абстрактен error и ходи го търси къф му е зора... Конзолата е през telnet и трябва OCD-то да е стартирано. Ти може и ръчно да го стартираш, но ако си настроиш бутонче за дебъг в yagarto, просто влизаш в дебъг и докато си в дебъг може да отваряш телнет към OCD.

Crossworks според мен не е добра идея. Хем GCC-базирано, хем не много съвместимо. Това за мен е ужасна простотия - да вземеш да режеш от въжмоностите на нещо безплатно и квото остане да го излъскаш... Ако държиш на истински комерсиални среди по-добре виж IAR или на Greenhills нещата. И двете са много по-добри решения. За greenhils нямам много опит, но отзивите са добри. IAR също не са лоши. Лошото е само че са комерсиални и то прекалено комерсиални - практически трябва да си спечелил от тото-то за да тръгнеш да им купуваш продуктите. Освен това при IAR e по-добре да ползваш JLINK. Не че wriggler/ocd няма да върви, но с JLINK e просто много стабилно.

благодаря на всички за съветите, мисля че когато отново се наложи да се захвана с wigglera ще съм доста по-ориентиран или поне имам материал за размисъл каква среда да ползвам. Временно се сдобих с CrossConnect така че създаването на работещо кълбо от жици се отлага за неопределено време но когато и да се наложи това, тръгне ли - ще се похваля

Извинявам се за оффпика, ама като чета темата, почвам да си мисля, че то било голям джумбиш с развойните средства за АРМ-овете, дописвания, додялквания, куче влачи рейс с една дума

Няма безплатен обяд.
Платените развойни средства си работят от раз

Аз малко така да се намеся в темата...
Някой ползвал ли е средата на ИАР с платката на олимкес с лпц2124 и JTAG-a им през паралелния порт? Интересно защо примерните проекти си вървят, т.е. дебъгването работи. но като поусложних малко програмата с още едно прекъсване не иска да дебъгва както трябва, а иначе като си пусна програмата да работи - няма проблеми?

Аз съм я ползвал точно с този Jtag. Ако се тровиш с вградения в IAR драйвер за Wiggler-a е голяма бозата. С H-Jitag през RDI работи долу горе стабилно.
Но като цяло от всички арм с които съм се борил с Wiggler-a най проблематична ми беше работата с тази платка точно.

С H-JTAG работя и го задавам като RDI, но както виждам при тия неща е нормално да не работи винаги...

Не работя с IAR, но и не знам какво имаш в предвид под нормално дебъгване.
Ако искаш постни кода и уточни какъв точно е проблема може да не е от средата или дебъгера.

Да питам и аз нещо по темата...

Имам target платка, на която JTAG-а на едно LPC2103 е изведен на 6-пинова рейка. На нея има Vcc, GND, TDO, TDO, TCK и TMS, но не и TRST. Той е с pull-up към Vcc-то на таргета. Олимекският ARM-USB-OCD го захапва така, разпознава го, но явно нещо не иска да го пише. Пробвам в CrossWorks-а това да го направя. OpenOCD също го вижда и уж влиза в debug режим, ама не съм седнал там да му разгледам скриптовете и да понапиша нещо.

Та, въпросът е, дали се държи така криво, защото няма TRST?

първо, предполагам, че едното TDO горе е всъщност TDI

много е възможно да не е точно TRST сигналът (но и той може да прави проблеми), а по скоро липсата на SRST опроводяване (трябва да е вързан към ресета на процесора); най-сигурно е да се опроводят поне и тези двата (TRST и SRST)

Първо, да, TDI е

Вързах SRST с една хвърчаща жица, но пак не става. Трябва да пробвам и с TRST... просто е много неудобно направено на платката. Хич не е гот така, с нестандартни конектори.

Вързах и двата Reset-а и седнах да се позанимая с OpenOCD... и все още нещо не се получава. По-точно - не иска да записва във flash-а. Един ред в конфигурационния файл на OpenOCD как ли не го въртях и суках, и уж не трябва да има там проблем, а все ме съмнява. Става дума за този:

flash bank lpc2000 0x0 0x40000 0 0 0 lpc2000_v1 12000 calc_checksum

Направих и един target script, дето да инициализира PLL и разни други неща. Да не би да има някаква друга особеност този вграден bootloader, дето през него се пише във flash-a?

При erase_sector не дава грешки, при flash protect също, въпреки, че всичките сектори си остават protected след като съм му дал да станат off. При четене няма проблеми, както и при четене/писане в RAM-а.

Поне сега знам, че хардуерът е наред...

Ако става въпрос за LPC2103 то е lpc2000_v2. Не знам дали това е проблема.
Не ти е нужно конфигуриране на PLL в скрипта така само ще омажеш нещата. Секторите на LPC2000 намат отделна протекция. Не се бори с това да ги сетнеш off. При този процесор "sector protection" няма значение. Защитата на FLASH-а там се прави по друг начин.
Размера на FLASH-a на LPC2103 не е 0x40000. Checksum-a най-добре си го сметни предварително.
И въобще защо не постнеш целия си конфигурационен файл и init скрипта та да поумуваме къде бъркаш.