|
|
  |
Проблема с "strb r3, [r2]" |
|
|
|
Apr 7 2011, 15:29
|
Участник

Группа: Участник
Сообщений: 43
Регистрация: 13-12-10
Пользователь №: 61 586

|
доброго времени суток. lpc2368. Столкнулся с аномальным поведением при работе с ethernetRAM (При работе с основной RAM памятью такого не наблюдаю, но нужна именно эзернет). Пояснения: Создаю структуру в EthernetRAM. Код struct TEST { unsigned short stat; unsigned short nop; unsigned short mas[20]; } tst; Всю структуру заполняю 0x55. Проблема появляется в строке: Код //p->stat = 0xffff; - строка на СИ. Когда пытаюсь записать таким образом после stat, как в это же время появляется мусорный бит в поле nop. В памяти выглядит так: ff ff d5 55 55 55 .... Ниже код на асме с пояснением: Код ldr r2, [r11, #-0x018] // после этого в регистр r2 попадает число 0x7fe014f8 mvn r3, #0x00000000 // в регистре r3 появляется 0xffffffff strb r3, [r2] // вот в этот момет происходит самое страшное. Одновременно записывается нулевой байт с адреса 0x7fe014f8 и равен 0xff. И записывается через // 1 байт (не следующий, а через 1, т.е. второй!) в старший бит единичка! Т.е. вместо числа 0x55 появляется число 0xd5! // Промежуточный вариант такой: ff 55 d5 55 55 55 .... mvn r3, #0x00000000 // в регистре r3 появляется 0xffffffff strb r3, [r2, #+0x001] // заполняется первый байт, после чего буфер (структура) выглядит так: ff ff d5 55 55 55. На работе ни кто не знает что такое происходит. Может кто-то знает? Сразу спасибо за ответы
Сообщение отредактировал XGoblinX - Apr 7 2011, 15:29
|
|
|
|
|
Apr 7 2011, 15:58
|
Участник

Группа: Участник
Сообщений: 43
Регистрация: 13-12-10
Пользователь №: 61 586

