Форум разработчиков электроники ELECTRONIX.ru

overloaded

Dec 27 2008, 21:44

есть функция и вызов. В неопределенном месте (после вызова функции) процессор стабильно вылетает в 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

Dec 27 2008, 22:02

Цитата(overloaded @ Dec 28 2008, 00:44)

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

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

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

overloaded

Dec 27 2008, 22:21

Цитата(aaarrr @ Dec 28 2008, 02:02)

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

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

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

defunct

Dec 27 2008, 23:16

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

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

sergeeff

Dec 28 2008, 01:54

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

overloaded

Dec 29 2008, 19:27

Цитата(sergeeff @ Dec 28 2008, 05:54)

Размер 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

Jan 9 2009, 19:05

Хм.. Дописал немного кода, снова начало глючить там-же. Посмотрел куда указывает аборт - кто-то портит код в прерывании, вынесенном в __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

Jan 9 2009, 19:14

Цитата(overloaded @ Jan 9 2009, 22:05)

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

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

Цитата(overloaded @ Jan 9 2009, 22:05)

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

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

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

GetSmart

Jan 10 2009, 00:26

Цитата(overloaded @ Dec 28 2008, 03:44)

есть функция и вызов. В неопределенном месте (после вызова функции) процессор стабильно вылетает в 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

Jan 10 2009, 07:49

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

overloaded

Jan 13 2009, 18:41

Цитата(Lelikk @ Jan 10 2009, 11:49)

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

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

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

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

Сергей Борщ

Jan 14 2009, 08:45

Цитата(overloaded @ Jan 13 2009, 20:41)

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

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