Здравия желаю!
уже несколько дней мучительная попытка запустить камешек 9200 и плату к нему

Люди вот такая проблемма, помоги решить ее плз

собрали макетную платку ( http://projects.org.ua/project/arm/9200/ )
пытаемся загрузить в нее romboot.bin ( следуем как написано в статье - http://heavy-online.ru/arm-linux/ )

и сталкиваемся с мистическим поведением контроллера, а именно:

после того, как прицепились гипертерминалом - отсылаем по xmodem файлик - romboot.bin
он отсылается
и появляется сообщение
CCCCCCCCCCCCCCCCC
AT91F_LowLevelInit(): Debug channel initialized
press any key to enter bootloader

ATMEL LOADER VER 1.01 May 3 2006 15:21:06
*----------------------------------------*
*----------------------------------------*
1: Download Dataflash [addr]
2: Read Dataflash [addr]
3: Start U-BOOT
4: Clear bootloader section in Dataflash
*----------------------------------------*
Enter:

тут вроде все верно

говорим
Enter: 1 c0000000
Download Dataflash [0xc0000000]
CCCCCCCCCCCCCCCCCC

отсылаем файл (как требует статья)

и здесь начинается самое интересное:

Modification of Arm Vector 6 :34340015

Write 10240 bytes in DataFlash [0xc0000000]
-F- Data Abort detected

тоесть, казалось бы, по какой-то неведомой причине не пишется в DataFlash

Так, берем осциллограф и идем далее...

проделываем тоже самое параллельно наблюдая осцилом за SPCK, MOSI и NPCS0

и к нашему удивлению - на SPCK, MOSI и NPCS0 нет изменения логического уровня и данных вообще!!!!!

аппартно все верно, все прозвонено тестером - с точки зрения железа все корректно, проверяли несколько раз!

это настараживает и мы идем читать исходники от romboot-evm9200 (SPI 1:1 + схема почти такая же)
только микруха у нас - AT45DB642
в исходнике разобрались - вроде все должно инициализироваться и SPI обязан работать...!

фух
однако SPI - НЕ РАБОТАЕТ...

Люди - у кого есть какие мысли и идеи на этот счет?
потому что реально уже отпало понимание происходяших глюков....
HELP PLZ !!!

На висящем процессоре SPI работать и не должен - обратите внимание на строку -F- Data Abort detected.
Нужно разобраться, почему возникает Data Abort.

Так данные то реально не поступают на пины SPI вообще, как будто не проинициализирован вообще SPI
тоесть состояние пинов не изменно...

а что значит - "На висящем процессоре" ???
по терминалу то он как-то отвечает 8))))
Вы думанете что процессор по какойто причине завис?
или я неверно Вас понял?

Я думаю, что случился Data Abort. А судя по тексту init.cpp -

- процессор должен намертво встать на строке while (1).

Попробуйте этот загрузчик.
Писать по адресу 0x00000000, т. е. 1 00000000
Правда он под 16 МГц.

верно, вот когда он встанет на while(1) вопроса нет - но ведь он оказывается здесь и заходит в процедуру _DataAbort() после какой-то проблемы....
и видимо по той причине что где-то какие-то проблемы, а именно как я уже писал реально"физически" не работает SPI как перифирия вообще....
по этой причине он и попадает в эту процедуру... и это логично...
но почему нет данных на SPI? ведь и инициализация проведена была корректно (я так подозреваю что всетаки корректно, если верить коду...) и потом попытка отослать данные по SPI, следовательно на пинах должен был осциллографом увидеть клоки и данные, а там девственная тишина как в пещере...




ок, спасибо большое - попробую
(кстати - а исходник можно тоже посмотреть - что хоть шить буду?)

перепаять кварц с 18.432 на 16.0 не проблема, тем более если верить даташиту, то можно и не перепаивать - должен стартонуть...

