Миландр

На странице 46 спецификации версии 2.10.0 в блок-схеме приёма блок условия должен быть "RDY=1?", а блок присвоения - "Установить DSCR.CTRL.RDY=1".

_________________
Hack the Planet!

При внимательном рассмотрении документации на 5600ВГ1У обнаружились следующие
косяки в документации (Версия 2.10.0 от 21.01.2016).

1. Таблица 14 – Описание бит регистра INT_MSK/ INT_SRC
Сразу за битом 7 идет бит 9. Куда делся бит 8? Reserved?

2. Таблица 15 – Описание бит регистра PHY_CTRL
Сразу за битом 13 идет бит 15. Что стало с битом 14?

3. Таблица 18 - Биты словосостояния дескриптора ПРМ
Написано:
RDY - индикатор состояния исходящего пакета
Должно быть:
RDY - индикатор состояния приема пакета

Написано:
IRQ_EN - разрешение формирования прерывания по передаче
Должно быть:
IRQ_EN - разрешение формирования прерывания по приему

4. Описание бит регистра GCTRL
В описании сказано, что биты [11..0] зарезервированы, однако после
сброса их значение не равно нулю. Должен ли я сохранять то, что там
после сброса, или могу занулить?

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

И по мелочи:

5. Рисунок 2 – Структурная блок-схема
На схеме обозначен входной сигнал CLKOUT, который более нигде не фигурирует.
Сигналы IRQ и RST не обозначены.

6. 4.1 Технические характеристики
Написано - "средой передачи сигнала в ЛВС является витая пара"

Таблица 15 – Описание бит регистра PHY_CTRL
Написано:
BASE_2
1 – подключение по коаксиальному кабелю;
0 – подключение по витой паре

Коаксиальный кабель может или не может являться средой передачи?

7. 5.3.2 Настройка работы в полудуплексном режиме
Написано - "В этом режиме осуществляется контроль занятости линии (CRS) и
коллизий (COL) не осуществляется."
Последние два слова лишние.

8. Все страницы начиная с четвертой начинаются словами -
"Спецификация 5600ВГ1У, К5600ВГ1У, К5600ВГ1У"
Должно быть:
"Спецификация 5600ВГ1У, К5600ВГ1У, К5600ВГ1УК"

9. 5.5 Прием пакетов
Написано:
"По завершении передачи контроллер переходит ..."
Должно быть:
"По завершении приема контроллер переходит ..."

Не подскажите, как бы этой микросхеме (ну и не только этой) лучше делать ресет по включению?
Существуют отечественные решения?

Конкретно этой - с помощью бита GLBL_RST и вывода nRST. По аппаратным решениям быстрый гуглеж выдает отечественный супервизор К1114ЕП1

В наших микросхемах есть схемы POR (power on reset) - которые обеспечивают корректную первоначальный сброс схемы при включении питания (если противное не описано в errata).
Так что по большому счету дополнительных супервизоров не требуется. Если же нужно сбросить микросхему из-вне - то для этого есть выводы внешнего сброса. Простейший способ сбросить через внешний вывод - это поставить RC задержку от питания на этом выводе.

Спасибо за ответы.

Здравствуйте!
При использовании модуля Ethernet на отладочной плате вместе с 1986ВЕ91Т по параллельному интерфейсу возникла следующая проблема:
Если ножку микроконтроллера, подключенную к входу nRST не настраивать на выход, то на nRST можно наблюдать 5В уровень. При этом всё работает хорошо.

Если эту ножку настроить как выход, но на nRST висит 3,3В. При этом наблюдается следующее:
Пока с шины данных считываются значения, где мало единичек (напр. 0х0005, 0х0505 и пр.) то всё работает.
Считывание же значения 0xFFFF или 0xFFFE приводит к сбросу 5600ВГ1У. При этом, осциллограф, подключенный к выводу nRST провалов не фиксирует. По спецификации напряжение лог. нуля на этом входе 0,8В.

Подскажите, какие могут быть причины такого поведения 5600ВГ1У?
Какая минимальная длительность сигнала сброса nRST приведет к фактическому сбросу?

