AT91RM9200. Пропадают пакеты eth, при работающем gprs модуле на уарте Опции

[dmitry-rf]

Есть плата на AT91RM9200. По сути - переразведённый AT91RM9200-DK c phy RTL8201. К плате подключен gsm модуль Siemens MC75, установлен linux. Система работает нормально, pppd дозванивается до провайдера и устанавливает соединение.
Неприятность такая - как только ppp соединение установлено, начинают теряться eth пакеты между платой и компьютером (возможно, пакеты начинают теряться еще при открытии ком-порта и дозвоне). Убиваешь pppd - потери пропадают, все пинги проходят. Таблица роутов выглядит нормально.
Есть аналогичная чужая плата, на ней та же сборка линукса в тех же условиях работает без проблем. Таблицы маршрутизации после дозвона совпадают. Схема чужой платы неизвестна, но это тоже модифицированный кит AT91RM9200-DK.
В чём может быть ошибка? Нецжели уарт как-то может влиять на ethernet?

[aaarrr]

Нецжели уарт как-то может влиять на ethernet?

GSM может. И очень неслабо

[maxus]

GSM излучает до 1 - 1.5 ВТ в эфир, если антена близко от платы, то это может влиять на микрухи. Запусти на компе WireShark или tcpdump и посмотри что приходит от платы.

[dmitry-rf]

GSM вряд ли на что-то влияет. Антана от платы далеко, да и пакеты, кажется, начинают пропадать уже при открытии порта ppp демоном (но это пока не ясно на 100%). Система представляет собой пирожок: Сверху платка с армом (проц, память, флэш, физика, eth-транс), снизу - gms-модуль. Посередине основная плата с разъёмами и источником питания. Чужая плата - такой же арм-модуль, как и моя. Соответственно, находится в тех же условиях, но работает без сбоев.
Wireshark запускал - показывает то же, что и ping: запрос-ответ, запрос без ответа, запрос-ответ....
Прошивка используется одна и таже, а платы разные. Т.о. я склоняюсь к тому, что проблема аппаратная, но ума не приложу, чем она может быть вызвана.
+++
Запустил pppd не указав логин-пароль. Соответственно, соединение не устанавливается. Пакеты пропадают. Значит, дело именно в какой-то связи ком-порта и эзернета.

Сообщение отредактировал dmitry-rf - Dec 2 2008, 08:50

[aaarrr]

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

[maxus]

Есть такое с питанием. У меня GSM передатчик очень сильно просаживал питание в момент передачи.
А на счет связи COM-порта и ethernet - запусти ppp на другом порту, там где нет GSM-передатчика. Можно просто в холостую запустить или с компом связать. Узнаешь точно: это лажа от СОМ-порта или от GSM.

[dmitry-rf]

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

Сообщение отредактировал dmitry-rf - Dec 2 2008, 15:09

[dmitry-rf]

Рано радовался. Сложилась очень интересная ситуация.
Есть три чипа RTL8201BL из разных партий: 1-й работает без проблем, 2-й теряет 30-50% пакетов, 3-й при включении gsm лежит совсем.
Есть две платы - чужая и аналогичная ей наша разработка. Вышеупомянутые проблемы наблюдаются на нашей плате. На чужой 1 и 2 чипы работают стабильно. 3-й не пробовал да и без него ясно, что есть косяк в нашей плате. Но и чипы различаются.
В даташите подключение RTL8201BL подробно не описано. В частности, нет рекомендаций по подключению трансформатора. Есть у кого-нить работающая схема с этим чипом? Буду очень благодарен за схему.
Взаимосвязь уарта и eth проверяется...

[aaarrr]

Есть у кого-нить работающая схема с этим чипом? Буду очень благодарен за схему.

У Реалтека есть Reference Schematics.
 sch_8201bl_120_.zip ( 176.49 килобайт ) Кол-во скачиваний: 233

Взаимосвязь уарта и eth проверяется...

Не тратьте напрасно время.

[dch]

В даташите подключение RTL8201BL подробно не описано. В частности, нет рекомендаций по подключению трансформатора. Есть у кого-нить работающая схема с этим чипом? Буду очень благодарен за схему.
Взаимосвязь уарта и eth проверяется...

Почему у них сайте была схемка отладочной платы, она аналогична вот этой :
http://www.ucrouter.ru/download/evm9200-sch.pdf

у клиента была похожая проблемка он подключал по ком порту модуль gprsный но проблемма у него была
в том что на компортовый драйвер не поддерживал управление потоком и пакеты у него там терялись.
Он, точнее она ;-) как с модемными сигналами разобралось, все пришло в норму. Точно пакеты у Вас теряются на ethernete?

Сообщение отредактировал dch - Dec 11 2008, 19:39

[dmitry-rf]

