STM32F4x9 + LAN8720A + lwIP 2.0.2, утечка памяти PBUF Опции

[Hold]

оптимизация отключена. Воткнул проверку на валидность адреса в функции prvCopyDataFromQueue

CODE

static void prvCopyDataFromQueue( Queue_t * const pxQueue, void * const pvBuffer )
{
if( pxQueue->uxItemSize != ( UBaseType_t ) 0 )
{
pxQueue->u.pcReadFrom += pxQueue->uxItemSize;
if( pxQueue->u.pcReadFrom >= pxQueue->pcTail ) /*lint !e946 MISRA exception justified as use of the relational operator is the cleanest solutions. */
{
pxQueue->u.pcReadFrom = pxQueue->pcHead;
}
else
{
mtCOVERAGE_TEST_MARKER();
}
if ( ( (uint32_t)pvBuffer < 0x20000000 || (uint32_t)pvBuffer > 0x2002FFFF ) || ( (uint32_t)(pxQueue->u.pcReadFrom) < 0x20000000 || (uint32_t)(pxQueue->u.pcReadFrom) > 0x2002FFFF ) )
{
printf("\tIncorrect addr in prvCopyDataFromQueue\r\n");
}
( void ) memcpy( ( void * ) pvBuffer, ( void * ) pxQueue->u.pcReadFrom, ( size_t ) pxQueue->uxItemSize );
}
}

Запустил проверку, жду когда сработает.
UPD: разбираюсь дальше


UPD:
Разбираюсь с функцией sys_arch_mbox_fetch, которую я взял из примера ST.
Есть подозрение, что в ней бага, причем жирная.

CODE

/*-----------------------------------------------------------------------------------*/
/*
Blocks the thread until a message arrives in the mailbox, but does
not block the thread longer than "timeout" milliseconds (similar to
the sys_arch_sem_wait() function). The "msg" argument is a result
parameter that is set by the function (i.e., by doing "*msg =
ptr"). The "msg" parameter maybe NULL to indicate that the message
should be dropped.

The return values are the same as for the sys_arch_sem_wait() function:
Number of milliseconds spent waiting or SYS_ARCH_TIMEOUT if there was a
timeout.

Note that a function with a similar name, sys_mbox_fetch(), is
implemented by lwIP.
*/
u32_t sys_arch_mbox_fetch(sys_mbox_t *mbox, void **msg, u32_t timeout)
{
void *dummyptr;
portTickType StartTime, EndTime, Elapsed;

StartTime = xTaskGetTickCount();

if ( msg == NULL )
{
msg = &dummyptr;
}

if ( timeout != 0 )
{
if ( pdTRUE == xQueueReceive( *mbox, &(*msg), timeout / portTICK_RATE_MS ) )
{
EndTime = xTaskGetTickCount();
Elapsed = (EndTime - StartTime) * portTICK_RATE_MS;

return ( Elapsed );
}
else // timed out blocking for message
{
*msg = NULL;

return SYS_ARCH_TIMEOUT;
}
}
else // block forever for a message.
{
while( pdTRUE != xQueueReceive( *mbox, &(*msg), portMAX_DELAY ) ){} // time is arbitrary
EndTime = xTaskGetTickCount();
Elapsed = (EndTime - StartTime) * portTICK_RATE_MS;

return ( Elapsed ); // return time blocked TODO test
}
}

Суть в следующем - если нужно дропнуть пакет, то они вместо адреса получателя пакета ставят указатель заглушку и читают в него. В указатель типа void. Возможно проблема в том, что он не указывает ни на что, и по факту можем птытаться записать хрен пойми во что. Попробую выловить.
UPD3: нет, там все верно, там же на входе указатель на указатель. Ищу дальше.
UPD4:
Еще одна бага в sys_arch.c. При создании mailbox-ов, незавивимо от указываемого размера, создавались они размеров всего-лишь 6 элементов.

Код

*mbox = xQueueCreate( archMESG_QUEUE_LENGTH, sizeof( void * ) );

Дополнительно включил SYS_LIGHTWEIGHT_PROT, поглядим

Сообщение отредактировал Hold - Sep 11 2017, 12:43

[mantech]

Многократные передачи мегабайтной картинки, виснет именно 8720, как на собственной плате, так и на примере от starterkit.

Это только на одной плате так или везде? Попробуйте не читать\записывать в регистры 8720 вообще ничего, и посмотрите.

[Hold]

И все таки, кривой драйвер ethernetif.c. Взял драйвер отсюда , все завелось.
Проверил на 3-х клиентах FTP, http-страничка и 3 пинга одновременно, все работает. Погоняю еще по времени. Зависаний LAN8720 пока не замечено.