AT91SAM7X256. Загадка для шпиона., Непонятное поведение после программного сброса Опции

[Aurochs]

Имеется такой вот код (для GCC):

CODE

void Stop ( void )
{
.................................
.................................
AT91F_RSTSoftReset( AT91C_BASE_RSTC,
AT91C_RSTC_PROCRST );
// наивно ждем сброса
// но в нижеследующей команде возникает исключение "Undefined instruction"
asm volatile ( "B ." );
}

void undef_handler ( void )
__attribute__ (( interrupt( "UNDEF" ), naked ));
void undef_handler ( void )
{
.................................
.................................
Stop();
}


void pabort_handler ( void )
__attribute__ (( interrupt( "ABORT" ), naked ));
void pabort_handler ( void )
{
.................................
.................................
Stop();
}


void dabort_handler ( void )
__attribute__ (( interrupt( "ABORT" ), naked ));
void dabort_handler ( void )
{
.................................
.................................
Stop();
}

Когда в процессоре возникает какое-то из вышеупомянутых исключений (какое точно - неизвестно), то попадаем в функцию Stop и пытаемся сделать сброс. Да не тут то было - почему-то возникает безконечная последовательность исключений типа "Undefined instruction" на ассемблеровской команде ожидания, а сброса так и нет.
Уже дважды такой перл зафиксировал в боевой прошивке. Попытки воспроизвести подобное поведение в "лабораторных условиях" ни к чему не привели - все работает без фокусов. С горя добавил еще 2 ассемблеровских команды бесконечного цикла (типа после программирования контроллера сброса процессор вываливается в исключение в момент предвыборки, т.к. получается, что вслед за командой B . идут уже данные).
Вот теперь и мучаюсь - спасет ли это отца русской демократии?

Сообщение отредактировал Aurochs - Dec 26 2009, 22:52