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, поэтому после "заливки" программы память у Вас так и остается чистой.

[Strijar]

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

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

[Harbour]

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

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

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

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

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

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

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

[Strijar]

Насчет 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

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