Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Проблема с "strb r3, [r2]"
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
XGoblinX
доброго времени суток.
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.


На работе ни кто не знает что такое происходит.

Может кто-то знает?

Сразу спасибо за ответы
sergeeff
Вы ведь на С пишете? Ну и опубликовали бы кусочек той программы, про которую вы так живописно рассказываете.
XGoblinX
Цитата(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 не работают.
scifi
Сначало надо бы подтвердить, что реально содержимое памяти портится, а не средства отладки врут.
Выводите содержимое подозрительного участка памяти до и после выполнения подозрительного кода наружу без участия отладчика (RS-232, printf и т.д.)
sergeeff
Цитата(XGoblinX @ Apr 7 2011, 18:58) *
.


Чего-то я не понял. В main() объявляете *tst, выделяете память, заполняете. Все ОК! А что за указатель p, который используете в функции Write?
XGoblinX
Цитата(scifi @ Apr 7 2011, 17:32) *
Сначало надо бы подтвердить, что реально содержимое памяти портится, а не средства отладки врут.
Выводите содержимое подозрительного участка памяти до и после выполнения подозрительного кода наружу без участия отладчика (RS-232, printf и т.д.)

Средства отладки не врут. Ставлю условие и брейк. В брейк попадает. Делаю вывод что отладка честна.


Цитата(sergeeff @ Apr 7 2011, 19:08) *
Чего-то я не понял. В main() объявляете *tst, выделяете память, заполняете. Все ОК! А что за указатель p, который используете в функции Write?

Опечатался. Точка там. Программа на самом деле на С++. Это просто пример. Картина в целом такая как я и описал.

Почему могут затрагиваться байты?

На питание грешил. Всё хорошо. Ровно 3.3В.
scifi
Цитата(XGoblinX @ Apr 8 2011, 08:19) *
На питание грешил. Всё хорошо. Ровно 3.3В.

Не вредно будет проверить и тактовые частоты. А у питания кроме среднего уровня ещё и шум надо смотреть (туда же относятся правильность разводки платы и развязывающие конденсаторы).
XGoblinX
Цитата(scifi @ Apr 8 2011, 05:29) *
Не вредно будет проверить и тактовые частоты. А у питания кроме среднего уровня ещё и шум надо смотреть (туда же относятся правильность разводки платы и развязывающие конденсаторы).

Дело в том, что уже много устройств в таком исполнении. Питание безупречное. Шумы буквально микровольты.
Появляется эта проблема буквально на штучках. Хотелось бы знать в процессоре ли это дело или нет.
И такое ощущение, что эта проблема проскакивает в во время эксплуатации.

Цитата(scifi @ Apr 8 2011, 05:29) *
Не вредно будет проверить и тактовые частоты. А у питания кроме среднего уровня ещё и шум надо смотреть (туда же относятся правильность разводки платы и развязывающие конденсаторы).

Частота стабильна. Проверил.
Заметил еще одну вещь. Есть дальше снова этот же strb, но со следующим байтом по порядку. Снова происходит дерганье битом того же второго в памяти байта.
scifi
Цитата(XGoblinX @ Apr 8 2011, 10:17) *
Частота стабильна. Проверил.

Я не про это. Теоретически можно обсчитаться в коэффициентах PLL и затактировать в разы быстрее, чем положено.
XGoblinX
Цитата(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] происходит засорение...

XGoblinX
Упростил пример:

Код
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.

В другие приборы загружаю этот же код, всё ок.
Но во время эксплуатации, то там то здесь проскакивает такая чепуха.

Подскажите пожалуйста.
aaarrr
Цитата(XGoblinX @ Apr 8 2011, 15:47) *
В другие приборы загружаю этот же код, всё ок.

Другие приборы на том же процессоре?
XGoblinX
Цитата(aaarrr @ Apr 8 2011, 11:49) *
Другие приборы на том же процессоре?

Да. Даже партия одна и та же. Как процов, так и приборов.
У меня тоже был такой глюк однажды, но пока я его отлавливал, он исчез.
К счастью на данном устройстве очень стабильный.
Такой прикол наблюдается только на Ethernet ram. На всех других во всех диапазонах всё как и должно быть.

Сейчас с NXP пытаемся связаться.
Такие приколы стали происходить последние 3 месяца.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.