У Реалтека есть Reference Schematics.

Спасибо. Нашёл 2 отличия:
- неправильно соединённые средние точки трансформаторов. Сделал как в референсе - потери упали до 8-9%
- нет конденсаторов на ногах питания. Возможно, это причина остальных потерь, хотя я не уверен. GSM-модуль и ARM-модуль питаются от одной линии 12 В, но через раздельные регуляторы на базе L5973. У каждого регулятора на выходе дроссель и конденсатор. Плата АРМа шестислойная, два слоя - 3.3 В и земля, что даёт большой конденсатор.

у клиента была похожая проблемка он подключал по ком порту модуль gprsный но проблемма у него была
в том что на компортовый драйвер не поддерживал управление потоком и пакеты у него там терялись.
Он, точнее она ;-) как с модемными сигналами разобралось, все пришло в норму. Точно пакеты у Вас теряются на ethernete?

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

Сообщение отредактировал dmitry-rf - Dec 12 2008, 14:12

[aaarrr]

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

Вообще нет?

Плата АРМа шестислойная, два слоя - 3.3 В и земля, что даёт большой конденсатор.

Большой конденсатор с очень маленькой емкостью.

[dmitry-rf]

Вообще нет?

На ногах питания физики нет ни одного. Пробовали повесить их при неправильном подключении средних точек транса - заметных изменений не было. Попробую поставить, но смоневаюсь, что это что-то даст.
AVDD и PWFBIN/PWFBOUT подключены согласно референсу.

[dch]

Пробовали повесить их при неправильном подключении средних точек транса - заметных изменений не было.

для RTL8201BL - на одной средней точке конденсатора быть не должно, а так должно работать особенных проблемм не заметно. А у Вас проблемы с ethernet-ом на 10 И 100 мбитах?

[dmitry-rf]

для RTL8201BL - на одной средней точке конденсатора быть не должно, а так должно работать особенных проблемм не заметно. А у Вас проблемы с ethernet-ом на 10 И 100 мбитах?

Сейчас конденсатор на землю есть только на средней точке RX. Проблемы только на 100 Мбит.

[dmitry-rf]

Падение потерь до 10% - случайность. Повторный прогон выдал опять 30-50%. Иногда падает до 6%.
Схема подключения совпадает с референсом и платой evm9200, если не считать светодиодов.

[dch]

Проблемы только на 100 Мбит.

и на полудуплексе и дуплексе и автоопределении ? На сетевой карточке со стороны хоста обычно нужно выставить автоопределение. Там бывает, скорость RTL8201BL может олределить а вот дуплекс нет и по умолчанию сваливается в определенный.

[dmitry-rf]

Потестил на симке другого оператора, с худшим приёмом. Пакеты теряются и на 10 Мбит. Видимо, сказывается повышение мощности передатчика...
Разницы при дуплексе/полудуплексе особой нет. Интересный момент - если пинговать с компа, пропадает 5-10%, если с роутера, то 40-60%.
Написал письмо в техподержку Realtek, но ответа нет.

[defunct]

Проблемы только на 100 Мбит.

Попробуйте воткнуть снаружи заглушку и запустить какой-нить packet injector, посмотрите статистику отправленных и принятых пакетов.
1. Если количество RX и TX пакетов совпадает - ищите проблему "снаружи" (транс, корд, свитч).
-Иначе, замкните между собой TX+ и RX+ до трансформатора, и снимите статистику еще раз.
2. совпадут - ищите проблему в HW между PHY и до "транса".
3. не совпадут - ищите проблему в HW между MK и PHY, если там все ОК остается только вариант с SW.

Разницы при дуплексе/полудуплексе особой нет.

Сорри если вопрос покажется тупым, но все же для чистоты:
бит autonegotiation при этом не забыли сбросить?

[RW9UAO]

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

[dmitry-rf]

Попробуйте воткнуть снаружи заглушку и запустить какой-нить packet injector, посмотрите статистику отправленных и принятых пакетов.
1. Если количество RX и TX пакетов совпадает - ищите проблему "снаружи" (транс, корд, свитч).
-Иначе, замкните между собой TX+ и RX+ до трансформатора, и снимите статистику еще раз.
2. совпадут - ищите проблему в HW между PHY и до "транса".
3. не совпадут - ищите проблему в HW между MK и PHY, если там все ОК остается только вариант с SW.
Сорри если вопрос покажется тупым, но все же для чистоты:
бит autonegotiation при этом не забыли сбросить?

А если на 10 Мбит тоже пропадают, инструкция актуальна?

Скорость и дуплекс меняю с помощью mii-diag. Она пишет, что autonegotiation сброшен при любом задании параметров вручную.

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

А какая цель приследуется?

[defunct]

