athlon64 0 17 мая, 2011 Опубликовано 17 мая, 2011 (изменено) · Жалоба Контроллер SAM7X512. Стек uIp был взят из атмеловского примера веб сервера и скорректирован id под мой PHY KSZ8001. Веб сервер прекрасно работает. После некоторого времени работы заметил что контроллер перестаёт отвечать на ethernet-пакеты, пинг не идёт, веб-интерфейс не открывается. После сброса (контроллера и PHY) всё нормализуется. Сам контроллер при этом не зависает, микросхема PHY продолжает мигать светодиодом Link/Act как и при нормальной работе. Такое проявляется довольно редко, последний раз контроллер проработал нормально 4 суток. Контроллер включен в корпоративную сеть. В каком направлении копать? Изменено 17 мая, 2011 пользователем athlon64 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
athlon64 0 18 мая, 2011 Опубликовано 18 мая, 2011 · Жалоба Выловил выдачу сообщения об ошибке. Контроллер когда перестаёт отвечать в EMAC_Poll выдаёт сообщение "size req 1488 size allocated 1066" Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
xvr 12 18 мая, 2011 Опубликовано 18 мая, 2011 · Жалоба Сам контроллер при этом не зависает, микросхема PHY продолжает мигать светодиодом Link/Act как и при нормальной работе.Это ни о чем не говорит - PHY будет моргать светодиодами даже если его вообще от контролера отключить :) Контроллер когда перестаёт отвечать в EMAC_Poll выдаёт сообщение "size req 1488 size allocated 1066" Судя по сообщению у вас в контролере кончился heap. Ищите утечки памяти в своей программе (или в uIp стеке) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
athlon64 0 18 мая, 2011 Опубликовано 18 мая, 2011 · Жалоба Это ни о чем не говорит - PHY будет моргать светодиодами даже если его вообще от контролера отключить :) Судя по сообщению у вас в контролере кончился heap. Ищите утечки памяти в своей программе (или в uIp стеке) Не похоже что дело в нехватке heap, стек его не использует насколько я понимаю, по крайней мере я не нашёл. В моей программе heap не утекает, остальные задачи, использующие heap после вываливания ошибки работают прекрасно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
xvr 12 18 мая, 2011 Опубликовано 18 мая, 2011 · Жалоба Не похоже что дело в нехватке heap,Судя по тексту ошибки (уверен на 99%) - ругался malloc. Его попросили выделить 1488 байтов, а в наличии оказалось максимум 1066 остальные задачи, использующие heap после вываливания ошибки работают прекрасно.Видимо остальным задачам оставшихся 1066 байтов хватило Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
athlon64 0 19 мая, 2011 Опубликовано 19 мая, 2011 · Жалоба Судя по тексту ошибки (уверен на 99%) - ругался malloc. Его попросили выделить 1488 байтов, а в наличии оказалось максимум 1066 Видимо остальным задачам оставшихся 1066 байтов хватило 1066 это константа UIP_CONF_BUFFER_SIZE в файле uip-conf.h. Пробовал её уменьшать до 256 и задачи спокойно находили более 256 байт динамической памяти с помощью malloc. А сообщение выводит вот этот кусок функции EMAC_Poll: if ((pRxTd->status & EMAC_RX_EOF_BIT) == EMAC_RX_EOF_BIT) { // Frame size from the EMAC *pRcvSize = (pRxTd->status & EMAC_LENGTH_FRAME); // Application frame buffer is too small all data have not been copied if (tmpFrameSize < *pRcvSize) { COM0_fprint("size req %d size allocated %d\n\r", *pRcvSize, frameSize); return EMAC_RX_FRAME_SIZE_TOO_SMALL; } // All data have been copied in the application frame buffer => release TD while (rxTd.idx != tmpIdx) { pRxTd = rxTd.td + rxTd.idx; pRxTd->addr &= ~(EMAC_RX_OWNERSHIP_BIT); CIRC_INC(rxTd.idx, RX_BUFFERS); } попробовал добавить сброс статуса (pRxTd->status = 0;), так хотя бы обмен ethernat-пакетами возобновляется, но какое то некрасивое решение Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
xvr 12 19 мая, 2011 Опубликовано 19 мая, 2011 · Жалоба Ага, значит попал в оставшийся 1% - это не malloc :) К вас по Ethernet пришел слишком большой пакет - не влез в приемный буфер :( Увеличьте UIP_CONF_BUFFER_SIZE до 1488 (если в RAM влезет), а лучше до 1500 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
athlon64 0 19 мая, 2011 Опубликовано 19 мая, 2011 · Жалоба Ага, значит попал в оставшийся 1% - это не malloc :) К вас по Ethernet пришел слишком большой пакет - не влез в приемный буфер :( Увеличьте UIP_CONF_BUFFER_SIZE до 1488 (если в RAM влезет), а лучше до 1500 Это самое первое что я попробовал, вылезло сообщение о попытке поместить пакет размером 1541 в буфер 1500 :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
xvr 12 19 мая, 2011 Опубликовано 19 мая, 2011 · Жалоба Это самое первое что я попробовал, вылезло сообщение о попытке поместить пакет размером 1541 в буфер 1500 :) А вот это уже странно - максимальный размер Ethernet пакета (со всеми заголовками и пр) всего 1518 байтов. Так что 1541 имеет право быть проигнорированным :laughing: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Nemod 0 1 июня, 2012 Опубликовано 1 июня, 2012 · Жалоба Контроллер SAM7X512. Стек uIp был взят из атмеловского примера веб сервера и скорректирован id под мой PHY KSZ8001. Веб сервер прекрасно работает. После некоторого времени работы заметил что контроллер перестаёт отвечать на ethernet-пакеты, пинг не идёт, веб-интерфейс не открывается. После сброса (контроллера и PHY) всё нормализуется. Сам контроллер при этом не зависает, микросхема PHY продолжает мигать светодиодом Link/Act как и при нормальной работе. Такое проявляется довольно редко, последний раз контроллер проработал нормально 4 суток. Контроллер включен в корпоративную сеть. В каком направлении копать? Смотрите бит AT91C_EMAC_BNA, если такое случилось лучше очистить весь приемный буфер (я обычно просто выкачиваю все пакеты оттуда, recieve пока есть пакеты буфере) и сбросить этот бит AT91C_BASE_EMAC->EMAC_RSR |= AT91C_EMAC_BNA; Остальные приемы которые раньше я делал типа переинициализации периферии не помогали. Вообще в сетях где много мусора (смотрите снифером wireshark), забивается буфер 16-32 кб довольно быстро (2-4 мс при трафике 60мегабит/с например, 1,5 - 3 мс считая фрагментирование данных по 128 байт). Если пришел пакет срочно его выгребайте из DMA буфера. 50мгц это очень мало для работы с Ethernet. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться