Микросхема AT91SAM7S32 c IAR
Отладка в RAM работает нормально.
Пытаюсь отладить во FLASH - полный бред. Вылетает черт знает куда.
Поменял конфиг линковщика на at91SAM7S32_FLASH.xcl,
файл отладчика на SAM7_FLASH.mac (оба файла скачал с Atmel)
поставил use flash loader
в настройках линковщика Allow C-spy specific extra output file
в extra outputs - simple code

теперь IAR руграется на невозможность инициализации debug режима или неверности формата файла Flashat91sam7Sx.d79

Пожайлуста, напишите по шагам, что нужно делать для отладки во Flash и, если можно, прикрепите необходимые файлы, а то я где-то прочитал, что и at91SAM7S32_FLASH.xcl надо как-то править

Заранее благодарен.

Две ошибки:
- использование IAR
- использование Atmel

Правильный вариант: KEIL + Philips или ICCV7ARM + Philips.

Дельный совет, спасибо. Главное вовремя.


Да, кстати, а как отлаживать c ICC по JTAG?

Вот тут посмотрите.

ICCV7 и JTAG
Imagecraft продаёт дополнительную утилиту
$ 159.00 NoICE-ARM Debugger

* Debugger program for use with ICCV7 for ARM. NoICE-ARM is fully compatible with Segger J-Link and other JTAG pods.

http://www.imagecraft.com/purchase_ARM.html?

А где можно купить NoICE-ARM?

Купить можно непосредственно на www.imagecraft.com
А бесплатно скачать можно здесь:
http://elmicro.com/files/noice/
но без лицензии она будет работать 30 дней.

Следующее подобное голословное суждение с нарушением правил форума неизменно повлечёт за собой предупреждение.
Что касается темы, то упомянутая связка IAR, Atmel, отладка во flash работает на ура. Били бы руки прямыми (это не к автору темы). Внимание следует обратить на запуск загрузчика и настройки отладчика. Ссылку уже давали, повторяться не буду.

А всетаки ответит кто нибудь на данный вопрос? у меня тоже такая проблемка.

Выше ссылку давал. "Делай раз, делай два, делай три". Сообщение о неверности формата файла Flashat91sam7Sx.d79 получал, но не могу вспомнить какова была причина. Что-то эелементарное, скорее всего пытался отлаживать проект под SAM7 когда к отладчику был подключен LPC. В остальных случаях все работает.

вроде разобрался немного, отредактировал flasher поставил там $TOOLKIT_DIR$\config\flashloader\Atmel\FlashAT91SAM7Sxx.d79.

