Re: [lwip-users] recv function BLOCK because recv_mbox is full: can yougive me a solution?

[Jonathan Larmour]

Piero 74 wrote:
> 
> 
> 2008/3/7, Jonathan Larmour <address@hidden
> <mailto:address@hidden>>:
>     But that's the thing - if you have a recv blocked, then the mbox
>     should not
>     be full.
> 
>     lwip_recv calls netconn_recv which directly calls sys_arch_mbox_fetch to
>     receive pending data. If the mbox is full, then your thread should have
>     extracted data from the mbox immediately.
> 
> 
> yes... i know,,, but all  was blocked iin a deadlock situation... i
> don't know why... and a big recv_mbox has removed the problem....

Appears to work around the problem I think! But I think this would be a
problem sometime later instead.

>     I think you have a more fundamental problem with your mbox
>     implementation.
> 
> 
> i used queue of  freertos for mbox...
> this is the code:
[snip]

I don't immediately see a problem. Perhaps you need to put your own
debugging into these functions. At least you appear to be able to easily to
reproduce the problem so it should not be hard to gather more data as to
what's going wrong. The implication is that xQueueReceive is not returning
even when data is posted with xQueueSend. You will probably want to verify
that that's really what is going on. Perhaps the mbox has simply gotten
corrupted somehow. Perhaps you are calling the queue functions from an ISR
(which is not allowed in FreeRTOS). Or perhaps FreeRTOS is buggy.

Jifl
-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
 **  Visit us at ESC Silicon Valley <http://www.embedded.com/esc/sv>  **
 **  April 15-17 2008, Booth 3012, San Jose McEnery Convention Center **
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine