Ошибка компилятора? (ARM), data abort.. Опции

[overloaded]

есть функция и вызов. В неопределенном месте (после вызова функции) процессор стабильно вылетает в data abort.

Код

void do_crc_8(unsigned char byte, unsigned char *crc8)
{
unsigned char ctmp = (*crc8^byte);  
*crc8 = crc_table[ctmp];
}


void write_AVR()
{    
  unsigned char crc8;
....      
  crc8=0;  
  
  for(itmp=0; itmp < sizeof(struct FHW_outs); itmp++)  
  {    
      while(!(AT91C_BASE_US1->US_CSR &AT91C_US_TXRDY));
      AT91C_BASE_US1->US_THR=buf[itmp];
      
      do_crc_8(buf[itmp], &crc8);// <<<----------------------------------------------!!!!
  }  
...
}

После небольшой перемены проблема исчезла. В чем юмор я понять к сожалению не могу =)
Кстати, на IAR AVR эта-же функция в таком-же (первоначальном) виде работает нормально.
ИМХО бред какойто ) Что-то здесь не чисто =)

Код

unsigned char do_crc_8(unsigned char byte, unsigned char crc8)
{
unsigned char ctmp = (crc8^byte);  
return (crc_table[ctmp]);
}


и вызов:

      crc8 = do_crc_8(buf[itmp], crc8);

[aaarrr]

В неопределенном месте (после вызова функции) процессор стабильно вылетает в data abort.

Для начала нужно установить "неопределенное место", т.е. состояние регистров процессора после попадания в abort + дизасм того места, на которое будет указывать LR_abt.

Кстати, второй вариант программы гораздо лучше.

[overloaded]

Для начала нужно установить "неопределенное место", т.е. состояние регистров процессора после попадания в abort + дизасм того места, на которое будет указывать LR_abt.

Кстати, второй вариант программы гораздо лучше.

Пока буду так использовать, времени нет на это, нужно остальное доделывать.. После праздников уже поиграюсь.. В пощаговом режиме в аборт попасть не смог.. Возвращаемое через указатель значение нормальное. Думал, может у кого-то были похожие грабли.. А так может кому-то и пригодиться.. Кстати, оптимизация отключена..

[defunct]

Возможно проблема в выравнивании. Возможно в перетирании стека.

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

[sergeeff]

Размер buf[]? sizeof(struct FHW_outs) равен ли sizeof(buf)?

[overloaded]

Размер buf[]? sizeof(struct FHW_outs) равен ли sizeof(buf)?

Не равен, на 2 байта больше =)

volatile unsigned char buf[sizeof(struct FHW_outs)+1];

Код не полный, но в другом месте касаемо buf[] есть только копирование из и в структуру
при выключенных прерываниях через memcpy. Раземер естественно через тот-же
sizeof(struct FHW_outs). Еще думал на константную таблицу const unsigned char crc_table[256]
т.к. интересным моментом было и то, что вылетало в аборт только с индексом 255:

void do_crc_8(unsigned char byte, unsigned char *crc8)
{
*crc8 = crc_table[255];
}

Но оказалось что таблица не при чем...

[overloaded]

Хм.. Дописал немного кода, снова начало глючить там-же. Посмотрел куда указывает аборт - кто-то портит код в прерывании, вынесенном в __ramfunc. Если из озу убрать, то дата аборта нет.
Портит типа такого(всегда в примерно разных местах в пределах + - 10):

Код

