STM32F217+Micrel KSZ8995
Взял за основу проект STM32F2x7_ETH_LwIP_V1.1.0 с сайта STM, в котором использовал 2 варианта проекта веб-сервера (Standalone и FreeRTOS). Переделал в обоих проектах инициализацию PHY под микрель.
Демка заработала, пинг пошёл.
Но замечена была следующая особенность:
В FreeRTOS-версии если ненадолго остановить выполнение программы и вновь возобновить его, пинг после возобновления становится огромным (скачет от десятков мс до нескольких секунд), большая часть пакетов пропадает и через несколько минут пинги перестают проходить вовсе. То же самое (пропуски, обрывы) случаются периодически в FreeRTOS-версии демки раз в несколько минут-часов.
В Standalone-версии такого не бывает. Если приостановить выполнение программы - пинг прекращается, после возобновления - пинг отличный и никаких пропаданий пакетов.
Инициализация в обоих проектах переделана под микрель одинаково (изменения проводились одинаковые), проверил уже раз 10.
Единственное отличие в работе и микрелем на беглый взгляд, что FreeRTOS-проект использует ETH_DMA, а Standalone - нет.
В потроха стека ещё не лазил, подскажите в какую сторону копать?
Сталкивался ли кто-нибудь с подобными багами в этой демке или в связке с micrel ksz8995 под FreeRTOS?
Полная версия этой страницы: Странности в работе FreeRTOS+lwIP
Сталкивался с подобным на LPC17 + FreeRTOS + LwIP. Только не при остановке работы, а при закрытии сразу множества TCP-соединений. Гуглом нашёлся совет что это из-за некорректной обработки пакетов из очереди emac. С езернетом в STM32 дела не имел, не знаю точно как там, а в LPC17 решилось уменьшением кол-ва DMA буферов для входящих и исходящих фреймов.
Цитата(Cosmojam @ Aug 15 2012, 00:56) 
Сталкивался с подобным на LPC17 + FreeRTOS + LwIP. Только не при остановке работы, а при закрытии сразу множества TCP-соединений. Гуглом нашёлся совет что это из-за некорректной обработки пакетов из очереди emac. С езернетом в STM32 дела не имел, не знаю точно как там, а в LPC17 решилось уменьшением кол-ва DMA буферов для входящих и исходящих фреймов.
Спасибо за ответ.
Действительно, изменение кол-ва буферов DMA влияет на проявление глюка. При ETH_RXBUFNB = 1 глюк перестаёт проявляться.
Погуглив, нашёл следующее решение данной проблемы (тут) - нужно заменить код задачи ethernetif_input на:
Код
void ethernetif_input(void * pvParameters)
{
struct pbuf *p;
for(;; )
{
if(xSemaphoreTake(s_xSemaphore, emacBLOCK_TIME_WAITING_FOR_INPUT)==pdTRUE)
{
GET_NEXT_FRAGMENT:
p = low_level_input( s_pxNetIf );
if (p != NULL)
{
if (ERR_OK != s_pxNetIf->input( p, s_pxNetIf))
{
pbuf_free(p);
p=NULL;
}
else
{
xSemaphoreTake(s_xSemaphore, 0);
goto GET_NEXT_FRAGMENT;
}
}
}
}
}
{
struct pbuf *p;
for(;; )
{
if(xSemaphoreTake(s_xSemaphore, emacBLOCK_TIME_WAITING_FOR_INPUT)==pdTRUE)
{
GET_NEXT_FRAGMENT:
p = low_level_input( s_pxNetIf );
if (p != NULL)
{
if (ERR_OK != s_pxNetIf->input( p, s_pxNetIf))
{
pbuf_free(p);
p=NULL;
}
else
{
xSemaphoreTake(s_xSemaphore, 0);
goto GET_NEXT_FRAGMENT;
}
}
}
}
}
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.