Mike Fleetwood wrote:
I am using ST's ethernetif.c driver for STM23F427, which occasionally
returns ERR_USE. The reason this return code is used, rather than any
other is explained by ST in the function header:
So STM decided to return "Address in use" (ERR_USE) when they cannot enqueue a
tx packet
in the DMA ring. That's a bogus error code for this error condition. This might
be a valid
approach as ERR_MEM indeed has some other side effects (e.g. the http server
retries
writing less bytes, etc).
However, ERR_USE is clearly the wrong error here, since it does not point to
the error
source at all.
ERR_IF might have been better, but this is marked as fatal in the lwIP version
they ship,
so this is not an option as well.
ERR_BUF might have been better, but in the end there is not a real difference
to using ERR_USE,
as the stack does not check error return values other than ERR_MEM and
ERR_IS_FATAL().
So, my request is: is it possible for future versions of LWIP detect
this return from the low level driver and either impliment some recovery
(presumably short wait, then re-try would allow the DMA buffer to
clear),
I could imagine that for TCP (some kind of trigger callback that results in
calling tcp_output()
on all pcbs), but there's no way to do that for UDP (we do not have cached
pbufs to retry).
Instead, the netif driver might want to keep a list of pbufs to transmit and
queue them in
a software queue if the (hardware-) DMA queue is not big enough.
or, at least report the error in a meaningful way to the higher
layers?
That's easy: make the netif driver implementation return a meaningful error.
ERR_IF would be correct, but that doesn't work until fatal error handling has
been fixed.
ERR_BUF would be OK for now, I guess.
Currently, this error would appear to be fatal.
No, it's not (unless you use a pre 1.4.0 version of lwIP).
It should continue working once there's room in the DMA ring again. That makes
me think there's
some kind of race condition in the driver.
As to why it should happen in the first place - that is another problem!
That, too, makes me think of a bug in the driver, given the timings you
discribed in your last mail.
Simon
_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users