Николай Анатольевич

Хм... А покажи конфиг для openocd. Где брал его?

Отладочная информация по-любому не причем. В мап-файл посмотри, правильно он память распределил, или нет. Варианта остается два: конфиг openocd и хардварная проблема, типа JTAGSEL неправильно установил, или банально не контачит. Не работает :laughing:

А причем тут makefile. Если собирается, значит должно что-то работать. Посмотри дизассемблер. Может быть с расположением что-то попутал (в смысле линкуешь для flash, а запускаешь в ram)?

Внимательней читайте. У меня стоит опция -nostdlib. А openocd запущен? Находит устройство? Порт правильный слушает?

Обычно компилятор и newlib собраны с опцией multilib и interwork, это для того, чтобы можно было компилить в ARM, THUMB и ARM+THUMB одновременно. По этому есть несколько версий libc и libgcc, которые нужно выбрать в зависимости от флагов компиляции. Это можно автоматизировать (как сделал я). Кусок makefile'а: LIBGCC = `$(CC) $(CFLAGS) -print-libgcc-file-name` LIBDIR = /opt/armgcc/arm-elf/lib/`$(CC) $(CFLAGS) -print-multi-directory` LIBC = $(LIBDIR)/libc.a где $(CC) = arm-elf-gcc и подставляем линкеру $(LIBGCC) $(LIBC) Почему так? Я использую опцию -nostdlib. А кто выводит это сообщение? OpenOCD, GDB или Eclipse?

Покажите ваш паспорт makefile. А вообще, я не рекомендую использовать printf/sprintf из стандартной библиотеки. Очень уж он там громоздкий. Напишите свой или возьмите готовый. В сети много вариантов валяется.

ОК. Тогда давайте по порядку. Что делаете, что работает, что не работает? Может ошибки какие выводит?

Да, совершено верно. Сам столкивался не раз на потребляющих цепях.

Зачем столько бусин? Может просто отделить LC-фильтром цифровую часть от общего питания? Ну в крайнем случае оставить бусины на AVCC и одну на AGND. Конечно, если питание по длинным проводам, то на каждой плате придется ставить разделительный фильтр.

Хоть вопрос и не мне (к тому-же и оффтоп), но тоже хочется ответить. Мы в нашей организации платы разводим в KiCAD'е, который GPL, и соответственно денег не стоит. Когда есть свободное время, посильно участвуем в разработке - это наш вклад. Микрософт офис тоже не используем - для него давно есть замена в лице OpenOffice, который давно уже в большинстве случаем обогнал MSOffice и по функционалу и по удобству. А вместо Windows используем Linux, что тоже дешевле ;) Тестировал ли кто нибудь (желательно непредвзято) GCC vs RVCT на более-менее комплексных тестах? Интересно узнать результат.

В принципе ничего сложного нет. Компилируем binutils, gcc (с опцией --without-headers, нужен для того, чтобы им скомпилить newlib), newlib и снова gcc (уже полностью, с поддержкой newlib). При этом ставим необходимые опции для целевой платформы (для ARM это --target=arm-elf --enable-interwork --enable-multilib). Всё, можно компилировать программки. Чтобы компилятор не использовал инициализацию от newlib (например crt0), в опциях линкера ставим -nostartfiles -nostdlib и пишем свой инициализирующий код. Чтобы при этом использовать функции из newlib, добавляем с список объектных файлов libc.a. Вот как сделал я (кусок Makefile'a): CFLAGS = $(FLAGS) -mcpu=$(MCU) -mtune=$(MCU) -march=$(CPUARCH) $(DEBUG) $(THUMB_IW) \ -Wall -std=gnu99 -O$(OPTLEVEL) $(INCLUDES) LDFLAGS = -nostartfiles -nostdlib -T lpc2148_rom.ld LIBGCC = `$(CC) $(CFLAGS) $(THUMB) -print-libgcc-file-name` LIBDIR = /opt/armgcc/arm-elf/lib/`$(CC) $(CFLAGS) -print-multi-directory` LIBC = $(LIBDIR)/libc.a ... $(ELF) : $(OBJS) $(OBJS32) $(OBJSAS) @echo $(MSG_LINKING) $@ $(LD) -Map $(MAP) --cref $(LDFLAGS) -o $@ $(OBJALL) $(LIBGCC) $(LIBC) @echo $(MSG_SIZE) $(OBJSIZE) $@ $(OBJS) : %.o : %.c @echo $(MSG_COMPILING) $< $(CC) -c $(CFLAGS) $(THUMB) -o $@ $< ... а вообще, в интернете масса примеров и готовых тулчейнов, в которых можно посмотреть, как это делается. Эклипс настраивается, как и на системный gcc. Все-таки gcc - он и в африке gcc. Использую и отладчик (OpenOCD) и симулятор (skyeye), правда для nxp21xx переферию он не эмулирует, по этому применение довольно ограниченное. Кстати, Zylin Embedded CDT не использовал. Надо попробовать. А вообще, говорят, что gcc во многих случаях делает более быстрый и компактный код, чем keil или iar. Я сам не проверял, но вот люди, типа проверили: ftp://www.raisonance.com/STR7/Benchmark/A...C-Benchmark.pdf (обсуждалось когда-то на этом форуме).

Я использую Eclipse+GCC+OOCD+самосборное подобие Wiggler'a. Проблем нет (кроме одного всем известного глюка с вызовом функций из обработчика прерываний в ARM-моде). Всё собирал вручную. Забыл сказать, что работаю в линуксе. KEIL и IAR не пробовал (точнее пробовал, но как-то не пошло. непривычно). Для AVR и MSP тоже использовал Эклипс+GCC, а для TMS320 - Эклипс+техасовский компилятор, который был жестоко выдран (собственно там ничего жестокого нет :) ) из из CCS, и который запускался через wine (кстати, прекрасно работал). Единственный минус - не нашел, как сделать отладку TMS-а из линукса. Для Linux/x86 естественно тоже использую Эклипс+GCC. Его-же использую и для написания скриптов на Ruby/Python/Perl (иногда нужно). Таким вот образом обеспечил себе обнообразие среды разработки.

Поставь триггер Шмитта.

Еще вопрос: в /S03 после сброса UART доступен? Или там GPIO и нужно каким-то образом активировать UART? И вообще, какие функции на пинах?

Так они же много потребляют...