[dimka76 42]

у меня сейчас практически ваша ситуация.В качестве основы использовал стекGuido Socher ,переточенный на работу по прерываниям.Выход прерываний у ENC-шки устанавливаются в 0 и выйти из этого положения никак не удается.Даташит на эту тему вроде курил,ничего не нашел.Виснет стабильно,если в нее фигачить любыми не отфильтрованными пакетми(ARP,ICMP,UDP) c интевалом менее 5ms.Кстати,зачем "махать" флагом разрешения прерывания меги,я не понял.Чип вам говорит,что у него пакет в буфере лежит,а вы его отказываетесь обрабатывать?ИМХО,так еще хуже.Тут похоже,что наоборот не успеваю забирать.Да,SPI у меня на максимуме(4MHz при 3V).Сейчас проблему решил лобовым способом-по таймеру периодически поллю вход прерывания,и если он в 0 больше определенного интевала,то ENC получает ломом по балде-хард-ресет и инит по новой.Но это,мягко говоря неспортивно...

Вам удалось как-то решить эту проблему?

 

У меня такая же фигня.

Только висяк появляется в момент включения питания, когда комп видя что подключился кабель начинает ENC посылками забрасывать (секунд 10-20 бросает и успокаивается), вот в процессе этого ENC и виснет.

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

[WHILE 0]

я рад,что нас уже трое Можно выпить за погибель микрочипа :cranky:

Если работать в режиме медленного диалога с компом,то не вещается вообще(по крайней мере 8 часов точно.Я и обнаружил-то зависание обмена только на живой сети вначале.У нас тут типичный пионернет,и временами прилетает с десяток ARP-запросов с интервалом,если верить снифферу,равным 0.И все-девайс отвалился.Стал экспериментировать напрямую и выяснил-виснет,если приходит несколько все-равно каких пакетов,вызывающих прерывание с интервалом меньше 5ms.

По совету :rolleyes: zltigo "медленно и печально" просмотрел весь софт приема.Слегка убыстрил алгоритм,теперь вешается если пакеты слать с интервалом менее 3ms.Даташит читал,эррату использовал.У меня пятая ревизия чипа.

Пока отложу,на той неделе продолжу игры дальше...

[zltigo 0]

Слегка убыстрил алгоритм,теперь вешается если пакеты слать с интервалом менее 3ms.

Ну для начала пакеты банально буферизируются чипом, если, конечно на это память есть. Это у Вас постоянный поток пакетов? Какого размера? Или достаточно, как и у коллег уже двух подряд?

У меня гарантированно при запуске системы вываливаются в сеть до нескольких десятков бродкастовских пакетов стык в стык. Их вынуждено глотают том числе и железяки на ENC - проблем нет. Короткие (60-300 байт)пакеты сыпятся уже конкретно на ENC в совершенно произвольном темпе в том числе и, как минимум, попарно, но средняя нагрузка гарантированно не приводит к перегрузке приемного буфера ENC. В экстремально-аварийных случаях на переходных режимах в сети прересылается с бродкастовским MAC до 4 мегабайт пакетами по килобайту с гарантированными паузами между пакетами в 2ms (но при этом могут и другие пакеты проскакивать изрежка). Довольно много свитчей такого потока broadcast просто не выдерживают :( - теряют пачками по 128-256 пакетов. ENC выживает без зависаний. В процессе написания софта проводились и "лабораторные работы" над ENC c иммитацией разнообразных нагрузок - с прерываниями проблем нет.

[Rst7 5]

Довольно много свитчей такого потока broadcast просто не выдерживают - теряют пачками по 128-256 пакетов.

 

Есть мнение, что это срабатывает Broadcast Storm Control. Например, классический представитель RTL8309 имеет данную функцию (кстати, она почти во всех свичах есть, кроме самых старых, которых уже выбросили давно):

 

8.3.10. Broadcast Storm Control

After 64 consecutive broadcast packets (DID=FFFF-FFFF-FFFF) have been received by a particular port, any following

incoming broadcast packets will be discarded by this port for approximately 800ms. Any non-broadcast packet can reset the time window and broadcast counter such that the scheme restarts.

Note: Trigger condition is consecutive 64 DID = FFFF-FFFF-FFFF packets. Release condition: receive non-broadcast packet on or after 800ms.

 

Обычно, разрешение/запрещение данной функции выполняется bootstrap-ножкой (помимо EEPROM и других способов) и производители свичей подключают их так, чтобы получить включенный по умолчанию Broadcast Storm Control.

 

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

 

Но в общем случае, тут проблема не в каких-то глюках ядер свичей, а именно в выбранных производителем режимах работы по умолчанию.

[zltigo 0]

Но в общем случае, тут проблема не в каких-то глюках ядер свичей, а именно в выбранных производителем режимах работы по умолчанию.

Похоже, ибо уж больно ровные пачки пакетов теряются - обычно ровно 128, но ситуевина такая, что ложатся простентькие пластмасски на 5-8 портов. Солидные - живут, посему особых хлопот это не доставляет. Потроха не исследовал - не до этого. Есть два варианта обхода эффекта, нежели таки попадется на обьекте....

[Rst7 5]

что ложатся простентькие пластмасски на 5-8 портов. Солидные - живут

 

Если солидные - это управляемые свичи, то там уж как руками наконфигурили. И, кстати, всегда переконфигурить можно. А мыльницы - они, в основном, все шторм дропают по умолчанию. Там либо резистор бутстрепа перепаивать, либо припаивать EEPROM'ку с необходимой конфигурацией. Лично я припаиванием епромки пользуюсь без зазрения совести, конечно, не для банального отключения штормконтрола ;)

[zltigo 0]

Если солидные - это управляемые свичи, то там уж как руками наконфигурили.

Ну не настолько. Обычно :) достаточным :) является наличие просто металлического корпуса :) :).