Вы путаете причину и следствие. "Физически" SPI работает, просто до его применения дело не доходит из-за вылета в Data Abort. Причиной этому может служить некорректное обращение к памяти - неверный адрес или ошибка выравнивания.

Сообщение терминала:
Write 10240 bytes in DataFlash [0xc0000000]
-F- Data Abort detected

Код из main.cpp:


Возможно, ошибка возникает при выполнении CRC32. Соответствующую диагностику добавить проблемы не составит.

Исходники - без проблем.

Переделанный атмеловский загрузчик.

Пытаюсь скачать этот файл. Все нормально. Только вот при открытии проекта IAR пишет not a project file. Не хочется все настраивать по-новой. Не подскажете в чем проблемма? IAR 4.4.

Проект не мой. Попробую разобраться.

загрузил по xmodem - не работает (полная тишина)
перепаял кварц на 16.0, загрузил по xmodem - тоже полная тишина
тоесть, "C" прекратили бежать вообще

Вы по ходу правы, если верить огрызку кода... этого я не заметил честно говоря... так...веселье наступает...
тогда, вопросиком плавно переходим к новому вопросику связанным с корректной работой схемы...
а именно с работой с памятью...
вопрос по памяти:
используется SAMSUNG K4S561632E-IC75 + абсолютно на всех цепях от МК до RAM стоят резюки на 33 Ом... - могут ли они както влиять?
или может проще Вам показать схему, на эту плату, что бы посмотреть правильно ли мы память вообще прицепили к МК?

Дайте схему.

P.S. Можете помочь ?
http://electronix.ru/forum/index.php?showtopic=25653

Щяс напарник схему положит и ответитит по этой ссылочке ( он в гиперлинксе моделирует )

Насчет модели - проверял. При наличии резисторов 27-36 Ом все выбросы укладываются в допустимые рамки.

Схема в ПКАД2004 прилагается.

Насчет модели - у меня двухслойка. Резисторы 68 Ом.

Схему посмотрю.

Может у вас генератор не стартует? Попробуйте держать кнопку ресет пару секунд при включении платы.

Стоп! Причем здесь корректная работа памяти? С ней, скорее всего, все в порядке.
Data Abort возникает из-за некорректного обращения к памяти, а не по причине неисправности оной.
У AT91RM9200 есть MC Abort Status Register и MC Abort Address Register - выведите их значения printf'ом в DataAbort(), и станет ясно, где происходит глюк.

собрать из линукса и gcc - бинарик для прошивки получилось....
щяс пробую сделать проверку по Вашему совету...

я так понимаю Вы говорите про это?
The full 32-bit wide abort address is saved in the Abort Address Status Register (MC_AASR).
Parameters of the access are saved in the Abort Status Register (MC_ASR) and include:
• the size of the request (ABTSZ field)
• the type of the access, whether it is a data read or write or a code fetch (ABTTYP field)
• whether the access is due to accessing an undefined address (UNDADD bit) or a misaligned
address (MISADD bit)
• the source of the access leading to the last abort (MST0, MST1, MST2 and MST3 bits)
• whether or not an abort occurred for each master since the last read of the register
(SVMST0, SVMST1, SVMST2 and SVMST3 bits) except if it is traced in the MST bits.

вот что я сделал
//*----------------------------------------------------------------------------
//* \fn AT91F_DataAbort
//* \brief This function reports an Abort
//*----------------------------------------------------------------------------
void AT91F_DataAbort()
{
int i;
AT91F_DBGU_Printk("-F- Data Abort detected\n\r");
AT91F_DBGU_Printk("-F- LOOP... \n\r");
// Abort Address Status Register (MC_AASR)
// Abort Status Register (MC_ASR)
//int *iii;
//iii=(int *AT91C_MC_ASR);
printf("\n --------- ASR --------->: %X \n\r", *AT91C_MC_ASR);
//iii=(int *AT91C_MC_AASR);
printf("\n --------- AASR --------->: %X \n\r", *AT91C_MC_AASR);

while (1);
}


