Начал использовать W5500 в связке с STM32. Библиотека от WiZNET ioLibrary_Driver-master/ Все хорошо, создаю сокет, инициализирую устанавливаю в Listen, происходит соединение с клиентом (W5500 в режиме сервер). Данные принимаю и отправляю и по опросу и по прерыванию (на линии INTn). Все работает, до определенного момента. А именно контроллер W5500 рвет сессию с возвратом байта состояния Sn_SR = 0x64 открытого сокета. А такого состояния нет даже в datasheets!!! После этого я спокойно снова устанавливаю в режим listen и он снова принимает соединение и снова прекрасно работает. Сейчас я решил эту проблему на стороне клиента, проверяю connect и если разрыв, то поднимаю соединение снова. Но это не правильно.

Если, кто сталкивался или есть мысли, прошу подсказать или направить в нужное русло. Убил уже два дня.

Причем время непредсказуемо, от 2 мин до 2 часа, при этом обмен пакетами идет с интервалом через 5 сек и длиною 10-20 байт.

Да работаю на скорости по SPI=18. Работаю в FreeRTOS, менял размер стека для задач, ничего не меняется. Использовал разные версии FreeRTOS - ничего. Да, чип в экспериментах один, есть конечно и другие, но пока боюсь распаивать если не пойму причину.

Я думаю, что это глюки поддельных чипов. Модуль W5500 наверное на Али покупали, такой синенького цвета рублей за двести с доставкой. .У меня тоже были проблемы с подобными модулями - периодически обнулялись сетевые настройки. Пришлось ставить костыль на проверку обнуления. Я долго бился с этой проблемой, все думал, что я что-то делаю не так. Но если запустить тот же код на фирменной плате, которая правда и стоит как чугунный мост, то проблема исчезала. Так что с большой долей вероятности ваша проблема - это доплата за низкую начальную стоимость модуля.
P.S. Не заметил сразу - у вас не модуль, а чип. Но это сути дела не меняет.

В общем проблема решилась, но дело было не в чипе. Если честно не понял в чем, но решение такое - отказался от FREE RTOS и написал свой диспетчер задач, благо не так много их. Чип покупался в Промэлектронике: 200 руб./шт. терпимо. 0х64 скорее всего вытаскивался из стека, хотя я до безобразия увеличивал стек и кучу. Не знаю в чем было дело. Работает более 24ч без сбоев и разрывов, передергивал шнурок - бодро подхватывает и восстанавливает соединение. Посмотрим. Возможно чуть позже покопаю библиотеку, но не сейчас.

А сетевые настройки все обнулялись или какие-то отдельные? Вы именно из регистров читали или смотрели в структуре?

Я тоже использую w5500. Покупал на Али за 250 рублей... Никаких проблем нет ! Гоняю сутками... Качаю гигабайты файлов))

Sn_SR - регистр статуса.

Sn_SR =
0x14-LISTEN, 0x16-SYN, 0x17-ESTABLISHED, 0x11-DISCON, 0x1C-CLOSE_WAIT, 0x18-FIN_WAIT, 0x00-FIN/ACK.

Я смотрю только Sn_SR =
0x14-LISTEN, 0x17-ESTABLISHED, 0x18-FIN_WAIT, 0x00-FIN/ACK.


Sn_SR = 0x64 - это глю какой-то)) W5500 не понял команды и завис... )) Короче это глюк библиотеки... полюбому))

У меня такого ещё не было)) Просто я не использую никаких библиотек... вот и всё))

P.S.
А потом я перешёл на UDP... Повысилась скорость передачи... И все проблемы с TCP отпали сами собой))

Не понял команды так же не соответствует моему случаю, т.к. я продолжал читать регистр в бесконечном цикле и ответ был 0х64.
Я не писал, что контроллер завис. Он продолжал нормально работать. Ни один регистр своих значений не терял и не изменял.
В целом проблема решена, но не имеет ответа причины такого поведения.

И насчет UDP, в моем случае неприемлемо т.к. требуется гарантированная доставка пакета. Скорость не важна, размер пакетов не более 100 байт, интервал обмена на более 200 мсек. Так, что TCP!

Ну бывало из-за плохого контакта или нестабильного питания у меня W5500 выдавал "мусор"... При этом W5500 продолжал принимать и отправлять пакеты...
Для этого у меня есть RESET ))

А UDP проще... быстрей... надёжней... ))
За гарантированную доставку пакетов у меня отвечает МК.
Если с первого раза пакет не прошёл, то МК повторит передачу... UDP... > UDP... > UDP... > UDP... > UDP... > UDP... >
И так хоть до посинения)) Пока пакет по дойдёт.)) Тем более всего 100 байт.))

Разобрался в чем была проблема!!!

Возможно кому-то пригодится.

Задачи во FREE RTOS - асинхронны и получалось так, что двум разным задачам нужно было получать данные с w5500! Первая задача отправляла запрос, происходило прерывание и передача управления второй задаче. Вторая задача отправляла свой запрос, но получала данные, которые были предназначены первой задаче. Эти данные, разумеется, были не корректны для второй задачи.

Мое решение: вытащил в отдельную задачу получение состояний с приоритетом Normal. Получаю состояния, в этой задаче 3 раза с интервалом 10 мсек, если все три раза совпали значения - значит истинные, если нет - просто не меняю и в паузу на 50 мсек. Можно было конечно сделать высокий приоритет и/или запрещать все задачи до получения состояний, но пока такое решение работает.

Если у кого-то есть идеи лучше, готов рассмотреть и прислушаться.