Пошло вреде, заливает во флеш но неправильно.... привожу LOG.
Wed Apr 25 20:28:29 2007: Loaded macro file: C:\Program Files\IAR Systems\Embedded Workbench 4.0 Evaluation\ARM\config\flashloader\Atmel\FlashAT91SAM7Sxx.mac
Wed Apr 25 20:28:29 2007: JTAG API v48.32, Wiggler v1.41, ARM ID: 3F0F0F0F
Wed Apr 25 20:28:29 2007: ---------------------------------------- FLASH Download V1.3
Wed Apr 25 20:28:29 2007: ---------------------------------------- 14/November/2005
Wed Apr 25 20:28:29 2007: ---------------------------------------- PLL Enable
Wed Apr 25 20:28:29 2007: -------------------------------Set CPSR ----------------------------------
Wed Apr 25 20:28:29 2007: CPSR 000000D3
Wed Apr 25 20:28:29 2007: ---------------------------------------- PLL Enable
Wed Apr 25 20:28:29 2007: ------------------------------- The Remap is done ----------------------------------------
Wed Apr 25 20:28:29 2007: ---------------------------------------- Chip ID 0x27090540
Wed Apr 25 20:28:29 2007: ---------------------------------------- Extention 0x00000000
Wed Apr 25 20:28:29 2007: ---------------------------------------- Flash Version 0x00000110
Wed Apr 25 20:28:29 2007: -------------------------------Set PC ----------------------------------------
Wed Apr 25 20:28:34 2007: 5096 bytes downloaded and verified (1.09 Kbytes/sec)
Wed Apr 25 20:28:34 2007: Loaded debugee: C:\Program Files\IAR Systems\Embedded Workbench 4.0 Evaluation\ARM\config\flashloader\Atmel\FlashAT91SAM7Sxx.d79
Wed Apr 25 20:28:34 2007: Target reset
Wed Apr 25 20:28:35 2007: Downloader Version 1.31 (04-Dec-2006)
Wed Apr 25 20:28:35 2007: Download1 : AT91SAM7Sxx at: 0x100000
Wed Apr 25 20:28:36 2007: Download : AT91SAM7Sxx Version: 0x110
Wed Apr 25 20:28:39 2007: Download : page 0
Wed Apr 25 20:28:42 2007: Download : page 1
Wed Apr 25 20:28:43 2007: Download : page 2
Wed Apr 25 20:28:45 2007: Program exit reached.
Wed Apr 25 20:28:45 2007: execUserFlashExit
Wed Apr 25 20:28:45 2007: ------------------------------- The Remap is done -----------------------------------------
Wed Apr 25 20:28:45 2007: Loaded macro file: C:\Program Files\IAR Systems\Embedded Workbench 4.0 Evaluation\ARM\config\flashloader\Atmel\FlashAT91SAM7Sxx.mac
Wed Apr 25 20:28:45 2007: -------------------------------Set CPSR ----------------------------------
Wed Apr 25 20:28:45 2007: CPSR 000000D3
Wed Apr 25 20:28:45 2007: ---------------------------------------- PLL Enable
Wed Apr 25 20:28:45 2007: ------------------------------- The Remap is NOT -----------------------------------------
Wed Apr 25 20:28:45 2007: ---------------------------------------- Chip ID 0x27090540
Wed Apr 25 20:28:45 2007: ---------------------------------------- Extention 0x00000000
Wed Apr 25 20:28:45 2007: ---------------------------------------- Flash Version 0x00000110
Wed Apr 25 20:28:46 2007: 546 bytes downloaded into FLASH and verified (0.04 Kbytes/sec)
Wed Apr 25 20:28:46 2007: Warning:
Verify error at address 0x00000110, target byte: 0x01, byte in file: 0x00
Wed Apr 25 20:28:46 2007: Warning:
Verify error at address 0x00000111, target byte: 0xBC, byte in file: 0xB5
Wed Apr 25 20:28:46 2007: Warning:
Verify error at address 0x00000112, target byte: 0x00, byte in file: 0x40
Wed Apr 25 20:28:46 2007: Warning:
Verify error at address 0x00000113, target byte: 0x47, byte in file: 0x1E
Wed Apr 25 20:28:46 2007: Warning:
Verify error at address 0x00000115, target byte: 0xB5, byte in file: 0x28
Wed Apr 25 20:28:46 2007: Warning:
Verify error at address 0x00000116, target byte: 0x9B, byte in file: 0xFC
Wed Apr 25 20:28:46 2007: Warning:
Verify error at address 0x00000117, target byte: 0x21, byte in file: 0xD1
Wed Apr 25 20:28:46 2007: Warning:


и так далее...... не совпадают записанные данные
что может быть?

Да простит меня господин модератор (який вже не гуморі)

Блин, но я не понимаю зачем губить столько времени шаманя с аппаратной отладкой, если все решается одним шнурком и одним окном терминала?

Все эти игрушки хороши, когда надо изучать работу нового камня. А в практической работе все решается моделированием в голове и трассировкой проги.
В 10% случаев проблемы от непонимания (кривизны) железа. В 90% от кривизны алгоритма.

Так под терминал надож писать кучу лишних отладочных команд, тормозить ими алгоритм, занимать какой либо порт, а потом еще в том же терминале фильтровать и анализировать полученый лог.
Т.е надо совершать кучу неоправданных и неэффективных действий.
Пока вы пишите assert-ы или debuf_printf-ы , с JTAG 10-ть раз можно прогнать тоже место по шагам и вычистить все ошибки просто на автомате, не прилагая никаких мозговых усилий. Т.е производительность труда вырастает многократно. Первое, потому, что писать можно не сильно думая об ошибках, а второе, потому, что очищать от ошибок тоже можно не сильно напрягаясь.
И код будет чист от кучи макросов зашумляющих исходники.

Несколько офтопично, но все же.
Добрая половина обсуждений в АРМах - проблемы с Вигглером, МТ-линком, Хамелеоном итд.итп.

Вот я и не пойму. Нафига столько убиваться с инструментами?
Кстати по той же причине пользуюсь gcc. Никаких проблем с инсталяциями, лекарствами, лицензиями итп. Ну да , требуется больше умения, зато любой комп рабочее место. Зачастую прямо с флэшки. Развернул за 10 минут и в бой. Время -деньги.
Аналогично и с отладчиками - на АРМ нужно одно, на АВР другое, на Ренесас или МСП - третье.
И потом начинается - без ЖТАГА - не могу (точно как Дельфисты не могут без складов компонентов в Инете).
Писать надо не расслаблясь - думая о том, что и как пишешь Тогда приобретается полезная привычка писать рабочий код с первого (на крайняк второго) прохода.
Опять таки подчеркну. Основные проблемы при отладке это не пропущенная запятая, а неправильный алгоритм или непродуманнная архитектура. И при этом нет смысла подглядывать в ядро. Просто по внешним признакам видно, что не пашет - графика не работает, клава не сканится, сеть не пингуется.
А чаще всего ошибки это вообще такая погань, которая вылазит не в лаборатории, а на эксплуатации, когда какую-то комбинацию внешних воздействий не просто не предусмотрел. И опять это отладочная ботва ничем не поможет. В лаборатории ее не смоделируешь. Т.е. опять приходится активизировать серое вещество.



P.S. Байка в тему.
Лет 15 назад я работал в сервисе. Починяли все - от телевизоров до профессиональной видеотехники.
По случаю хронической невыплаты зарплат пришел к нам мужичек из какого-то НИИ.
Мы громоздили на столы телетесты, осциллы с выделением строки, скупали всякие припонтованые приспособы. А у Саши было два инструмента - отвертка с двумя жалами (простое и крест) и тестер(хороший). Успеевал он сделать вдвое больше лучшего из нас.
Вот тогда я понял к чему в работе надо стремится.

P.P.S. Извиняюсьза некоторую сумбурность - и время позднее и "Львовское Премиум Лагер" напиток не детский

Смущает строчка Download1 : AT91SAM7Sxx at: 0x100000, а дальше идут ошибки на адресах 0x00000110. Посмотрите, в какие адреса слинкована программа. И не висит ли у вас неправильный уровень на ноге, отвечающей за восстановление самбы.

Хм... посмотрел, что пишет у меня - то же самое, Download1 : AT91SAM7Sx at: 0x100000. Может самба восстанавливается?
И какой кристалл отлаживаете? AT91SAM7Sxx.d79 для 128 и 256, AT91SAM7Sx.d79 для 32 и 64

Место надо найти сначала . А ошибки и без прогона глазом в исходнике видно, если место известно хоть с каой-то точностью. Самое главное в локализации общесистемных и реалтаймовых ошибок внутрисхемный отладчик крайне мало полезен.

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

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

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

Я сказал ошибка видна "сразу" - это, конечно, условно. Нужны итерации, но довольно тупые, объясняю на примерах:
1. Программа не дошла до места. Здесь просто тупо ставим точки останова перед тем местом и с каждой итерацией точки удаляем и находим ту процедуру где застревает. Итерации заключается просто в переустановке точки останова и рестарте, все очень быстро и механически.
2. Программа в аборте. Здесь просто смотрим LR регистр, и все остальные регистры. Смотрим че там по адресу из LR находится. По MAP файлу узнаем имя процедуры и разбираемся, но конкретно уже без домыслов.
3. Программа гуляет черт знает где и не живая. Здесь делаем останов и смотрим че стало с RAM-ом. Часто уже там сплош мусор. Тогда находим с какого места он начал расти и ставим точку останова по записи в тот адрес. На следующем рестарте мы узнаем кто туда пишет мусор.