и вот что получилось
Enter: 1 c0000000
Download Dataflash [0xc0000000]
CCCCC
Modification of Arm Vector 6 :34340015

Write 10368 bytes in DataFlash [0xc0000000]

--------- ASR --------->: 10201

--------- AASR --------->: EA000438
-F- Data Abort detected
-F- LOOP...

судя по всему за аддрес EA000438 отвечает этот кусок кода из lib_AT91RM9200.h

//*----------------------------------------------------------------------------
//* \fn AT91F_AIC_SetExceptionVector
//* \brief Configure vector handler
//*----------------------------------------------------------------------------
__inline unsigned int AT91F_AIC_SetExceptionVector (
unsigned int *pVector, // \arg pointer to the AIC registers
void (*Handler) () ) // \arg Interrupt Handler
{
unsigned int oldVector = *pVector;

if ((unsigned int) Handler == (unsigned int) AT91C_AIC_BRANCH_OPCODE)
*pVector = (unsigned int) AT91C_AIC_BRANCH_OPCODE;
else
*pVector = (((((unsigned int) Handler) - ((unsigned int) pVector) - 0x8) >> 2) & 0x00FFFFFF) | 0xEA000000;

return oldVector;
}

что это может значит?

Кстати по ходу дела CRC32 не учавствует в этом всем...

дело в том что если верить даташиту страницы 17, то по этому аддресу доступ вообще - undefined
следовательно - ерунда какаято......
кто-нибудь что-нибудь может дельное посоветовать?
крыша едет...

Могу только сказать, что адрес больше похож на код команды (b +0x10e8).


Для начала следует выяснить, где именно вызывается исключение. Для этого нужно прочитать значение LR_abt, только до этого нужно выяснить, не портится ли он, что в C-программе более чем вероятно.

а как это выснить?
и что за LR_abt?

я так понимаю если схема правильная, то и romboot должен корректно вести себя и работать, ведь у людей же работает он....
вот тот romboot который я пытаюсь загрузить...
http://heavy-online.ru/arm-linux/files/pac...oot-evm9200.tgz

Посмотреть генерируемый компилятором код.


Link Register (R14) процессора для режима Abort.

Придется написать свой обработчик Data Abort, и написать на ассемблере, по крайней мере, частично.

в асмовсвом коде я непонял где искать...
на всякий случай, в прикрепленном файле асмовкский код этого файлика, если это не испугнет ~100К размер его...

оброботчик есть в файле cstartup.S
/*- Set up Abort Mode and set Abort Mode Stack*/
msr CPSR_c, #ARM_MODE_ABORT | I_BIT | F_BIT
mov r13, r0 /* Init stack Abort*/
sub r0, r0, #ABT_STACK_SIZE

JTAGом пошагово пробежаться по этому куску, и все станет ясно. А так гадать можно очень долго.

Посмотрел. В функции AT91F_DataAbort() LR должен остаться целым. Его можно попробовать вытащить через inline asm - это <адрес инструкции, вызвавшей Abort> + 0x08.


Это не обработчик, а установка стека режима Abort.

JTAG спаяем (WIGGLER) - а каким инструментарием "пошагово пробежаться по этому куску"?
я не делат этого никогда, не знаю как...
в инете конечно посмотрю... но может уже есть правельное отканаттое решение?

Если в GCC то на сайте Macraigor подробно написано как отлаживаться через вигглер.
www.macraigor.com/gnu_faq.htm
Я пишу в RVDS 2.2 и отлаживаюсь встроенным отладчиком через H-JTAG.

Вы были правы полностью: - вспоминается ваш пост:
Стоп! Причем здесь корректная работа памяти? С ней, скорее всего, все в порядке.
Data Abort возникает из-за некорректного обращения к памяти, а не по причине неисправности оной.

