Блог

Я столкнулся с очень странной проблемой, пытаясь запустить CodeSys на 4 ГБ RasPi-4. Короче говоря, Pi работает нормально вплоть до тех пор, пока я не начну запускать проект CodeSys. Когда я это делаю, в течение 60 секунд eth0 падает и не может быть восстановлен. Даже перезагрузка Pi не имеет никакого эффекта. Единственный способ, который я нашел для восстановления eth0, — это перезаписать RasPiOS из исходного изображения с Raspberrypi.org (что я проделал около 30 раз за последние несколько дней, пытаясь методом проб и ошибок выпутаться из этой ситуации).

 Linux raspberrypi 5.4.79-v7l  #1373 SMP Mon Nov 23 13:27:40 GMT 2020 armv7l GNU/Linux
 

Я установил eth0 на статический IP-адрес, используя /etc/dhcpcd.conf. Что бы ни вызывало эту проблему, оно не изменяет мои настройки там. Попытки использовать ifconfig eth0 вверх / вниз не имеют никакого эффекта — ни ошибок, ни отзывов, просто ничего. Проверка состояния eth0 показывает «ожидание оператора», несмотря на то, что он подключен к активному коммутатору (я также заменил все кабели и коммутатор, чтобы устранить их как источник проблемы).

Когда я повторно записываю Pi и устанавливаю CodeSys, eth0 остается включенным на неопределенный срок (24 часа в моем самом длинном тесте). Это запуск проекта CodeSys, который убивает eth0. Перезагрузка после того, как etho «умирает», выдает серию сообщений bcmgenet, которые, по-видимому, связаны:

 pi@raspberrypi:~ $ dmesg | grep bcmg
[    1.033665] bcmgenet fd580000.ethernet: failed to get enet clock
[    1.033685] bcmgenet fd580000.ethernet: GENET 5.0 EPHY: 0x0000
[    1.033709] bcmgenet fd580000.ethernet: failed to get enet-wol clock
[    1.033730] bcmgenet fd580000.ethernet: failed to get enet-eee clock
[    1.044648] libphy: bcmgenet MII bus: probed
[    9.528502] bcmgenet fd580000.ethernet: configuring instance for external RGMII
[    9.535175] bcmgenet fd580000.ethernet eth0: Link is Down
 

Я также попытался создать новый проект CodeSys с нуля, в котором не были установлены драйверы eth0 (ModBus, Ethernet / IP), только драйвер GPIO. Это тоже не помогло — eth0 умирает в течение 60 секунд.

Самое странное, что, похоже, затронуто только eth0. Контакты GPIO продолжают переключаться, как это контролируется проектом CodeSys (у меня запущена простая программа с мигающим светодиодом), и я все еще могу подключиться к Pi по SSH с помощью Wi-Fi. Но поскольку моей основной причиной настройки этого Pi является использование Ethernet / IP и ModBus….

Этот поток: на GitHub — единственное место, где я нашел кого-либо, описывающего что-то похожее на то, что я испытываю, но в этом случае CodeSys не установлен. Я попытался добавить genet.skip_umac_reset=n в мой cmdline.txt как было предложено в теме, но это не возымело никакого эффекта.

Итак, оказалось, что это была проблема с настройкой выводов GPIO.

CodeSys имеет два разных файла «device» для добавления выводов GPIO в дерево устройств проекта. Выбор по умолчанию предназначен для более старых моделей Pi, а альтернативный выбор (обозначенный только для B и Pi2) является правильным для Pi4.

Как оказалось, устаревший файл устройства GPIO будет работать в основном на Pi4. Но использование неправильного файла устройства позволяет CodeSys пытаться настроить контакты GPIO, которые не должны быть изменены. В данном случае GPIO 28 и 29. Установка любого из них в режим вывода убила eth0.

Использование правильного файла устройства удаляет 28 и 29 из списка настраиваемых выводов GPIO. Это также дает правильный список доступных выводов GPIO для более новых моделей Pi, надеюсь, избегая других потенциальных проблем с конфигурацией, о которых я не споткнулся.

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