Что за хрень? Почему, если работает таймер, может сбоить UDP.
За одну минуту шлю в PC гдето около 30 000 пакетов по 64 байта(или меньше, неважно).
Таймер выдает прерывания - 50 герц. Как показала статистика, в среднем, в течение двух-трех минут проц вылетает в undefvec, swivec, dabtvec и тд. короче RAMEND?!?!?!
Приоритет у UDP выше.
Объясните.
Полная версия этой страницы: TC0 vs UDP. ARM7S
Цитата(KAlex @ Mar 30 2008, 14:24) 
Как показала статистика, в среднем, в течение двух-трех минут проц вылетает в undefvec, swivec, dabtvec и тд. короче RAMEND?!?!?!
Не очень понял, что Вы хотели сказать данной фразой - причем тут RAMEND?
Ищите ошибку в своей программе - UDP с TC0 работает нормально.
Цитата(aaarrr @ Mar 30 2008, 19:36)
что Вы хотели сказать данной фразой - причем тут RAMEND?
Ну это так, фразеологизм.
В программе все нормально. Если запретить прерывания от таймера на время обработки UDP - накаких проблем. Для меня в принципе это не критично, запрещаю. Но все таки интересно, почему им нельзя работать одновременно? Прием и передача по USB происходит аппаратно. По идее, никакие програмные действия на это влиять не могут. Однако же ...?
Цитата(KAlex @ Mar 31 2008, 11:54)
В программе все нормально. Если запретить прерывания от таймера на время обработки UDP - накаких проблем. Для меня в принципе это не критично, запрещаю. Но все таки интересно, почему им нельзя работать одновременно? Прием и передача по USB происходит аппаратно. По идее, никакие програмные действия на это влиять не могут. Однако же ...?
Влиять может многое.
Например компилятор, который криво обрабатывает выходы из прерываний или переходы между ARM/THUMB.
Или протокол обмена по USB может содержать внутри запреты прерываний с последующим ожиданием вашего таймера.
Часть функций может распологаться в озу и рекурсивный вызов некоторых функций может вызывать наползание стека на функцию.
Может влиять порядок инициализации таймера или USB, время между подачей частоты на перефирию и установка в ней регистров.
Даже банальные иголки от цепей подключенных к 50Гц.
Я прекрасно передавал в комп мегабит/с данных по протоколу MSD и при этом у меня один таймер дёргал ногу с частотой 3кГц (манчестер), а другой выдавал на внешнее оборудование 16кГц.
Цитата(_4afc_ @ Mar 31 2008, 11:14)
Например компилятор, который криво обрабатывает выходы из прерываний или переходы между ARM/THUMB.
Это как? Можно поподробнее.
Цитата(_4afc_ @ Mar 31 2008, 11:14)
Или протокол обмена по USB может содержать внутри запреты прерываний с последующим ожиданием вашего таймера.
Не, такого нет.
Цитата(_4afc_ @ Mar 31 2008, 11:14)
Часть функций может распологаться в озу и рекурсивный вызов некоторых функций может вызывать наползание стека на функцию.
Тоже нет.
Цитата(_4afc_ @ Mar 31 2008, 11:14)
Может влиять порядок инициализации таймера или USB, время между подачей частоты на перефирию и установка в ней регистров.
Непонятно. (с)
Цитата(_4afc_ @ Mar 31 2008, 11:14)
Даже банальные иголки от цепей подключенных к 50Гц.
Прерывания от таймера никакими ногами не дергает. Чисто внутреннее.
Скоре всего причина в обработчиках прерываний. Сами переферийные модули здесь не причем.
Ошибки в UDP модуле отрабатываются (прием с левой длиной и т.п.)? Стеков точно хватает?
Цитата(SpiritDance @ Mar 31 2008, 11:27)
Скоре всего причина в обработчиках прерываний. Сами переферийные модули здесь не причем.
Оставил только
Код
void timer0_irq_handler(void){
dummy = AT91C_BASE_TC0 -> TC_SR;
dummy = dummy;
AT91C_BASE_AIC -> AIC_EOICR = AT91C_ID_TC0;
}
dummy = AT91C_BASE_TC0 -> TC_SR;
dummy = dummy;
AT91C_BASE_AIC -> AIC_EOICR = AT91C_ID_TC0;
}
Не помогает.
Цитата(aaarrr @ Mar 31 2008, 11:34)
Ошибки в UDP модуле отрабатываются (прием с левой длиной и т.п.)?
Все учтено.
Цитата(aaarrr @ Mar 31 2008, 11:34)
Стеков точно хватает?
Стек обработчика прерываний?
А вот это интересно.
Цитата(aaarrr @ Mar 31 2008, 11:34)
Стеков точно хватает?
Скорее всего вот ОНО.
Если обрабатывается прерывание с высшем приоритетом, а в этот момент приходит более восьми запросов на прерывание от другого(одного и того же) источника. Что будет? В даташите как то скупо написано.
Цитата(KAlex @ Mar 31 2008, 12:24)
Это как? Можно поподробнее.
Например WinAVR криво компилирует MSD если установлены ключи thumb
intrframework. Причём видно это на USB. Другие части кода работают нормально.
IAR вроде имел проблемы с преамбулой в обработчиках в какихто режимах.
Цитата(KAlex @ Mar 31 2008, 12:24)
Непонятно. (с)
Был код или камень в котором USB работал, только если USB включить сразу при инициализации PLL.
Был код или камень в котором SSC работал, только если SSC включить только пепед непосредственной инициализацией его регистров.
Советую начинать отделять мух от котлет. Для начала разнесите на FIQ и IRQ.
Заодно посмотрите какой тип прерываний используете по фронту или по уровню и соответствует ли это типу вашего подтверждения (выхода) из прерывания.
Цитата(_4afc_ @ Mar 31 2008, 12:06)
Например WinAVR криво компилирует MSD если установлены ключи thumb
intrframework. Причём видно это на USB. Другие части кода работают нормально.
IAR вроде имел проблемы с преамбулой в обработчиках в какихто режимах.
intrframework. Причём видно это на USB. Другие части кода работают нормально.
IAR вроде имел проблемы с преамбулой в обработчиках в какихто режимах.
IAR 4.31. Оптимизация отключена.
Цитата(_4afc_ @ Mar 31 2008, 12:06)
Заодно посмотрите какой тип прерываний используете по фронту или по уровню и соответствует ли это типу вашего подтверждения (выхода) из прерывания.
На сколько я понимаю, для таймера и udp это не актуально.
Цитата(KAlex @ Mar 31 2008, 13:02)
Если обрабатывается прерывание с высшем приоритетом, а в этот момент приходит более восьми запросов на прерывание от другого(одного и того же) источника. Что будет? В даташите как то скупо написано.
Ничего не будет: запросы с низшим приоритетом на время обработки маскируются.
У Вас Interrupt Nesting используется? Если да, то все ли корректно в коде обработчика прерывания TC?
Цитата(_4afc_ @ Mar 31 2008, 12:06)
Например WinAVR криво компилирует MSD если установлены ключи thumb intrframework.
WinARM, наверное? Фигушки. И без --thumb-interwork генерит кривой пролог/эпилог. Цитата(_4afc_ @ Mar 31 2008, 12:06)
IAR вроде имел проблемы с преамбулой в обработчиках в какихто режимах.
Не нарывался. Скорее всего вы что-то путаете.
Цитата(Сергей Борщ @ Mar 31 2008, 14:32)
Не нарывался. Скорее всего вы что-то путаете.
Я IAR не пользовался, возможно спутал с приведённой вами ссылкой про GCC.
Цитата(Сергей Борщ @ Mar 31 2008, 14:32)
WinARM, наверное? Фигушки. И без --thumb-interwork генерит кривой пролог/эпилог.
WinAVR - конечно WinARM. У меня прерывания на асм написаны. И даже без --thumb-interwork, а просто если перенести весь или часть кода в thumb, то MSD коннектится не ко всем машинам стоящим в офисе. Причину не установил пока. Отваливается с повисанием контроллера. JTAG не разведён, поэтому сложно установить причину.
Заложил в новую партию SAM7S256 вместо SAM7S64, буду эксперементировать с кодом в озу и thumb для ускорения обмена более 2Мбит.
2KAlex:
А вы AT91C_BASE_AIC -> AIC_EOICR = AT91C_ID_TC0; делаете один раз? у вас в эпилоге или том, что вызывает timer0_irq_handler не пишется AIC_EOICR ? В этот регистр можно хоть 666 писать...
Цитата(KAlex @ Mar 31 2008, 13:02)
Если обрабатывается прерывание с высшем приоритетом, а в этот момент приходит более восьми запросов на прерывание от другого(одного и того же) источника. Что будет? В даташите как то скупо написано.
Ну если запросы не обрабатывать из текущего обработчика,то ничего. Другое дело сколько стека использует собственно сама функция-обработчик.
Цитата(_4afc_ @ Apr 1 2008, 10:54)
А вы AT91C_BASE_AIC -> AIC_EOICR = AT91C_ID_TC0; делаете один раз? у вас в эпилоге или том, что вызывает timer0_irq_handler не пишется AIC_EOICR ? В этот регистр можно хоть 666 писать...
В стартапе есть, выполняется только один раз при инициализации системы..
for (i=0; i<8; i++) AT91C_BASE_AIC->AIC_EOICR = 0; //clear INT steck
Ну и последняя команда в timer0_irq_handler.
Цитата(KAlex @ Apr 1 2008, 13:27)
В стартапе есть, выполняется только один раз при инициализации системы..
for (i=0; i<8; i++) AT91C_BASE_AIC->AIC_EOICR = 0; //clear INT steck
Ну и последняя команда в timer0_irq_handler.
for (i=0; i<8; i++) AT91C_BASE_AIC->AIC_EOICR = 0; //clear INT steck
Ну и последняя команда в timer0_irq_handler.
Я не это хотел спросить. Меня интересует: скока раз в цепочке
pc=0х1C->asm precode->timer0_irq_handler->asm postcode->pc=lr-4
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.