STM32 + switch KSZ8895 Опции

[cyrax0]

Здравствуйте!
Используем данную связку (см. сабж), объединяя таким образом контроллеры в общую сеть. Внутри них крутится программа, которая очень часто посылает сетевые UDP-пакеты (скажем, 200 пакетов в секунду). Все хорошо (почти), за исключением того, что через 1-10 часов работы один или более контроллеров из 10 прекращают обмен. При этом вызов udp_send возвращает ноль, т.е. с точки зрения ethernet-а контроллера все хорошо. Свич тоже живой: индикаторы портов мигают и производится пересылка бродкаст-пакетов, а также срабатывает прерывание свича по изменению link status (при подключении/отключении сетевого провода). Но реально программа и свич уже не общаются.

Дебаггер к этому времени уже сто раз отвалится, да и проблемный контроллер не угадать. Поэтому вопрос в том, куда копать?
Если запостил не туда, прошу направить в нужное направление

[scifi]

Для начала надо потыкать MII/RMII щупом осциллографа и определить, это МК не выдаёт кадры или свич их не пропускает.

[jcxz]

Дебаггер к этому времени уже сто раз отвалится, да и проблемный контроллер не угадать. Поэтому вопрос в том, куда копать?

Для отладки без дебаггера используют обычно отладочный вывод в UART к примеру.

[kolobok0]

... Поэтому вопрос в том, куда копать?...

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

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

[Golikov A.]

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

При этом поглядите в стеке функции отправки, были жалобы что большая часть аварийных ситуаций заткнута заглушками "все хорошо". Ковыряли что-то что идет с СТЭамими, вроде бы это был LwIP. Это я к тому что возвращаемый 0 от UDP - вовсе не означает что все хорошо, просто там все плохо, но на этом плохо стоит заглушка которая возвращает 0 код ошибки...

[doom13]

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

При этом поглядите в стеке функции отправки, были жалобы что большая часть аварийных ситуаций заткнута заглушками "все хорошо". Ковыряли что-то что идет с СТЭамими, вроде бы это был LwIP. Это я к тому что возвращаемый 0 от UDP - вовсе не означает что все хорошо, просто там все плохо, но на этом плохо стоит заглушка которая возвращает 0 код ошибки...

Что-то Вы тут явно напутали. Это про тот случай, когда процессор захлёбывался от приёма потока broadcast-ов?

[Golikov A.]

SM - да про бродкасты, ТС тоже что-то писал.


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

[cyrax0]

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

[Golikov A.]

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