STM32F107 и DP83848: пропадает Ethernet Опции

[loltrol]

Есть устройство на STM32F107 и физ. драйвере DP83848. Работает на PowerPac RTOS (full, не evaluation) из-под IAR 6.2.
Периодически отмирает Ethernet. Вначале падал чётко через 15 минут, грешили на какие-либо программные глюки. Однако впоследствии стал умирать совершенно случайно и внезапно. Может проработать 2 минуты, а может и 2 часа. Иногда встречаются периоды просветления и работает часов по 12.
Одновременно вертится несколько задач, но пробовали запускать лишь одну.
Когда Ethernet работал по 15 минут пробовали останавливать программу дебаггером - после продолжения всё равно работал те же 15 минут и умирал.
Ethernet умирает даже если прибор не подключён к ЛВС (т.е. запускаем, ждём минут 20-30 и подключаем сеть - ноль эмоций).
Какие могут быть подводные камни? Рука уже тянется к топору :-(

[Aner]

Именно эта связка у меня работает стабильно много лет в серийных устройствох -> STM32F107 и физ. драйвер DP83848. Ничего не подает, ройте.
Проверять начинайте с кварца, его качество, точность. Затем вопрос чем тактируете DP83848? Если вторым PLL от проца, то кварц желателен +/-20ppm.
Какой кварц у проца и как получаете частоты в первом PLL? (PowerPac RTOS full из-под IAR 5.8 ... 6.2 +) Ну и смотрим что с дма и тд. Проверте аппататную проблему также.

[A. Fig Lee]

Ета же связка если не имзменяет память и в STM3210C-EVAL. Так что ищите грабли.

[loltrol]

PLL3 тактируется кварцем (25МГц) и дает на выходе 50 МГц.
PLL2 тактируется кварцем (25 МГц), на выходе - 40 МГц.
PLL1 тактируется от PLL2/5 = 8 МГц, на выходе 72 МГц.
DP83848 тактируем PLL3. Правда, точность вряд ли лучше 50 ppm, однако грели феном схему что бы вызвать сбой - сбоя не случалось.
Нужно ли ставить терминальные резисторы на сигнальные линии от проца к драйверу? Грешим на отражения, а от физдрайвера к трансу они стоят (49.9 Ом).

[Aner]

С плл все вроде так, смотрите дебагером что с прерываниями в дма. И еще вопрос, есть ли разница если коннект по езернету на 10 и 100?
Если разница есть проверяйте джиттер, откуда он берётся. Еще можно пробовать запитать DP83848 от отдельного кварца, тех же 25 мег, или от внешнего генератора 50 мег. И понять на чьей стороне проблема.

Еще можно проверить какие у вас ревизии чипов и порыть ераты, может у вас что из первых выпусков чипов и там бяки.

49.9 Ом обязательно 100%, и желательно 1%. Никаких там 47, 51 иначе будет плавать и скорость падать, будут ошибки. И если "провода" проводники на плате длинные то и разводить как диф пару! со строгим выдержанном волновым, примеров хоть отбавляй.

Что еще за терминальные резисторы на сигнальные линии от проца к драйверу? От проца к драйверу все строго по аенам, даташиту.

[loltrol]

Разницу 10 и 100 не проверяли, в эрратах ничего нет.
Терминальные резисторы - на STM3210C-EVAL, которую привёл A. Fig Lee, между процом и физдрайвером стоят согласующие резисторы 33 Ом. У нас таких нет.
Aner, а вы используете PowerPac'овский модуль Ethernet? Мы явно не используем DMA; только указали выходы проца, всё остальное делает PowerPac TCPIP.
И ещё: мы используем RMII (не хватило ножек). У вас также или MII?

Сообщение отредактировал loltrol - Jan 19 2015, 07:24

[Aner]

Разницу 10 и 100 так проверьте! Согласующие резисторы 33 Ом не обязательны (у нас тоже их нет), они нужны для низких питаний согласовать уровни, проблем с фронтами, то чего давно на этих связках не наблюдается.

Дма нужно контролировать через него все идет. Или смотрите кто дёргает ваш третий плл, если там джиттер. Потом использую Lwip, уходите от того начального PowerPac TCPIP или сами его доковыривайте. Проект не один, есть проект cо STM32F107RCT6 также RMII, из-за малого корпуса и пинов. Но проверяли и с MII, разницы не нашли.

[loltrol]

Спасибо за помощь!
Пока обнаружили другую проблему: из-за избыточной длины проводника данные с физ. драйвера приходят на проц с запаздывающим (на пол-такта) тактированием. Возможно, причина в этом. Будем переразводить плату, по результатам постараюсь отписать.

[Aner]

Спасибо за помощь!
Пока обнаружили другую проблему: из-за избыточной длины проводника данные с физ. драйвера приходят на проц с запаздывающим (на пол-такта) тактированием. Возможно, причина в этом. Будем переразводить плату, по результатам постараюсь отписать.

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

[Jury093]

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

попробуйте затактировать от внешнего генератора на 50МГц
гугление выводит на темы, типа:
http://electronix.ru/forum/lofiversion/ind...hp/t108846.html
http://forum.easyelectronics.ru/viewtopic....999&start=0
с упоминанием еррат и советов с генератором..
переразвестись всегда успеете..

ps посмотрите в даташите, может есть упоминания для управления сдвигом такта для данных (кажись у микрела была такая фишка) для rmii

[A. Fig Lee]

Разницу 10 и 100 так проверьте! Согласующие резисторы 33 Ом не обязательны (у нас тоже их нет), они нужны для низких питаний согласовать уровни, проблем с фронтами, то чего давно на этих связках не наблюдается.

"У нас тоже их нет" не показатель. Я вон модуль MRF24J40MA пользовал - не работает. И гдето в дебрях интернета нашел, что ктото поставил 120 Ом в цепь даты.
И о! С ним заработало. А многим они оказались не нужны..

[loltrol]

Опишу ситуацию, чтобы другие не попадались: RMII интерфейс связи пришлось использовать по скудости пинов, но внимательно изучить разницу было недосуг - в итоге из виду ушло что тактирование приема данных от физдрайвера процом осущетсвляется самим процом (от сигнала пина MCO на пин ETH_RMII_REF_CLK) и естественно по оч короткому пути (15 мм). Тот же клок идет до физдравера по дорожке примерно 80-90 мм и на двухлучевом осциле замеряется задержка в 5-6 нс. Ну а дальше простая арифметика - задержка данных на пинах физдрайвера до 14 нс (по даташиту), плюс ход данных до проца до 5-6 нс (по замеру) - и имеем что может быть ситуация считывания процом данных которых еще нет (считывание данных идет вторым тактом - т.е. чз 20 нс а валидные данные могут появится чз 25 нс). Что, в пинципе, мы и имеем: плавающий эффект - то работает 2-3 дня, то дохнет чз 10-15 минут после включения - не отлипает, видимо, по особенностям софта (PP IAR). Наблюдая осцилом зависший Ethernet, видно что данные от физдрайвера идут абсолютно адекватные, а проц просто их игнорит. А если еще и плата плохо помыта и флюс под процом - эффект падежа гаратирован ((

[Aner]

C PP давно ушел на Lwip, чего и вам советую. РР ну очень сырая была тогда, незнаю как сейчас.

[loltrol]

C PP давно ушел на Lwip, чего и вам советую. РР ну очень сырая была тогда, незнаю как сейчас.

100500 и была и есть сырая. Иногда стоит мегаусилий заставить их код работать, что USB-bulk, что WEB-сервер - оч крупный рашпиль применяется )) особенно при полном отсутствии исходников. Выбор PP щел от компилятора, честно Lwip просто не попался под руку, спс за наводку.