I think this is the bug Sergio referred to?
The "CubeMX" framework generates code to connect LwIP to the ST
driver.
It appears to free a pbuf before it is processed; seems like a
rather bad idea.
What's the proper way to handle this? Or am I confused?
tcpip_thread (lwip) thread priority is set to 3 (FreeRTOS
priority 0, which is highest).
The packet-pump thread ethernetif_input is set to the same
priority,
so putting a message into its queue does not immediately trigger
a priority-induced context switch (which would be a non-ideal
way to fix this problem).
Thanks again for any help,
Best Regards, Dave
void
ethernetif_input( void const * argument )
{
struct pbuf *p;
struct netif *netif = (struct netif *) argument;
for( ;; )
{
if (osSemaphoreWait( s_xSemaphore,
TIME_WAITING_FOR_INPUT)==osOK) // DRN: Wait until driver signals
one or more frames received
{
do
{
p = low_level_input( netif ); // DRN: retrieve next pbuf
from driver layer
if (p != NULL)
{
// DRN: below calls LwIP tcpip_input, which calls
tcpip_inpkt, who enqueues msg with pointer p into sys_mbox_t
tcpip_mbox
if (netif->input( p, netif) != ERR_OK )
{
pbuf_free(p); // DRN: Serious bug! p is placed in
mailbox by netif->input and may not yet have been processed!
}
}
} while(p!=NULL);
}
}
}
--
Dave Nadler, USA East Coast voice (978) 263-0097, address@hidden, Skype
Dave.Nadler1