переделал драйвер этой карты для работы с freeRTOS
с контроллером 1986ВЕ3
добавил прерывания по приему и посылку семафора
из IRQ в ожидающую задачу приема.
ранее было так-запускалась задача и
она в бесконечном цикле следила за линком
и готовностью дескрипторов
время от времени все это отваливалось, по всей вероятности
тогда, когда в програме при чтении не переиниализировал
дескриптор приема.
сейчас работает внешняя память + внешний ethernet на параллельной шине
получает адрес по DHCP,
сделана настройка внешней шины и прочеее
можно использовать как образец.
для IAR 6 или IAR 7

во вложение - изменить частоту CPU до 40 МГц
в файле periph/clock поставить
RST_CLK_CPU_PLLconfig(RST_CLK_CPU_PLLsrcHSEdiv1, RST_CLK_CPU_PLLmul5);
внеший eth тогда работает без сбоя

исправил драйвер 5600 во FreeRTOS
1) поменял семафор с бинарного на счетный, как это сделано, например, у STM
потери пакетов исчезли
2) "мотание" дескрипторами сделал в одном месте
отладочные сбросы eth5_clr_tx() и eth5_clr_tx() можно убрать

обнаружил такую ошибку-микросхема 5600
не хочет слать через 0-й дескриптор (следующий после wrap)
то есть когда 0 дескриптор на отправку,
все правильно заполняется
но физически данные не отправляются
причем та же самая прошивка иногда работает часами без потерь
а на след. день 3.3% ошибок (если 32 дескриптора)
пока грешу на микросхему.
сделал "заплатку" для обхода
то есть в 0-й дескриптор пишу мусор а данные пишу в следующий.

Здравствуйте, форумчане.

Нужна помощь в диагностике отправки данных от 5600ВГ1У на комп. Все более-менее работает, но некоторые пинги бьются или не доходят и ARP-ответы от моего устройства приходят с битой FCS Ethernet-пакета.
Топология связей: 1986ВЕ92У <--SPI--> 5600ВГ1У <-- Ethernet 10BASET --> ПК (Debian 9 (ядро 4.9.0), сетевуха какая-то Intel gigabit с драйвером e1000e)
Конфигурация 5600ВГ1У: GCTRL = 0x4382; MAC_CTRL = 0x0200; MinFrame = 0x0040; CollConfig = 0; IPGTx =0x000A; PHY_CTRL = 0x31D0;

Для диагностики приема и отправки провёл такой эксперимент: MAC_CTRL установил равным 0, на ПК в ARP-таблице статически привязал IP к MAC-у моего устройства и запустил пинг на заданное кол-во пакетов (что-то около 200 шт.). По окончании пинга проверил счетчики принятых и отправленных пакетов - как внутренних в прошивке моего устройства, так и регистров STAT_RX_ALL, STAT_RX_OK, STAT_RX_OVF, STAT_RX_LOST, STAT_TX_ALL, STAT_TX_OK в 5600ВГ1У. В результате "кол-во отправленных пакетов с ПК"=STAT_RX_ALL=STAT_RX_OK="счетчик принятых пакетов в прошивке"="счетчик отправленных пакетов в прошивке"=STAT_TX_ALL=STAT_TX_OK; STAT_RX_OVF=STAT_RX_LOST=0. Но на ПК по данным ping вернулось на несколько пакетов меньше (именно вообще не дошли, т.е. битые, но все-таки дошедшие, считаются дошедшими). Из этого я сделал вывод, что прием пакетов на моем устройстве работает исправно.