Нормальный:
    ADC_buf3[ADC_buf7_count] = ADC_DATA_3;
  00000328  E59F10F8  LDR          R1, [PC, #+248]         ; [0x428] =ADC_buf7_count (0x201464)
  0000032C  E5911000  LDR          R1, [R1, #+0]
  00000330  E3A02004  MOV          R2, #0x4
  00000334  E59F3108  LDR          R3, [PC, #+264]         ; [0x444] =ADC_buf3 (0x201310)
  00000338  E0213192  MLA          R1, R2, R1, R3
  0000033C  E59F2104  LDR          R2, [PC, #+260]         ; [0x448] =ADC_CDR3 (0xFFFD803C)
  00000340  E5922000  LDR          R2, [R2, #+0]
  00000344  E5812000  STR          R2, [R1, #+0]

Порченный:
    ADC_buf3[ADC_buf7_count] = ADC_DATA_3;
  00201508  E59F10F8  LDR          R1, [PC, #+248]         ; [0x201608] =ADC_buf7_count (0x201464)
  0020150C  E5911000  LDR          R1, [R1, #+0]
  00201510  E3A02004  MOV          R2, #0x4
  00201514  E59F3108  LDR          R3, [PC, #+264]         ; [0x201624] =ADC_buf3 (0x201310)
!!! 00201518  FFFFFFFF  SWINV        0xFFFFFF            
  0020151C  E59F2104  LDR          R2, [PC, #+260]         ; [0x201628] =ADC_CDR3 (0xFFFD803C)
  00201520  E5922000  LDR          R2, [R2, #+0]
  00201524  E5812000  STR          R2, [R1, #+0]

Дело почти однозначно в этой ф-и(про которую выше говорил) т.к. когда ее комментирую все работает долго и без глюков. Думаю, что-то с расположением таблици.. Код в прерывании портится не непосредственно этой функцией.. Где-то дальше, не смог найти где.
Какие могут быть нюансы с таблицей?

const unsigned char crc_table[256] = {
0x00,0x5E,0xBC,0xE2,0x61,0x3F,0xDD,0x83 ...

Или если не таблица, куда снова копать?..

[aaarrr]

Дело почти однозначно в этой ф-и(про которую выше говорил) т.к. когда ее комментирую все работает долго и без глюков. Думаю, что-то с расположением таблици.. Код в прерывании портится не непосредственно этой функцией.. Где-то дальше, не смог найти где.

Не обязательно: выбросили функцию - расположение кода/данных сместилось - глюк "исчез".

Какие могут быть нюансы с таблицей?

Да никаких, по-идее.

Подумайте, кто у Вас в программе может записать слово по левому адресу (через указатель, например), да так, что его значение будет 0xFFFFFFFF. На глюк со стеком это не похоже, т.к. в этом случае возможность появления одиночной записи с таким значением маловероятна.

[GetSmart]

есть функция и вызов. В неопределенном месте (после вызова функции) процессор стабильно вылетает в data abort.

Код

void do_crc_8(unsigned char byte, unsigned char *crc8)
{
unsigned char ctmp = (*crc8^byte);  
*crc8 = crc_table[ctmp];
}


void write_AVR()
{    
  unsigned char crc8;
....      
  crc8=0;  
  
  for(itmp=0; itmp < sizeof(struct FHW_outs); itmp++)  
  {    
      while(!(AT91C_BASE_US1->US_CSR &AT91C_US_TXRDY));
      AT91C_BASE_US1->US_THR=buf[itmp];
      
      do_crc_8(buf[itmp], &crc8);// <<<----------------------------------------------!!!!
  }  
...
}

Запостите листинг этих двух процедур. Только не меняйте их. И проверьте чтобы этот код надёжно вызывал аборт. Может что-то в скомпилированном коде не то.

Хотя можно закомментировать код, там где троеточия. Если это на глюк не повлияет.

[Lelikk]

Не думаю, но на всяк случай спрошу, вы ни где не пробовали в проекте Embedded C++ использовать?
Спрашиваю потом, что мои с ним игрушки вылились как раз в точно такой неуловимый data abort, который удалось изгнать, только отказавшись от C++.

[overloaded]

Не думаю, но на всяк случай спрошу, вы ни где не пробовали в проекте Embedded C++ использовать?
Спрашиваю потом, что мои с ним игрушки вылились как раз в точно такой неуловимый data abort, который удалось изгнать, только отказавшись от C++.

Нет ) Но предостережения запомню ) Спасибо)

А проблема решилась)) Таки ошибся, как и предполагалось, я =))
Поставил дата брейкпоинт на код в прерывании, который портился.. И нашел свою ф-ю которая его портит =)) Вообще тот кусок кода (ф-ю) отлаживал на компьютере, и мог подумать что в ней ошибка только в последнюю очередь..

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

[Сергей Борщ]

Нет ) Но предостережения запомню )

А зря. Куча народу пользуется EC++ без всяких проблем. Надо помнить, что в 99.9% случаев виноват программист, точнее его незнание языка или инструмента, и только в 0.01% или даже меньше - компилятор.