|
Цитата(sergeeff @ Apr 7 2011, 15:38)  Вы ведь на С пишете? Ну и опубликовали бы кусочек той программы, про которую вы так живописно рассказываете. Если поможет, то держите: Код struct TEST { unsigned short stat; unsigned short nop; unsigned short mas[20]; };
void Write(void) { p.stat = 0xffff; }
void main(void) { TEST * tst = malloc_z(sizeof(TEST)); memset(tst, 0x55, sizeof(TEST)); Write(); // Здесь возникает глюк. ... } fiq, irq не работают.
Сообщение отредактировал XGoblinX - Apr 8 2011, 05:34
|
|
|
|
|
Apr 7 2011, 19:08
|
Профессионал
    
Группа: Свой
Сообщений: 1 481
Регистрация: 10-04-05
Пользователь №: 4 007

|
Цитата(XGoblinX @ Apr 7 2011, 18:58)  . Чего-то я не понял. В main() объявляете *tst, выделяете память, заполняете. Все ОК! А что за указатель p, который используете в функции Write?
Сообщение отредактировал IgorKossak - Apr 8 2011, 06:46
Причина редактирования: Бездумное цитирование
|
|
|
|
|
Apr 8 2011, 04:19
|
Участник

Группа: Участник
Сообщений: 43
Регистрация: 13-12-10
Пользователь №: 61 586

|
Цитата(scifi @ Apr 7 2011, 17:32)  Сначало надо бы подтвердить, что реально содержимое памяти портится, а не средства отладки врут. Выводите содержимое подозрительного участка памяти до и после выполнения подозрительного кода наружу без участия отладчика (RS-232, printf и т.д.) Средства отладки не врут. Ставлю условие и брейк. В брейк попадает. Делаю вывод что отладка честна. Цитата(sergeeff @ Apr 7 2011, 19:08)  Чего-то я не понял. В main() объявляете *tst, выделяете память, заполняете. Все ОК! А что за указатель p, который используете в функции Write? Опечатался. Точка там. Программа на самом деле на С++. Это просто пример. Картина в целом такая как я и описал. Почему могут затрагиваться байты? На питание грешил. Всё хорошо. Ровно 3.3В.
|
|
|
|
|
Apr 8 2011, 06:17
|
Участник

Группа: Участник
Сообщений: 43
Регистрация: 13-12-10
Пользователь №: 61 586

|
Цитата(scifi @ Apr 8 2011, 05:29)  Не вредно будет проверить и тактовые частоты. А у питания кроме среднего уровня ещё и шум надо смотреть (туда же относятся правильность разводки платы и развязывающие конденсаторы). Дело в том, что уже много устройств в таком исполнении. Питание безупречное. Шумы буквально микровольты. Появляется эта проблема буквально на штучках. Хотелось бы знать в процессоре ли это дело или нет. И такое ощущение, что эта проблема проскакивает в во время эксплуатации. Цитата(scifi @ Apr 8 2011, 05:29)  Не вредно будет проверить и тактовые частоты. А у питания кроме среднего уровня ещё и шум надо смотреть (туда же относятся правильность разводки платы и развязывающие конденсаторы). Частота стабильна. Проверил. Заметил еще одну вещь. Есть дальше снова этот же strb, но со следующим байтом по порядку. Снова происходит дерганье битом того же второго в памяти байта.
|
|
|
|
|
Apr 8 2011, 08:51
|
Участник

Группа: Участник
Сообщений: 43
Регистрация: 13-12-10
Пользователь №: 61 586

|
Цитата(scifi @ Apr 8 2011, 07:50)  Я не про это. Теоретически можно обсчитаться в коэффициентах PLL и затактировать в разы быстрее, чем положено. Внешний резонатор = 12Mhz Fcco = 288Mhz cclk = 48Mhz usbclk = 48Mhz Как получаю?: 1) MSEL <- 11 NSEL <- 0 2) CCLKCFG = 5 //Выходной PLL сингнал я делю на 5. Также пробовал увеличивать деление до 11 с шагом 2. Не помогло! Я в ступоре. Глюк крайне стабильный пока на данном процессоре. Выяснил, что если в регистре r2 младший байт менее 127, то всё ок. Но если больше (т.е. старший бит в единице) сразу начинает проявляться этот глюк. strb r2, [r3] //При r2 = [0x00000000 до 0x0000007f] всё ок. При [0x00000080 до 0x000000ff] происходит засорение...
|
|
|
|
|
Apr 8 2011, 11:47
|
Участник

Группа: Участник
Сообщений: 43
Регистрация: 13-12-10
Пользователь №: 61 586

|
Упростил пример: Код void main(void) { u16 * pntr = (u16*)0x7fe014f8; memset(pntr, 0x55, 158); while(1) { *pntr = 0xffff; pntr++; } } В результате первого присвоения получается: ff ff d5 55 55 55 55 55. После втрой итерации получается: ff ff ff ff 55 55 55 55 55. После третьей опять глюк получается: ff ff ff ff ff ff ff d5 55 55. В другие приборы загружаю этот же код, всё ок. Но во время эксплуатации, то там то здесь проскакивает такая чепуха. Подскажите пожалуйста.
Сообщение отредактировал XGoblinX - Apr 8 2011, 11:48
|
|
|
|
|
Apr 9 2011, 09:33
|
Участник

Группа: Участник
Сообщений: 43
Регистрация: 13-12-10
Пользователь №: 61 586

|
Цитата(aaarrr @ Apr 8 2011, 11:49)  Другие приборы на том же процессоре? Да. Даже партия одна и та же. Как процов, так и приборов. У меня тоже был такой глюк однажды, но пока я его отлавливал, он исчез. К счастью на данном устройстве очень стабильный. Такой прикол наблюдается только на Ethernet ram. На всех других во всех диапазонах всё как и должно быть. Сейчас с NXP пытаемся связаться. Такие приколы стали происходить последние 3 месяца.
|
|
|
|
|
  |
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|