Далее решил посмотреть, что же все-таки приходит на ПК - мусор вместо потерянных пакетов или вообще ничего. Вернул MAC_CTRL назад, снес статическую привязку IP к MAC-у. Провел несколько экспериментов с захватом пакетов tcpdump-ом при различных настройках rx-fcs и rx-all сетевухи на ПК и последующим анализом в Wireshark. Между экспериментами мое устройство сбрасывалось путем полного отключения питания. Результаты работы в файлах в приложении.
Собственно, из этих экспериметов получились следующие выводы:
1. Ошибки одни и те же и ситуация повторяется все четыре раза. Т.е. аналоговая часть и SPI на уровне сигналов скорее всего работают корректно.
2. Поскольку FCS вычисляется в 5600ВГ1У, и в некоторых пакетах она не совпадает с переданным содержимым (см. дампы с rx-fcs=off), то скорее всего проблемы внутри неё.
3. Настройка rx-fcs=on на ПК заставляет сетевуху добавлять в конец Ethernet-фрэйма вычисленную ей самой FCS по принятым данным (т.е. FCS всегда будет совпадать с содержимым пакета), хотя я ожидал более честного поведения, т.е. увидеть не вычисленный, а принятый FCS. При этом при установке rx-fcs=off FCS можно увидеть только у ARP-ответов моего устройства. Для пингов она обрезается.
4. Просто наблюдение: несмотря на то, что 5600ВГ1У настроена на Full duplex, на ПК сетевуха работает в Half duplex. Попытка переключить её с помощью ethtool принудительно в Full duplex приводит к исчезновению линка на уровне PHY. Переключение назад в Half duplex восстанавливает линк. Такая же ситуация и с другой сетевухой на базе rtl8169.

Собственно, вопрос: куда копать дальше? У меня пока только два варианта:
1. Провести при инициализации 5600ВГ1У проверку её памяти.
2. Попробовать заменить 5600ВГ1У на другой экземпляр.
В общем оба варианта сводятся к тому, что проблема в самой микросхеме, но это как-то не вяжется с тем, что эти микросхемы имеют военную приемку, т.е. с качеством там на мой взгляд все должно быть в норме. Или это всего лишь мои иллюзии по поводу качества ВП и там тоже могут быть битые м/с?

Вроде бы разобрался со своим вопросом. Вот мои выводы - мало ли кому пригодится:
1. rx-fcs действительно работает так, как нужно. Т.е. на ПК при включенном rx-fcs я получал контрольную сумму, которая пришла по проводу, а не вычисленную сетевухой в процессе приема пакета;
2. При выключенном rx-fcs контрольная сумма присутствует в ARP-ответах от моего устройства потому, что при приеме пакета в прошивке м/к я передавал в LwIP весь пакет с контрольной суммой. LwIP, в свою очередь, при формировании ARP-ответа просто модифицирует буфер с принятым пакетом в некоторых местах. Т.о. при выключенном rx-fcs в ARP-ответах остается FCS от ARP-запроса, посланного с ПК. При включенном rx-fcs оставшаяся FCS от запроса перезаписывается на принятую FCS;
3. Собственно, основные причины битых пакетов - это ошибка записи в буфер отправки при переходе с конца буфера в начало (т.е. баг в моем коде) плюс нестабильный источник питания, от которого я временно питал схему (стабилизатор в схеме есть, но пока не запаян).

Вобщем, вылечилось все исправлением бага в прошивке, использованием стабильного БП и отрезанием от пакета контрольной суммы перед его передачей в LwIP.

А с этим не разбирались?
Наблюдал такое в 2015м viewtopic.php?f=6&t=126&start=150#p14725
Оставили в полудуплексе в итоге. Но разобраться бы хотелось)

Замечания по документу "Спецификация 5600ВГ1У, К5600ВГ1У, К5600ВГ1У".

1) Стр. 12, п 4.6 "Дескрипторы":
"LEN: длина пакета"; длина пакета в байтах или 16 разрядных словах?

2) Стр. 47, "Таблица 19 - биты словосостояния дескриптора ПРМ":
"RDY: 1 - готов к приему пакета; 0 - пакет принят/не готов".
НО на стр. 48 в блок схеме ПРИЕМА нарисован цикл "читать DSCR.CTRL пока RDY=0 ".

Верно ли то, что я должен установить RDY=1, чтобы обозначить готовность к приему,
а контроллер 5600ВГ1 сбросит этот бит после приема ethernet кадра?

3) Стр. 66 "Фильтрация по HASH таблице":
опечатка
N.hash = CRC.inv[31:26] = (101001b) = 0x19 = 41.
должно быть
N.hash = CRC.inv[31:26] = (101001b) = 0x29 = 41.