Миландр

Имеются отладочная плата (на мс ревизии 1453) и 2 макета на чипах ревизий 1525 и 1644.
Выставляем джамперами режим коммутатора с автоматическим выбором скорости и дуплекса. Остальные параметры через регистры не меняем. В итоге подключения на 100Мбит/c, полный дуплекс.
Подключаем 4 компьютера к одному коммутатору. Если между двумя компьютерами (№1 и №2) идет большой трафик (смотрели на telnet и TCP-передачах), то коммутатор каждые пару секунд переходит в режим концентратора, и пакеты от компьютеров №1 и №2 сыпятся и на остальные порты к компьютерам №3 и №4. При этом индикатор активности сетевых портов №3 и №4 не мигает.
На пингах такого нет, возможно из-за небольшого трафика.
Предположение в переполнении ОЗУ хранения пакетов.
Есть возможность доступа к регистрам микросхем по SPI, можем подробнее диагностировать возникшую проблему.

UPD. Мы не одиноки в данной проблеме

В результате моделирования на стенде прояснилось следующее поведение коммутатора.

Когда пакет приходит в коммутатор, то MAC адрес источника кладется в таблицу (если адреса в ней еще нет), либо обновляется в таблице - обновляется время жизни записи.

Далее возможны две ситуации когда пакет может попасть не в тот выход.

1 - Когда пакеты маленькие, порядка минимальной посылки.

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

В нашем случае такое поведение пропадало при увеличении пакета до 70 байт.

2 - Случай когда пакеты большие, но посылает только один источник.

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

Оба случая являются штатными режимами работы коммутатора.

Ситуация:
Есть 8-ми портовый коммутатор на 5600ВВ3Т.
К нему на один порт подключён 1986ВЕ1Т, а от микросхем 5600ВВ3Т на МК заведён SPI для управления.
На другой порт коммутатора подключён импортный прозрачный для всех, 2-ух Мбитный SHDSL-модем (увы, в стране нет м/сх подобного типа и видимо в ближайшие 10 лет не предвидится).

Дак вот, если на втором конце линии модема нет абонента, т.е ведомого модема, или обрыв линии связи произошёл, то он начинает сыпать в линию PAUSE Frame, причём периодически забивая наглухо сеть, да так, что первым, кто "падает в обморок", т.е у кого напрочь отваливается сеть, это подключённый внешний ноутбук.

То есть к модему я придраться не могу, он выполняет всё, в соответствии с отдельной ветвью протокола Ethernet, ставить импортный коммутатор с FlowControl в разрыв между модемом и 5600ВВ3Т сильно не хочется, потому как:
во-первых это "костыль";
во-вторых весьма дорогостоящий "костыль";
в-третьих если я поставлю в разрыв между модемом и 5600ВВ3Т ещё один коммутатор, то туда кто-нибудь, когда-нибудь обязательно врубится, что может привести к нежелательным результатам;
и в четвёртых, мне никак не хочется выбрасывать 5600ВВ3Т, потому как мне ещё авто-резервирование линий делать, а с ним, как я уже выносил мозг N-страниц назад, это вполне реально.

Вопрос - насколько я понимаю в 5600ВВ3Т функция FlowControl (т.е аппаратная реализация этого семейства протоколов Ethernet) отсутствует.
Если так, то могу-ли я используя свойство управляемости коммутатора 5600ВВ3Т от МК, подключённого на другой порт, выполнить управление потоком в соответствии с набором протоколов FlowControl программно? Или есть что-то, что кардинально не позволяет мне это выполнить?

Например со следующими условиями:
1) При включении МК переводит все потоки от модема на себя и периодически "пингует" на наличие аппаратуры на другом конце.
2) Если видим PAUSE Frame, то выключаем порт модема и через некоторое время проверяем снова.
3) В процессе работы анализируем трафик от модема на наличие пакетов PAUSE Frame, и если они начинают сыпать непрерывно, то выполняем пункт 1, при этом включаем резервный канал связи, подключённый к другому порту коммутатора на 5600ВВ3Т, если это один-два пакетика в минуту, то не обращаем внимание.

_________________
"В радиотехнике, как в церкви - многое не понятно, но приходится верить"
ВлГУ. к.т.н Садовский Н.В