с ней таки действительно все в порядке...
я это проверил, вставил кусок кода для проверки памяти с топика - http://electronix.ru/forum/index.php?showtopic=20153

Подскажите пожалуста а как "можно попробовать вытащить через inline asm" ?
и узнать "<адрес инструкции, вызвавшей Abort>" ?

Не знаю, как в GCC, нужно посмотреть документацию
Для ADS/RVDS это будет выглядеть так:

Должно быть что-то типа:


Только листинг надо потом проверить обязательно.

оказуется так просто?
вот что в итоге получается...

AT91F_LowLevelInit(): Debug channel initialized
AT91F_DataflashInit
AT91F_SpiInit
PIOA->PIO_ABSR - 0
PIOA->PIO_PSR - 3FFFFF80
PMC->PMC_PCSR - 2000
SPI->SPI_SR - 100F2
SPI->SPI_MR - E0019
dfcode - 0
press any key to enter bootloader

*----------------------------------------*
1: Download Dataflash [addr]
2: Read Dataflash [addr]
3: Start U-BOOT
4: Clear bootloader section in Dataflash
5: ...test...
*----------------------------------------*
Enter: 1 c0000000
Download Dataflash [0xc0000000]
CCCCC
Modification of Arm Vector 6 :34340017

Write 11392 bytes in DataFlash [0xc0000000]
write_dataflash
AT91F_DataflashSelect novalid
-F- Data Abort detected
-F- LOOP...

--------- ASR --------->: 10201

--------- AASR --------->: EA000490

--------- Address --------->: 11C8

тоесть - 11C8 если я верно понял - это адрес из пространства - Internal Memories на еще и диапазона 0х0..0х100000 (Boot Memory)
так а что это теперь может нам сообщить?

Теперь смотрите map-файл линкера - к какой процедуре относится этот адрес.

В асм-листинге все в порядке с R14? Еще не грех прочитать значение кода команды по полученному адресу.

