Странности в работе FreeRTOS+lwIP, STM32F217+Micrel KSZ8995 Опции

[athlon64]

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?

[Cosmojam]

Сталкивался с подобным на LPC17 + FreeRTOS + LwIP. Только не при остановке работы, а при закрытии сразу множества TCP-соединений. Гуглом нашёлся совет что это из-за некорректной обработки пакетов из очереди emac. С езернетом в STM32 дела не имел, не знаю точно как там, а в LPC17 решилось уменьшением кол-ва DMA буферов для входящих и исходящих фреймов.

[athlon64]

Сталкивался с подобным на 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;
        }
      }
    }
  }
}