Здравствуйте!
Пытаемся запустить микросхему коммутатора 5600ВВ3, маркировка даты выпуска 1617.
Включаем по типовой схеме кварцевым резонатором.
На выводе 1 имеется меандр частотой 25 МГц.
Выводы MODE0..3 подтянуты к плюсу питания 3.3В.
При подключении коммутатора к сетевой карте индикатор линии на сетевой карте не включается.
По SPI считываем значения регистров 5600, в частности:
Номер регистра - значение
2 - 0xfc
4 - 0x77
0x0b - 0x77
Как видно, в старшем разряде регистра STATUS единица, что, согласно спецификации, значит, что генератор выключен или не готов.
Как это объясняется и как заставить коммутатор работать?

Здравствуйте, Неман!
Извините, пожалуйста, ответ на Ваш вопрос совершенно не своевременный, и наверное, Вы его уже решили, но все-таки по словам главного конструктора проблем быть не должно, но если у Вас возникают или возникали проблемы с реализацией озвученных Вами пунктов, напишите, пожалуйста, какие именно.

_________________
Отдел технической поддержки support@milandr.ru

Так, ну в общем Pause Frame от проводного модема удалось побороть.
по нижеприведённому скриншоту видно, что "мусор" от модема отправляется на фиксированный mac-адрес. И после того, как модем начинает истерично вещать "Не шлите мне данные" он своими запросами просто элементарно глушит всю подсеть. На скриншоте видно, что обмен практически прекратился, хотя по идее не его модема, это дело, забивать наглухо всю сеть своей служебной информацией.

У меня в изделии 1986ВЕ1Т подключён к 5600ВВ3Т по SPI-интерфейсу для управления и по Ethernet, как один из абонентов. В моём случае решение проблемы состоялось в том, что в таблицу маршрутизации периодически (раз в минуту-две) прописывается условие "Абонент с мак-адресом 0180C2000001 находится на том порту, откуда пришли данные" Проще говоря я разворачиваю "мусор" обратно модему, так что ВЕ1Т его даже не ощущает и соответственно не тратит время на обработку.
Соответственно когда по проводному каналу модема связь восстанавливается и он перестаёт пытаться слать в сеть "мусор", данные на него и от него уходят и приходят в нормальном штатном режиме.
Поможет мой опыт кому или нет мне неведомо, но проблема довольно приличная в общем масштабе, т.к все xDSL модемы у нас как правило выполнены на ЭКБ ИП и отечественные разработчики на них слабо влияют.

Кстати говоря, импортный неуправляемый коммутатор, у которого в спецификации прописано "Flow Control" мне не помог совсем, хотя по идее должен был закрывать порт до восстановления связи по проводному каналу модема, поэтому то, что я ещё на этапе разработки озаботился подключением управления к МК мне сильно помогло.

Ну и соответственно, разработчикам Миландра просьба обратить на реализацию Flow Control в своих текущих или будущих разработках.

_________________
"В радиотехнике, как в церкви - многое не понятно, но приходится верить"
ВлГУ. к.т.н Садовский Н.В

Добрый день!
Сделал 8 портовый коммутатор по аналогии с приведенной в отладочной плате схемой. При включении каждая из микросхем 5600 работает нормально, но не коммутируется по интерфейсу MII. При изучении с осцилом состояния ног выяснил что с ножки CLK_OUT выходит 25МГц и через буфер раздается на тактовые входы, но до резистора стоящего по схеме после буфера есть сигнал, а после нет, при этом прозвонка не показывает коротыша. Может ли это быть связано с конфигурированием микросхемы? Хотя по описанию MII по дефолту включен.

(Стоял слишком большой резистор. На демоплате R48 - 10 Ом.)

В свежей СП(2.5.0) на рисунке 13 не указан источник сигнала CLK_OUT_2 и требования к нему.

_________________
сочувствующий…

На стр. 20 описано какой сигнал необходимо подавать на RXCLK и TXCLK. 25МГц, уровни сигнала в таблице предельно допустимых, стр 41.

ТСКЯ.431291.001СП, Версия 2.8.0 от 06.09.2019
1) Страница 36 - Рисунок 11 "R29 – R32 = 12,4 кОм +/-10%".
Может быть всё же 1% ?