если я все правильно вижу - такого файла нет (map-файл линкера)
root@server:romboot-evm9200_dmb# ll
итого 435
drwxr-xr-x 6 dmb dmb 1320 2007-01-12 17:35 ./
drwxr-sr-x 5 root staff 280 2007-01-11 09:47 ../
-rw-r--r-- 1 root root 732 2007-01-12 17:35 asm_isr.o
-rw-rw-rw- 1 dmb dmb 2058 2007-01-09 11:37 asm_isr.S
-rw-rw-rw- 1 dmb dmb 23776 2007-01-12 17:15 at45.cpp
-rw-r--r-- 1 root root 4792 2007-01-12 17:35 at45.o
-rw-rw-rw- 1 dmb dmb 3711 2007-01-09 16:09 com.cpp
-rw-rw-rw- 1 dmb dmb 3252 2007-01-09 11:37 com.h
-rw-r--r-- 1 root root 2488 2007-01-12 17:35 com.o
-rwxr-xr-x 1 dmb dmb 835 2007-01-09 17:34 compile*
-rw-r--r-- 1 root root 1208 2007-01-12 17:35 cstartup_ram.o
-rw-rw-rw- 1 dmb dmb 5272 2007-01-09 11:37 cstartup_ram.S
-rw-rw-rw- 1 dmb dmb 7556 2007-01-12 17:15 dataflash.cpp
-rw-rw-rw- 1 dmb dmb 7174 2007-01-12 16:06 dataflash.h
-rw-r--r-- 1 root root 3940 2007-01-12 17:35 dataflash.o
-rw-rw-rw- 1 dmb dmb 984 2007-01-09 16:09 div0.c
-rw-r--r-- 1 root root 648 2007-01-12 17:35 div0.o
-rw-rw-rw- 1 dmb dmb 348 2007-01-09 16:10 elf32-littlearm.lds
-rw-rw-rw- 1 dmb dmb 27065 2007-01-09 11:37 embedded_services.h
-rwxr-xr-x 1 dmb dmb 192 2007-01-09 11:37 env.sh*
drwxrwxrwx 2 root root 112 2007-01-11 10:35 exchange/
drwxr-xr-x 2 dmb dmb 144 2007-01-10 10:08 include/
-rwxrw-rw- 1 root root 8429 2007-01-12 17:35 init.cpp*
-rw-r--r-- 1 root root 2944 2007-01-12 17:35 init.o
-rw-r--r-- 1 root root 508 2007-01-12 17:35 jump.o
-rw-rw-rw- 1 dmb dmb 39 2007-01-09 11:37 jump.S
-rw-rw-rw- 1 dmb dmb 15700 2007-01-12 16:10 main.cpp
-rw-rw-rw- 1 dmb dmb 1352 2007-01-09 16:10 main.h
-rw-r--r-- 1 root root 6580 2007-01-12 17:35 main.o
lrwxrwxrwx 1 root root 13 2007-01-11 10:32 Makefile -> Makefile_last
-rw-rw-rw- 1 dmb dmb 1044 2007-01-12 12:42 Makefile_last
drwxr-xr-x 2 root root 1288 2007-01-11 10:30 old/
drwxr-xr-x 3 root root 1280 2007-01-11 10:32 old2/
-rw-r--r-- 1 root root 117345 2007-01-11 13:18 ROMBOOT.asm
-rwxr-xr-x 1 root root 11308 2007-01-12 17:35 romboot.bin*
-rwxrw-rw- 1 root root 10116 2007-01-09 11:37 romboot.bin.orig*
-rw-rw-rw- 1 root root 44010 2007-01-12 17:35 romboot.lss
-rwxr-xr-x 1 root root 18007 2007-01-12 17:35 romboot.out*
-rw-rw-rw- 1 dmb dmb 5276 2007-01-09 11:37 stdio.cpp
-rw-rw-rw- 1 dmb dmb 643 2007-01-09 11:37 stdio.h
-rw-r--r-- 1 root root 3776 2007-01-12 17:35 stdio.o
-rw-r--r-- 1 root root 900 2007-01-12 17:35 _udivsi3.o
-rw-rw-rw- 1 dmb dmb 2219 2004-07-04 11:49 _udivsi3.S
-rw-r--r-- 1 root root 892 2007-01-12 17:35 _umodsi3.o
-rw-rw-rw- 1 dmb dmb 2767 2004-07-04 11:49 _umodsi3.S

значение... посмотрите пожалуста(я не знаю что там искать) в приклепленном файле асмовый код...

Значит линкер нужно попросить - посмотрите документицию.


Посмотрел, могу сказать только, что LR не поврежден. Значение посмотрите тем же printf'ом: *(unsigned int*)i.

Благодарю Вас...
>"Значит линкер нужно попросить" - не совсем понятно, честно говоря что Вы имеете ввиду, а где его можно попросить?
кстати, elf32-littlearm.lds - это не линкер скрипт?

Кстати, раз проблема близка к проблеме с стеком... как можно проверить вообще стек?
как узнать что должно быть и что получаем...?
Видимо если - DataAbort - то \то очень вероятно что чтото или с памятью или с стеком...
Как выяснилось память SDRAM тут не причем...

Мне вообще не ясно что может быть за проблемма???
По следующей логике пытаюсь судить ---> Ведь, romboot этот стандартный(причем написан фирмой ATMEL если я правильно все понимаю) и у других людей этот загрузчик работает видимо корректно, почемуже не работает у нас?
Схема то отличается только подключением переферии - ETHRNET и т д


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

Вы что, с дуба все упали?ИМХО. Кто и где сказал загрузчику, что датафлеш сериальная? Загрузчик понимает, что флешка (обычная, параллельная) сидит по адресу 0xC0000000 И пытается ее писать. А ее нету. ну и облом соответственно. Соответственно и SPI недергается вообще.