[Rst7 5]

является наличие просто металлического корпуса

 

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

 

А что, в Вашем проекте было так необходимо пролить такой объем броадкаста? Или тонкости поведения свичей выяснились, когда уже было поздно что-либо менять? ;)

[zltigo 0]

А что, в Вашем проекте было так необходимо пролить такой объем броадкаста?

Удобно было и есть, для ввода в работу резерва железно-тупо кидаться бродкастом, потом уже после разбираться с конфигурацией и подниматься.

ADM6999

С ADM самодельные железки пользуем.

[Rst7 5]

Удобно было и есть, для ввода в работу резерва железно-тупо кидаться бродкастом

 

Надо было мультикаст зашарашить :)

 

С ADM самодельные железки пользуем.

 

Которые себе такого не позволяют по умолчанию :) Вопросов больше не имею :)

[zltigo 0]

Надо было мультикаст зашарашить :)

Неудобно :(, но в качестве второго варианта обхода возможной проблемы так и сделано.

Которые себе такого не позволяют по умолчанию

Не для этой задачи, а для TDM<->Ethernet

[WHILE 0]

Итак,гуру пообщались о своем о "гуровском",теперь можно и нам простым смертным о наших делишках покалякать.

Вроде победил я этого ежика,2 часа сыплю в него чем не попадя, зависаний нет.

Должен сразу извиниться перед zhevak,пришлось все-таки "махать"флагом разрешения прерывания Меги.Это по времени и стабильности работы оказалось выгодней,чем как рекомендует мелкочип,при входе в обработчик запрещать выдачу прерываний на пин INT ENC,а при выходе разрешать.Больно медленно-4 транзакции SPI на установку банка регистов и 2 на сброс EIE.INTIE.И вдобавок временами все-таки висло.

У меня сделано следующим образом-вход внешнего прерывания меги настроен на работу по низкому уровню,а не как рекомендует мелкочип по падающему.В обработчике запрещаю прерывания и устанавливаю флаг наличия данных в буфере ENC.SPI тоже работает по прерываниям,т.к поллинг SPI с его многочисленными while(!(SPSR&(1<<SPIF))) на 8Мгц Меги жрет ну очень много времени.

В главном цикле подбираю флаг и запускаю процедуру чтения буфера.Если нет ошибок-анализ,чего там прилетело.Если что-то нужное(ARP,пинг или запрос сервера)-отвечаю.Если нет никаких операций с ENC-разрешаю внешнее прерывание от ENC.Если пин стоит в 0,значит есть еще пакеты и все повторяется.Если пакеты летят быстрее,чем успеваем их забирать,то при достижении EPKTCNT==255 ENC начинает их дропать. Как-то так...

А вообще конечно медленный чип,чтобы забрать пакет и подготовиться к приему следующего надо сделать кучу телодвижений.И даташит полное г-но или рассчитан на телепатов,весьма мутно изложено и на все про все на все режимы работы с пяток примеров в несколько строк на псевдокоде.

[Rst7 5]

Вообщем-то для таких внешних маков, которые побайтно кормят проца данными имеет смысл заголовки разбирать прямо на лету.

 

Типа, например такого (писано несколько лет назад для SLIP, но идея должна быть ясна)

__task IPreciver(void)
{
INT_TASK_HEADER(iprx_task,8,40);
char ip_pos;
char ip_hlen;
char prtc;
char c;
unsigned int ip_len;
unsigned long rip;

 //Ожидаем начало пакета
do
{
 TRM_CHAR=_sliprx();
}
while(!EOP);
L_SLIP_START:
ip_pos=0;
ip_hlen=0;
do
{
 c=_sliprx();
 if (EOP) goto L_SLIP_START;
 switch(ip_pos)
 {
  case 0: ip_hlen=c<<2&0x3F; break;
  case 7: if © goto L_SLIP_END; break;
  case 2: ip_len=c<<8; break;
  case 3: ip_len|=c; break;
  case 9: prtc=c; break;
  case 12: rip=(unsigned long)c<<24; break;
  case 13: rip|=(unsigned long)c<<16; break;
  case 14: rip|=(unsigned long)c<<8; break;
  case 15: rip|=c; break;
  case 16: if (c!=MIP0) goto L_SLIP_END; break;
  case 17: if (c!=MIP1) goto L_SLIP_END; break;
  case 18: if (c!=MIP2) goto L_SLIP_END; break;
  case 19: if (c!=MIP3) goto L_SLIP_END; break;
 }
 ip_pos++;
}
while(ip_pos!=ip_hlen);
if (testrxcrc()) goto L_SLIP_END; //Не совпала контрольная сумма
ip_len-=ip_hlen; //Длинна IP данных
switch(prtc)
{
 case 1:
  ICMPrx_jmp(rip,ip_len);
  break;
 case 6:
  TCPrx_jmp(rip,ip_len);
  break;
}
L_SLIP_END:
do
{
  _sliprx();
}
while(!EOP);
goto L_SLIP_START;

}

 

Кстати, _sliprx сразу и контрольную сумму IP считает на ходу.

[WHILE 0]

Идея понятна.Действительно,можно будет время приема сократить прилично-избавиться от внешней функции разбора пакета.Спасибо.

[Rst7 5]

Если пакеты летят быстрее,чем успеваем их забирать,то при достижении EPKTCNT==255 ENC начинает их дропать

 

Кстати, я бы на Вашем месте озадачился правильной обработкой Flow-Control'а.