AT91SAM7 (S64) + GCC + GDB + JTAG, У кого есть опыт, помогите разобраться Опции

[Strijar]

Добрый день!

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

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

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

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

[Harbour]

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

[Strijar]

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

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

[Harbour]

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

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

Ну так как 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 сигналы по причине неюзанья каличной самбы я не использую - т.е. они висят в воздухе

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

Может дело в 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 - без изменений.

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