Разберитесь в проблеме, для начала. Данный загрузчик вообще не умеет писать "обычную" флеш.

А вам кажется подозрительной фраза:

Modification of Arm Vector 6 :34340017

вообще-nо для AT45DB642 должно быть 0841a017 (см стр. 87 на at91rm9200 "Structure of arm vector 6")

Совершенно верно, но к проблеме отношения не имеет
Только не обязательно 0841a017, правильнее 0841a0xx.

Можно Вас попросить изложить свою мысль по этому поводу?
Хотелось бы понять что же все таки происходит и куда копать...
Вы довольно метко подмечаете особенности вопроса!

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

Попробую кратко изложить свои мысли по поводу Вашей проблемы.
Итак, исключение DataAbort возникает из-за обращения инструкции, находящейся по адресу 0x11C8, к несуществующей памяти по адресу 0xEA000490. Само значение адреса говорит о том, что базовый регистр, использующийся при обращении, был загружен неправильно, и в результате вместо адреса в нем оказался фрагмент кода (b +0x10e8).

Сейчас нужно установить, к какой именно части кода относится инструкция, расположенная по адресу 0x11C8. Это можно заставить сделать линкер, но у меня, к сожалению, нет сейчас под рукой документации.
Добавьте в обработчик AT91F_DataAbort() еще одну строку:


Возможно, это поможет обойтись без map-файла, но все же он крайне желателен.

собственно, вот что получил в терминале...
Enter: 1 c0000000
Download Dataflash [0xc0000000]
CCCCCCCC
Modification of Arm Vector 6 :bdf80017

Write 11392 bytes in DataFlash [0xc0000000]
write_dataflash - это я выводу для дебага пути
AT91F_DataflashSelect novalid - это я выводу для дебага пути
-F- Data Abort detected - это я выводу для дебага пути
-F- LOOP... - это я выводу для дебага пути
--------- ASR --------->: 10201
--------- AASR --------->: EA000494
--------- Address --------->: 11C8
--------- Opcode --------->: E59F002C