2) Страница 1 - "Динамический ток потребления, Iосс , не более 400 мА", в тоже время на странице 40, в таблице 45 "Динамический ток потребления не более 500 мА". В ТУ кстати тоже указан динамический ток потребления не более 500 мА.
Вопрос - всё-таки 400 мА или 500 мА?

3) Там же, в таблице 45 Динамический ток потребления
– от источника питания Ucc;
– от источника питания Uccphy ;
не более 500 мА.
Вот только из ТУ на м/сх становится понятно что 500 мА это суммарный ток по выводам Ucc и Uccphy, а судя по СП это по 500 мА и для каждого раздельно, несмотря на то, что обозначение одно - Iocc.
Может быть как и в ТУ надо добавить слово "суммарный" ?

4) Вот с Ucc всё понятно, выводы такие есть, а вот насчёт Uccphy:
в таблице выводов есть "VDDA - Питание приемопередатчиков PHY" я так понимаю это оно? Но тогда в тексте должна быть где-то взаимосвязь между обозначением VDDA и Uccphy.
То есть догадаться-то можно, но ведь наверное целесообразнее или в тексте СП сделать либо явную взаимосвязь между обозначениями (например "VDDA - Питание приемопередатчиков PHY (Uccphy)"), или вместо Uccphy в таблице писать VDDA.
Вариант писать VDDA кстати по-моему для таблицы 45 лучше подходит, т.к сразу понятна связь с конкретными выводами м/сх.

В общем такие вот нюансы найдены

_________________
"В радиотехнике, как в церкви - многое не понятно, но приходится верить"
ВлГУ. к.т.н Садовский Н.В

Здравствуйте!

Спасибо за замечания, 400мА на первой странице действительно пропустили при последней правке спецификации, хотя таблицу с электрическими параметрами приводили в соответствие с ТУ.
Исправим.

По первому вопросу - скажите, пожалуйста, почему Вы полагаете, что 1%? В ТУ все же 10%, а вот на рисунке 12, которого нет в ТУ - 1%.

В ТУ нет слова "суммарный" в таблице электрических параметров, поэтому в спецификации также.

По четвертому вопросу - заменить VDDA на Uccphy уже не получится, потому что во всей подписанной конструкторской документации эти выводы называются именно VDDA, но дописать в скобках в таблице описания выводов в спецификации можем. Зарегистрирую тикет.
Спасибо.

_________________
Отдел технической поддержки support@milandr.ru

1) EXRES это вроде как опорный резистор и например для 1986ВЕ1Т в ТСКЯ.431296.008CП Версия 2.22.0 от 10.04.2019 на странице 9, в таблице выводов даже специально написано "EXRES1 – Вывод для подключения опорного резистора 12,4 кОм 1% на VSS2A" и вот тут (ссылка) даже была небольшая дискуссия по этому поводу.
2) Насколько я понимаю, PHY в 1986ВЕ1 и 5600ВВ3Т одинаковый, поэтому скорее всего и в 5600ВВ3 не изобрели "фотонный двигатель".
3) Кстати на микросхемах с Ethernet других производителей тоже всегда есть опорный резистор с 1% точностью.

В общем понятно, что всё это косвенные доводы, поэтому и прошу проверить. Может быть как раз в ТУ ошибка? Уж прям сильно странно - у всех 1%, а здесь 10%, т.е даже не самые распространённые 5%, а именно 10. Это выглядит примерно как "Здесь поставьте какой-нибудь резистор". Странно просто.
У меня к сожалению дома нет ТУ, но там вроде бы написано в колонке справа "по выводам ............... суммарно" и перечислены как раз выводы и UCC и VDDA.

_________________
"В радиотехнике, как в церкви - многое не понятно, но приходится верить"
ВлГУ. к.т.н Садовский Н.В

Была и другая дискуссия о потребной точности этого резистора в случаях, когда Ethernet не используется. Так вот на сколько я помню, в том случае точность не требуется и подойдёт 10% "какой нибудь" резистор.
Другое дело, что 12,4 +/-10% выглядит немножечко не естественно. Для 10% допуска бывают номиналы 10 и 15.
Видимо стоит это оговорить особо в тексте.

_________________
сочувствующий…

Должно быть 12,4 ± 1% кОм. Документацию будем исправлять.

_________________
Отдел технической поддержки support@milandr.ru