А если на 10 Мбит тоже пропадают, инструкция актуальна?

Если % потерь практически не зависит от скорости, тогда, конечно, - актуальна.

К проблемам "только на 100M" у этого чипа - относится autoneg, PHY может рапортовать 100M/Full-duplex в autoneg режиме, но работать при этом в полудуплексе, и это может приводить к потерям.

[dmitry-rf]

Если % потерь практически не зависит от скорости, тогда, конечно, - актуальна.

К проблемам "только на 100M" у этого чипа - относится autoneg, PHY может рапортовать 100M/Full-duplex в autoneg режиме, но работать при этом в полудуплексе, и это может приводить к потерям.

Процент потерь зависит. На 100 теряется гораздо больше. Сейчас есть 2 платы с проводками, исправляющими ошибки разводки. Платки одинаковые, проводки одинаковые. Но на одной 10Мбит работает без потерь, а на другой 10-20% потерь пингов от компа к роутеру и 40-60% от роутера к компу. Обескураживает такая разница - пинги же ходят одним и тем же путём, значит и теряться должны в равной степени...

[RW9UAO]

а чтобы исключить влияние модема на цепи питания контроллера. и исключить наводки от антенны (ВЧ тракта) модема на контороллер.

[dmitry-rf]

Попробуйте воткнуть снаружи заглушку и запустить какой-нить packet injector, посмотрите статистику отправленных и принятых пакетов.

Сделал loopback провод, снял tcpdump-ом пинги в обе стороны и загнал их обратно c помощью bittwist:

Код

11:55:23.730483 IP 192.168.1.1 > 192.168.1.10: ICMP echo request, id 4884, seq 43, length 64
11:55:23.924575 IP 192.168.1.10 > 192.168.1.1: ICMP echo reply, id 4884, seq 43, length 64
11:55:24.100111 IP 192.168.1.10 > 192.168.1.1: ICMP echo request, id 41855, seq 11, length 64
11:55:24.395369 IP 192.168.1.1 > 192.168.1.10: ICMP echo reply, id 41855, seq 11, length 64
11:55:24.601119 IP 192.168.1.1 > 192.168.1.10: ICMP echo request, id 4884, seq 20, length 64
11:55:24.810409 IP 192.168.1.10 > 192.168.1.1: ICMP echo reply, id 4884, seq 20, length 64
11:55:24.958266 IP 192.168.1.10 > 192.168.1.1: ICMP echo request, id 41855, seq 12, length 64
11:55:25.227096 IP 192.168.1.1 > 192.168.1.10: ICMP echo reply, id 41855, seq 12, length 64

Вроде, потерь нет, но я нифига не понимаю, что именно происходит. Может, bittwist загоняет пинги уже с ответами в интерфейс...

[defunct]

Вроде, потерь нет, но я нифига не понимаю, что именно происходит.

Если тест проделан "чисто" (пакеты точно заворачивались через заглушку), и с учетом того, что со второй платой проблем нет, тогда полученный результат может говорить о нестыковке с внешним железом (переполюсовка, настандартный трансформатор с другим коэф. трансформации, обрыв средней точки и т.п.)..

Может, bittwist загоняет пинги уже с ответами в интерфейс...

Это легко проверить, сделайте заглушку с ответвлителем

Код

Device           PC
   TX---+------->RX
   TX----+------>RX
        ||
   RX---+|
   RX----+

подключите ответвлитель к RX PC, wireshark'ом увидите есть снаружи пакеты или нет.

[dmitry-rf]

Наконец-то нашли причину. Ножка RXCLK MAC'a совпадает с выводом DTR 1-го UART'a. Таким образом, как только открывался ком-порт, тактирование мака просаживалось до уровня 1.5-2 В. В тех случаях, когда выход phy был мощный, ему удавалось раскачать вывод... Решили проблему отключением сигнала DTR в Linux'e.

Всем большое спасибо за советы и помощь! Цифровой осциллограф рулит

[dmitry-rf]

TEK0002.JPG - осцилограмма выхода TXCLK физики. Амплитуда хорошая.
TEK0003.JPG - осцилограмма выхода RXCLK физики. Амплитуда в два раза меньше положенного.

Эскизы прикрепленных изображений

 

[dch]

Совсем забыл - тестик порта eherneta отдельностоящий - грузится по x модему во внутреннюю SRAM - отвечает на пинги:
http://www.ucrouter.ru/download/AT91RM9200-GnuEMAC.bin
http://www.ucrouter.ru/download/AT91RM9200-GnuEMAC.tgz
Если у Вас проблеммы исключительно с Ethernet-ом должно помочь. Из под linux
ping -f <IP адрес> - это отправка пингов с максимальной скоростью на которую способен линукс

[dmitry-rf]

Дмитрий, спасибо, пригодятся.