AT91RM9200 - мистика? SPI? или romboot.bin?, задачка не для слабонервных.... Опции

[PrSt]

Здравия желаю!
уже несколько дней мучительная попытка запустить камешек 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 !!!

[aaarrr]

в исходнике разобрались - вроде все должно инициализироваться и SPI обязан работать...!

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

[PrSt]

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

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

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

[aaarrr]

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

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

Код

void AT91F_DataAbort()
{
    AT91F_DBGU_Printk("-F- Data Abort detected\n\r");
    while (1);
}

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

[PrSt]

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

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

Код

void AT91F_DataAbort()
{
    AT91F_DBGU_Printk("-F- Data Abort detected\n\r");
    while (1);
}

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

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

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

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

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

[aaarrr]

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

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

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

Код из main.cpp:

Код

      printf("\n\rWrite %d bytes in DataFlash [0x%x]\n\r",SizeToDownload, DeviceAddress);
      crc1 = 0;
      pAT91->CRC32((const unsigned char *)AddressToDownload, SizeToDownload , &crc1);
      
      // write the dataflash
      write_dataflash (DeviceAddress, AddressToDownload, SizeToDownload);

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

[PrSt]

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

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

Код из main.cpp:

Код

      printf("\n\rWrite %d bytes in DataFlash [0x%x]\n\r",SizeToDownload, DeviceAddress);
      crc1 = 0;
      pAT91->CRC32((const unsigned char *)AddressToDownload, SizeToDownload , &crc1);
      
      // write the dataflash
      write_dataflash (DeviceAddress, AddressToDownload, SizeToDownload);

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

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

[aaarrr]

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

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