Очень занятное поведение флага INTSTATUS_bit.RXDONEINT обнаружилось.

Разрешено только прерывания RXDONEINT. Там такой код:


Неспеша кормлю девайсу по одному пакету (дабы быть уверенным, что никакого переполнения не происходит). В результате в консоль сыпется:



Пуристы для тестов могут заменить usart0_txc на ногодрыг и наблюдать осциллографом тот же результат - импульсов то 1, то 2.

Если бы просто сделать

то этот код часто (а то и вообще всегда) вызывается 2 раза - не сбрасывается флаг RxDoneInt, соответственно, сброс соответствующего бита в NVIC не помогает - не снят изначальный флаг, т.е. происходит опять поднятие флага в NVIC и последующее прерывание. Правда, на второй заход сброс таки происходит.

Вот такой код вроде (ну ибо на обозримом отрезке времени мне не удалось наблюдать двойной вызов) всегда вызывается один раз:


Ересь какая-то в общем. Другие биты не проверял.

Есть у кого какие мысли?

В общем-то такое поведение и не особо страшно, но уж очень стремно

Мне кажется что у него какой-то внутренний сигнал, устанавливающий запрос RXDONEINT не успевает сняться.
Если быстро заходите в прерывание и пытаетесь сбросить запрос, то внутренний "триггер" (не флип-флоп, а именно спусковой крючок) снова его ставит. А если немножко подождать - то внутренний "триггер" успевает сняться и все OK.
У меня в прерывании с регистрами EMAC ничего не делается - просто ставится событие RTOS, поэтому до обработки собственно запроса в приоритетном потоке проходит некоторое время (явно больше чем Ваши NOPы), и такого поведения не наблюдается.

Да вот там есть интересная фраза такая в мане, что


Какими они там сигналами асинхронно выставляются, я уж хз. Запросто эти сигналы могут быть заведены на вход S триггеров и быть по длительности хз какими. Вот и не сбрасывается.



Так тут тоже самое. NVIC_SetPend(NVIC_RIT) - это и есть запуск потока обработки. Только у него приоритет ниже, посему начинает обрабатывать позже.

А если dsb вставить после записи INTCLEAR?

Я правильно понял - происходит двойной заход в обработчик?
По моему NVIC должен запрещать двойные заходы. Только после полного выхода.

Сообщение отредактировал GetSmart - Jun 15 2011, 13:58

Посмотрите соответствующий код в ассемблере, нет ли там записи в INTSTATUS.
У меня были какие-то неприятности с прерываниями от ЕМАС, когда я делал так:

давненько было - не помню подробностей.
Сделал так:

И неприятностей больше не было.

Барьеры не помогают (только как задержка вместо нопов). Я тоже сразу подумал о синхронизации всяких Load-Store конвейеров, но это не оно.



Не двойной заход. Вход-выход и опять вход-выход. На втором входе все замечательно очищается.



Такой код дрыгает ножкой два раза на один пакет. Без паузы.



Конечно нет. Код корректный.

Не совсем то же самое - Вы цупите INTCLEAR. Я прерывания от EMAC запрещаю через NVIC:

Разбор чего там EMAC захотел и общение с его регистрами происходит позже в потоке

Ну тогда похоже Вы не видите этих граблей, ибо очень долго до собственно сброса флага.

Я с EMAC плотно пока не работал, поэтому есть лишь догадка: в первом случае INTSTATUS вычитывается ПОСЛЕ первого обнуления в INTCLEAR, а во втором СНАЧАЛА читается статус, потом очищается прерывание. Может быть тот самый упомянутый выше "спусковой крючок" находится в INTSTATUS и сначала надо его прочитать (как в некоторых self-clear прерываниях), а потом уже принудительно прописать бит в INTCLEAR?

Я в LPC1768 не смог победить их работу с прерыванием RxDone. По итогу сделал поллинг индекса в DMA. В других примерах (FreeRTOS например), сделано так же. Прерывание там используется только чтобы проснуться. Да, а заметили, что первые пара пакетов шлётся криво? В Errata описан такой баг.

Я так тоже думал. Нет, просто паузы достаточно для последующей нормальной очистки флага.



А что его побеждать? Оно работает.



Хватило квалификации не наступить. Ибо изначально изучил Errata и закодил передачу пары пакетов заранее. И вообще, описанный баг превращается в фичу

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

Люди, а каких вы скоростей на Lpc17 достигаете по tcp?

Смотря какую полезную нагрузку вкладывать. В принципе, при верном подходе утилизируется вся доступная полоса.

Да, кстати, собственно по теме топика. Оказывается, у меня не была припаяна ножка RX- на PHY - работало по одному проводу. В результате после окончания пакета на 10МБит были еще дрыгания, которые интерпретировались PHY как начало нового фрейма. А MAC, как оказалось, даже такой в упор непакет все таки отбрасывает с установкой флага прерывания.

В общем, имейте в виду, что может происходить и такая ересь.