lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Receive path stuck due to pbuf_alloc returning NULL


From: ercang
Subject: Re: [lwip-users] Receive path stuck due to pbuf_alloc returning NULL
Date: Mon, 25 Mar 2019 01:57:23 -0700 (MST)

Hi Sergio,

Thanks for the answer.

"If your device does not go to the Eth Rx ISR that is because either the 
controller is not interrupting anymore or the OS is not accepting the IRQ."

I don't think FreeRTOS controls EMAC interrupts, what I face is probably
your first assumption.

"  p = pbuf_alloc(PBUF_RAW, somesize, PBUF_POOL); 
        if (p != NULL) { 
                // handle the data from the chip to the pbuf 
        } else { 
                // LINK_STATS_INC(link.memerr); was useful long time ago,
and I guess 
it still is 
                // flush the chip so it "thinks data has been delivered", I
read it 
anyway like if delivering, ymmv 
                return; // can't go ahead, and next frame will likely have
to be 
discarded too... mmm... ymmv 
        } 
        // perhaps check some packet types and eventually 
        if (netif->input(p, netif != ERROR_OK)) 
                pbuf_free(p); 
        // but if you will not deliver, then pbuf_free(p); 

Perhaps your driver is not checking returned value and goes ahead when 
it shouldn't ? 
Maybe your driver does check the value and forgets to properly care for 
the controller when there is no place to put the data ? "

I am implementing something similar to this. What I don't understand is
neither ISR nor ethernet input task does not use any return value from
hdkif_input(), which implements these functions. I don't even know what
pbuf_alloc has to do with emac controller. It looks to me that pbuf_alloc
should not affect ISR mechanism. However, as I told in my question,
disabling pbuf_alloc() saves the program from not getting into ISR. 

I tried to change some options in lwip. I enabled MEMP_OVERFLOW_CHECK,
MEMP_SANITY_CHECK in opt.h and LWIP_FREERTOS_SYS_ARCH_PROTECT_USES_MUTEX in
sys_arch.c and that made an improvement. Now interrupts fail after 7-8
minutes instead of 1-2 seconds.

I am kind of a newbie, not very familiar with the device, freertos and lwip.
But these observartions make me think the problem is with lwip.

Can you help me further?
Regards
Ercan



--
Sent from: http://lwip.100.n7.nabble.com/lwip-users-f3.html



reply via email to

[Prev in Thread] Current Thread [Next in Thread]