Ни и т.д. , можно продолжать перечислять сценарии где простой терминал ничем не поможет.

Насчет макросов.
Я не против всех макросов. А только против макросов условной компиляции и в частности отладочных.
Дело в том, что SlickEdit плохо ориентируется при поиске объявлений и реализаций тех или иных объектов если они были скрыты или переименованы макросами. Также ненадежно работает рефактроинг. Когда в тексте встречаются макросы условной компиляции приходится перенапрягать память чтобы вспомнить какие блоки активны.
Изучать чужие тексты переполненные макросами просто кошмар.

И еще, 90% текстов в серьезных прогах - чужие. Еще 9% это библиотеки компилятора к которым вообще нет исходников. Так, что реально "анализировать" алгоритмы не приходится, они либо верны, либо мы меняем компилятор и не связываемся с сомнительным софтом.
Ошибки с которыми в основном приходится бороться это ошибки сбоев периферии и вызванные багами кристаллов, ошибки неинициализированных указателей, ошибки парсинга компиляторов, ошибки или недопонимание ретаргетинга компиляторов на целевую платформу, т.е. чисто технические непредсказуемые и слабо зависящие от программиста ошибки, терминал здесь явно неэффективен.

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

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

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

Аналогично, только LR и все прочее мне выдает отладочная консолька в загрузчике. Причем выдает всегда и везде а не только когда я (а не кто-то на объекте) работаю в комфортных условиях с подключеным отладчиком. Ну и на ARM платформе я не вылетал ни разу еще , если не считать специально при проверке работоспособности.

Полезная штука - один раз воспользовался при освоении, правда до того, как появился первый JTAG нарывался раза три и обошелся, хотя времени потратил явно больше. Сейчас как-то не наступаю уже
на такое. Кроме того при использовании системы "гуляет" уже не программа вообще а какая-либо конкретная задача. Ядро живет и можно глянуть кто там куда забрел-завис. Ну а накрывание системы это уже скорее всего к п.2 приведет.

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

Это примиряет

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

У меня тоже не грузилось во FLASH на AT91SAM7S256
Мне на этом форуме подсказали решение Options->Debugger->Download->Edit и должны получить след. строчку ,,,0x00100000,(default),
т.е. Reallocate Base Address установить крыж и значение 0x00100000

Несмотря на то, что все ругают Wiggler, у меня он работает стабильно, через RDI с последней версией H-JTAG в IAR и в KEIL.

Сейчас купил MT-LINK и тоже доволен.

пока только 2 дня изучаю ARM , мучаю 91SAM7S64. есть IAR+Wigler, согласен что отладка это дело любителя, на AVR никогда таким не пользовался, а все изза того что был нормальный low-cost программатор и avreal или ponyprog компилил шил и сразу смотрел результат. А здесь непонятно както, есть SAM-BA но все время тыкать джампер и кабель USB дергать так далеко не уедеш по моему, вот и занялся вотросом программирования через J-TAG. Кто как выходит из этого положения??? H-JTAG пробывал, пока не понятно, чтото онругается. Пока единственный вариант это заливка во флеш из IAR. но как я понял для нормальной работы необходимы нормально-сконфигурированные .xcl и .mac файлы проекта... пока получилось токлько залить примерчик Atmel со светодиодом, а вот свой проект со светодиодом уже не пошел, т.к. нет нормального сконфирурированного проекта. Еще попутный вопрос, вроде облазил весь форум,ничего не нашел, по поводу конфигурирования .xcl и .mac, есть ли линки по этому поводу???

А зачем форум, если смотреть нужно в документации на линкер Help->Linker Tools.... Там все более, чем подробно.
По *.mac - аналогично, но думаю, что менять пока Вам вообще нечего относительно имеющегося по умолчанию.