LPC1769 FreeRTOS LWIP : rx interrupt no more trigged after some time

[tdo]

Hello

I'm facing a trouble with the LPC1769 and LwIP stack. At some point, the receive task present in lpc17xx_40xx_emac.c just hang on sys_arch_sem_wait(&lpc_enetif->rx_sem, 0);.

As far as I can tell the Rx intterupts are no longer trigged (but TX interrupts are). In function ETH_IRQHandler it never goes inside the following IF block

if (ints & RXINTGROUP) {
        /* RX group interrupt(s) */
        /* Give semaphore to wakeup RX receive task. Note the FreeRTOS
           method is used instead of the LWIP arch method. */
        xSemaphoreGiveFromISR(lpc_enetdata.rx_sem, &xRecTaskWoken);
    }

I have checked the 'Command', 'Status' registers, nothing seems anormal.

The (RxFilterCtrl - 0x5000 0200) register is OK and broadcasted message flag is set to allow reception

My project is based on LPCOpen 2.10 and derivate from the 'lwip_tcpecho_freertos' example. I have upgraded to FreeRTOS V8.2.3 and LwIP V2.0.0. The arch directory is almost the same

In lwipopts.h, i've made some changes to use static memory allocated @0x2007C000 and pbuff

My Computer send on braodcast address (255.255.255.255) an UDP packet on port 45454 every 100ms (17 bytes).  The LPC send every 100ms 3 to 5 packets of 280 bytes each to the Computer address (which is retrieved from received packet on port 45454) I'm only using the Socket API.

I've been able to perfom some long run before the RX thread hang: 10h, and more than 2,000,000 packets exchanged before the error occurs. It sometimes hang sooner than that.

As the probleme occurs, even ping are not received. Transmission as already stated keeps working perfectly. The MCU and the Computer are plugged on the company network

As the problem occurs, all the thread and Queue of my application keep working normaly. Even the behaviour on the  receiving socket is fine (Select keep timeouting as no message is received)

If you have any idea, it'll be great as i'm really stuck on this problem

Thanks

Original Attachment has been moved to: FreeRTOSConfig.h.zip

Original Attachment has been moved to: sys_arch_freertos.c.zip

Original Attachment has been moved to: lpc17xx_40xx_emac.c.zip

Original Attachment has been moved to: lpc_debug.c.zip

Original Attachment has been moved to: lpc_arch.c.zip

Original Attachment has been moved to: lpc_17xx40xx_emac_config.h.zip

Original Attachment has been moved to: perf.h.zip

Original Attachment has been moved to: lpc17xx_40xx_emac.h.zip

Original Attachment has been moved to: lpc_arch.h.zip

Original Attachment has been moved to: cc.h.zip

Original Attachment has been moved to: lwipopts.h.zip

Original Attachment has been moved to: sys_arch.h.zip

[wsd]

Sadly I´m now facing to the same problem.

Is there any solution for this issue in the meantime?

[Carlos_Mendoza]

Hi Thibaut,

We are investigating this, there seems to be a bug on the driver in LPCOpen that causes a failure of the memory assignment from heap when MCU receiving. We are working on fixing the driver, will get back to you as soon as we have a fixed version.

Hope it helps!

Best Regards,
Carlos Mendoza
Technical Support Engineer

[tdo]

Hi Carlos,

Thank you for your answer. It does help as you indicate it might not

originate from a faulty configuration.

I'll be glad to test the new LPCOpen drivers as they will be released.

Right now I don't have much time to investigate on this problem but in the

coming weeks it will be the top priority again.

Best Regards

Thibaut

2016-12-29 21:13 GMT+01:00 Carlos_Mendoza <admin@community.nxp.com>:

NXP Community

<https://community.freescale.com/resources/statics/1000/35400-NXP-Community-Email-banner-600x75.jpg>

Re: LPC1769 FreeRTOS LWIP : rx interrupt no more trigged after some time

reply from Carlos_Mendoza

<https://community.nxp.com/people/Carlos_Mendoza?et=watches.email.thread>

in LPC - View the full discussion

<https://community.nxp.com/message/864326?commentID=864326&et=watches.email.thread#comment-864326>

[Carlos_Mendoza]

Hi Thibaut,
 

We found a workaround to resolve a similar issue in the webserver project  on LPC1769 and we think the workaround should be applicable to this issue here. Could you please try it on your side? The suggested workaround is this:

In the tcp_impl.h file change the definition of TCP_MSL to the following:

#define TCP_MSL 100 //1000 //60000UL /* The maximum segment lifetime in milliseconds */

It means the memory is freed more quickly when closing connection.

I tried the value 100 and 1000 on lpcopen webserver example on lpc1788 and it can work.

We analyze the cause should be that when TCP connection is closed, the PCB is not released in time due to the long (120s) time waiting. This cause the PCB created more and more so that memory leaks due to the limited memory of MCU (SRAM). 

Hope it helps!
 
Best Regards,
Carlos Mendoza
Technical Support Engineer

[tdo]

Hi Carlos,

Thank you very much for remembering my problem. I'm sure this fix will help many people

Unfortunately I'm not sure this will help me to fix my problem.

The only TCP_MSL present in my project is located in lwip/priv/tcp_priv.h. The TCP_MSL is not even defined/compiled for my project, as LWIP_TCP is set to 0 in my lwipopts.h

I'm only using UDP  in my project. If it is of any help, I can provide to you more of my project (whithout some of the sensitive part, but you'll have the whole usage of the LwIP stack)

I have tried to change priorities of  tskRECPKT_PRIORITY  and tskTXCLEAN_PRIORITY located in lpc17xx_40xx_emac.c without any sucess. The only visible effect is that it is the sending of all messages that might block after some time (instead of the reception). I have even enable LOCK_RX_THREAD knowing i might have some performance issue (which are not a concern right now as only 3 to 4% of CPU are used; 96% of time in FreeRTOS Idle task)

[tdo]

Sorry wrong operation, the message was sent before I wanted to do so :s.

If you have any hint that might explain why at some point the RX or TX interrupt are no longer trigged, I'll be glad to look after. I was wondering whether it could be a problem with the communication between LPC and the PHY chip ?

I'm pretty sure it's not hardware related as i'm using two different card (one based on a LPCxpresso 1769 red D board + a MagJack RJ45, and one AOA board from embedded artist)

Thanks

Best regards

Thibaut DONTAIL