да кстати
вот тест
в int AT91F_DataflashInit (void) делаю маленькое изменение
// for (i = 0; i < CFG_MAX_DATAFLASH_BANKS; i++) {
for (i = 0; i < 1; i++) {

и вот что получаю
AT91F_LowLevelInit(): Debug channel initialized
AT91F_DataflashInit
AT91F_SpiInit
PIOA->PIO_ABSR - 0
PIOA->PIO_PSR - 3FFFFF80
PMC->PMC_PCSR - 2000
SPI->SPI_SR - 100F2
SPI->SPI_MR - E0019
dfcode - 3C
AT45DB642
press any key to enter bootloader
ATMEL LOADER VER 1.01 Jan 16 2007 09:56:44
*----------------------------------------*
AT91F_DataflashPrintInfo
DataFlash:AT45DB642
Nb pages: 008192
Page Size: 001056
Size=08650752 bytes
Logical address: 0xC0000000
AT91F_DataflashPrintInfo ERROR detect - 0
*----------------------------------------*
1: Download Dataflash [addr]
2: Read Dataflash [addr]
3: Start U-BOOT
4: Clear bootloader section in Dataflash
5: ...test...
*----------------------------------------*
Enter:

Enter: 1 c0000000
Download Dataflash [0xc0000000]

Modification of Arm Vector 6 :841a017

Write 11392 bytes in DataFlash [0xc0000000]
write_dataflash
AT91F_DataflashSelect
read_dataflash
AT91F_DataflashSelect
Hit a Key!CCCCCCCCCCCC
AT91F_LowLevelInit(): Debug channel initialized
AT91F_DataflashInit
AT91F_SpiInit
PIOA->PIO_ABSR - 0
PIOA->PIO_PSR - 3FFFFF80
PMC->PMC_PCSR - 2000
SPI->SPI_SR - 100F2
SPI->SPI_MR - E0019
dfcode - 3C
AT45DB642
PIOA->PIO_ABSR - 0
PIOA->PIO_PSR - 3FFFFF80
PMC->PMC_PCSR - 2000
SPI->SPI_SR - 100F2
SPI->SPI_MR - 70019
dfcode - 0
press any key to enter bootloader
Load U-BOOT from dataflash[c0008000] to SDRAM[20f00000]
read_dataflash
AT91F_DataflashSelect
Set PLLA to 180Mhz and Master clock to 45Mhz and start U-BOOT


и - УРА!!!!!!
зашилось
нада зхаметить чтло это случайно....!!!!!!!!!
с какойто промежуточной редакцией гдето в коде....

тоесть вот что я вижу

>CCCCCCCCCCCCCCCCC
>AT91F_LowLevelInit(): Debug channel initialized
>press any key to enter bootloader
>
>ATMEL LOADER VER 1.01 May 3 2006 15:21:06
>*----------------------------------------*
>*----------------------------------------*
>1: Download Dataflash [addr]
>2: Read Dataflash [addr]
>3: Start U-BOOT
>4: Clear bootloader section in Dataflash
>*----------------------------------------*
>Enter:
>
>тут вроде все верно
как раз тут и неверно... у Вас DataFlash вообще неопределяется romboot'ом, поэтому дальше идти рано... добейтесь что бы romboot увидел вашу флэшку. Должно быть что-то вроде этого:

ATMEL LOADER VER 1.01 May 3 2006 15:21:06
*----------------------------------------*
DataFlash:AT45DB321
Nb pages: 008192
Page Size: 000528
Size=04325376 bytes
Logical address: 0xC0000000
*----------------------------------------*
1: Download Dataflash [addr]
2: Read Dataflash [addr]
3: Start U-BOOT
4: Clear bootloader section in Dataflash
*----------------------------------------*
Enter:


упс!! не заметил пока печатал, что вы уже решили эту проблему

З.Ы.: да еще на AT45DB321 запись у romboot'а глючит

Стас, а ты не пробовал прицеплять к 9200 CrossWorks (он же CrossStudio)?. У меня щас версия 1.6 build 3, но только мы работаем с LPC21xx. Это IDE, основанная на gcc. Без make, собственная система сборки проекта. Субъективно ее отладчик мне понравился больше чем Insight. Интерфейс содран с MS VS 7. Она правда не совсем халявная, но есть методы лечения. В списке поддерживаемых процов есть 9200. Правда не знаю как обстоят дела с загрузчиком. У LPC с этим проще - флеша внутренняя и загрузчик cw ее писать может, через jtag прямо из среды. В числе поддерживаемых отладчиков есть вигглер.

Но ты в любом случае вигглер собери, хоть с cw, хоть с gdb+insight+openocd - несравненно удобнее иметь пошаговую отладку и просмотр всех регистров и переменных, чем просто консоль .

К сожалению, именно по твоему загрузчику тебе ничего посоветовать не могу, с 9200 сам не работал.

А мапу вывести - линкеру опцию -Map mapfile скормить. Там много интересного пишут.

Это хорошо. А с диагностикой я малость наврал - строку asm volatile("mov %0, r14" : "=r" (i) : ); нужно ставить перед первым printf'ом, иначе LR теряется.

Всем спасибо!
помогли! серьезно!
надо заметить - локализовал проблемму(!как мне кажется!)
завелась схема прошивкой после следующего
1 - скорость SPI инициализировани с снижением скорости в 32 раза
2 -
#define AT91C_PLLA_MCK назначили как 0x302
3 - сменил в
int AT91F_DataflashInit (void)
...
// for (i = 0; i < CFG_MAX_DATAFLASH_BANKS; i++) {
for (i = 0; i < 1; i++) {
....
этот пункт отметим как FFF так как это временное решение, сами понимаете...

дело втом, что на флешку все сигналы кроме MISO идут через буфер (если посмотреть на схему - то можно это увидить), и стояла HC244 но она оказалась медленной, там какаято беда с тормозами фронтов, именно - по этому снижение скорости SPI помоло...
сменил ее на AC244 как рукой сняло эту проблемму...
Видимо из-за этого все и было...хотя может и не только...
за исключением еще одной.... которая отмечена ранее FFF

порвая флэшка стоит на CS0, как положенно....
у нас в схеме вторая флэшка используется на CS1
а в этом лоадере используется CS0 и CS3
вопрос:
что мне сменить в программе что бы использовать не CS3 а CS1 ?
и еще такой вопрос - как сделать что бы размер памяти 2 флэшек был виден как единая память?
тоесть у нас стоит 8M+8M а хочется сумарно видеть все 16M. надеюсь передал верно мысль.
вообще такое реально?

Судя по всему CS0 и CS1 заработали если верить сообщению на терминале
Nb pages: 008192
Page Size: 001056
Size=08650752 bytes
Logical address: 0xC0000000
DataFlash:AT45DB642
Nb pages: 008192
Page Size: 001056
Size=08650752 bytes
Logical address: 0xD0000000
*----------------------------------------*
1: Download Dataflash [addr]
2: Read Dataflash [addr]
3: Start U-BOOT
4: Clear bootloader section in Dataflash
*----------------------------------------*
Enter:

а вот на счет 8M+8M вопрос все еще остался... просветите кто нибудь плз...

Также вопрос к СОМА, aaarrr и к другим опытным ребятам...
...плюс ко всему не работает U-Boot.
вот в этой статье(http://heavy-online.ru/arm-linux/) сказано
" Если все нормально - то после ресета - u-boot будет грузиться автоматически (если ничего не нажимать) "

ВОПРОС! - а если не нормально?

объясняю проблемку:
прошит - romboot.bin
его исход ник в вложении

если не нажимать интер то после вклоючения
AT91F_LowLevelInit(): Debug channel initialized
press any key to enter bootloader
Load U-BOOT from dataflash[c0008000] to SDRAM[20f00000]
Set PLLA to 180Mhz and Master clock to 45Mhz and start U-BOOT
и тут висит....

если с нажатием после включения
AT91F_LowLevelInit(): Debug channel initialized
press any key to enter bootloader

ATMEL LOADER VER 1.01 Jan 17 2007 09:45:22
*----------------------------------------*
DataFlash:AT45DB642
Nb pages: 008192
Page Size: 001056
Size=08650752 bytes
Logical address: 0xC0000000
DataFlash:AT45DB642
Nb pages: 008192
Page Size: 001056
Size=08650752 bytes
Logical address: 0xD0000000
*----------------------------------------*
1: Download Dataflash [addr]
2: Read Dataflash [addr]
3: Start U-BOOT
4: Clear bootloader section in Dataflash
*----------------------------------------*
Enter:

собрал U-Boot

запись U-Boot`a
*----------------------------------------*
Enter: 1 c0008000
Download Dataflash [0xc0008000]
CCCCCCCCCCCC
Modification of Arm Vector 6 :841a0bc

Write 95744 bytes in DataFlash [0xc0008000]
Hit a Key!aflash: OK

снимаю питание
при включении надеюсь увидеть U-Boot а вижу следующее
AT91F_LowLevelInit(): Debug channel initialized
press any key to enter bootloader
Load U-BOOT from dataflash[c0008000] to SDRAM[20f00000]
Set PLLA to 180Mhz and Master clock to 45Mhz and start U-BOOT

это означает что U-Boot мягко говоря - не стартанул вообще...
зотя если проверить пунктом 2 по адрессу 20008000, из romboot, то вижу что таки в flash находится бействительно U-Boot.bin

что за проблемма?
может в файле include/configs/RM9200.h: не верно чтото, в зависимости от моей схемы?