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(), и станет ясно, где происходит глюк.

[PrSt]

Стоп! Причем здесь корректная работа памяти? С ней, скорее всего, все в порядке.
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;
}

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

[PrSt]

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

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

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

[aaarrr]

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

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

кто-нибудь что-нибудь может дельное посоветовать?

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

[PrSt]

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

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

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

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

[aaarrr]

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

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

и что за LR_abt?

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

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

[PrSt]

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

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

Прикрепленные файлы

 ROMBOOT.rar ( 24.49 килобайт ) Кол-во скачиваний: 107

 

[aaarrr]

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

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

оброботчик есть в файле cstartup.S

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

[PrSt]

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

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

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

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

[aaarrr]

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

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

Код

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);

    __asm
    {
        mov    i, R14
    }
    printf("\n --------- Address --------->: %X \n\r", (i - 0x08));

    while (1);
}