Добрый день!

Наши электронщики спаяли плату, а мне ее кодить. До этого с контролерами дела почти не имел.

Работаю из под Linux, arm-elf-gcc собрал без проблем - компилирует. Проблема залить и ковырять по JTAG (Wiggler). Пробовал OpenOCD и еще один jtag_gdbserver - без успешно. OpenOCD после заливки бинарника показывает что состояние помяти не изменилось, хотя если включить TST - показывает появление SAM_BA (?). jtag_gdbserver заливает бинарник, но работает как то странно...

Направьте на путь истиный. Может нужны другие версии gcc или gdb? Какие 100% рабочие?

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

Сам только хочу заняться практикой проэктирования на ARM
Насколько я знаю ARM AT91S7 имеют функцию заливки через USB через прогу SAMBA ее можно скачать http://www.at91.com там же можно еще всего найти, только вроде просле заливки через USB нужно провести какие то несложные операци с портами чтоб прошивка записалась во flash (подробнее в Help от SAMBA

использую openocd - шьет флеш без вопросов. один раз из интереса проверил их gdbserver - сработал тоже четко. openocd брал из svn, gcc-4.1.1, latest binutils.

Насколько мне помнится, SAM-BA только под Windows, а здесь Linux. Да и работу через SAM-BA сложно назвать полноценной отладкой (брек-пойнты там, пошаговое выполнение и т.д.).

GNU тулчейн для ARM: все скучковалось, включая USB JTAG!
http://www.caxapa.ru/echo/arm.html?id=66685
http://electronix.ru/forum/index.php?showtopic=20310

Во флэш или во RAM? Можно кратенький HOW-TO? Потому что я уж думаю может в карте какие баги? И если возможно разъясните по ERASE и TST сигналам...

Может дело в gdb? Откуда брали?
Я собрал сам:
GNU gdb 6.4.50.20060406-patched
This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-elf".

Но он с OpenOCD не очень дружит - по info registers роняет openocd и вообще..

И еще пробовал из codesourcery:
GNU gdb 6.4.50.20060226-cvs
This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-none-eabi".
А этот с регистраим работает - но после load память чистая

И вот еще, если цепляюсь к openocd через 4444 порт (telnet) - и пробую что нибудь поменять mwb и когда смотрю mdb - без изменений.

Ну так как samba меня не устраивает по многим причинам - я написал свой загрузчик, его я один раз шью во флеш - дальше он по usb или uart может заливать основную прогу. краткий howto:

- ставим, желательно стабильный, codegen (gcc/binutils/newlib)
- выкачиваем последний snap openocd и ставим
- создаем скрипт ocd.cfg, что-то типа :

telnet_port 4444
gdb_port 3333
interface parport
parport_cable bb2 # у меня патченый openocd под altera bb2 - указываете свой кабель
jtag_speed 0
reset_config srst_only
jtag_device 4 0x1 0xf 0x3f0f0f0f
daemon_startup reset
target arm7tdmi little reset_init 0 arm7tdmi_r4
flash bank at91sam7 0 0 0 0 0
run_and_halt_time 0 30
working_area 0 0x40000000 0x40000 nobackup

- запускаем openocd -f ocd.cfg, телнетимся к нему и проверяем как дышит плата командами openocd - можно распечатать состояния регистров, попытаться изменить значения в памяти и проверить что они меняются и т.д.
- собираем проект с -g и правильным linker скриптом, т.е. помня как прога будет работать - из RAM или ROM
- заливаем все это дело, опять же не забывая что после ресета по 0 адресу у нас флеш и естественно запись программы в этот сегмент по RAM принципу толку иметь не будет
- запускаем

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




codegen я собираю сам, gdb беру из стандартной поставки слакваря. Я думаю Ваша проблема в том что Вы не разобрались с картой памяти процессора - после reset'а по 0 адресу мапится флешка а не SRAM, поэтому после "заливки" программы память у Вас так и остается чистой.

Действительно. Если писать/читать с адреса 0x20000 то все меняется. Спасибо!
Тогда такой вопрос - если я заливаю прогу по flash write 0 test.bin 0x0 по какому адресу ее искать? вроде как по 0x100000 - но там чисто. По 0x0 тоже...

Вообще ерунда какая-то!

меняю - mwb 0x200000 0x12
выключаю/включаю питание и проверяю - mdb 0x200000, все на месте = 0x12. Тут ведь RAM?

Причем у меня на этом месте дальше судя по всему залита программа - как я ее туда залил и не понимаю уже. flash erase 0 0 15 похоже вообще ничего не делает

Если чисто - то значит прошивка не прошла - openocd обычно при этом пишет что-то про lock bit'ы


А кто сказал что инфа должна сразу пропасть, это от токов утечки зависит - SRAM для данного кристалла может хранить инфу до 15 мин.
Насчет flash erase, см. в сторону lock bit'ов - у меня уже стойкая уверенность в том что дока на чип не читалась вовсе, максимум 1 страница так Вы долго будете наступать на свои же хвосты и грабли ...

Ну это вы зря!
Дока прочитана, про lock bit известно - даже снимал их на всякий случай, хотя flash info 0 говорит, что они сняты.

При прошивке openocd -d 1 проскакивает такое:
Debug: bitbang.c:198 bitbang_execute_queue(): end_state: 5
Debug: bitbang.c:237 bitbang_execute_queue(): scan end in -1
Debug: jtag.c:957 jtag_build_buffer(): fields[0].out_value: 00
Debug: jtag.c:957 jtag_build_buffer(): fields[1].out_value: 0000f1a7
Debug: bitbang.c:215 bitbang_execute_queue(): runtest 0 cycles, end in -1

Это нормально?

Взял еще одну такую плату - там был не подпаян BT чип (BGB204) там флэшка заливается! Так что или этот чип садит питание (не хватает для флэша) или просто atmel глючный.

Спасибо за помощь, теперь есть хоть с чем разбираться

bitbang - это кабель на ftdi, у меня bb2 на lpt, посему ничего по openocd логу сказать не могу. как говориться - если что-то долго вертеть в руках - можно починить