[lwip-users] Stuck in netconn_write()

[Thomas Johansen]

Hi all

I have a LPC1788 running FreeRTOS and lwIP.

When a task, using netconn_write function, has a to low FreeRTOS priority, then it can lockup sometimes.

I have a function I use for sending Ethernet data via the netconn API.
To protect the TX function I use a critical section so one task can complete the transmit before a new one can do it.

But if I the calling task has a low FreeRTOS priority the task is stuck in the netconn_write(..) function??
It seems strange to me. It never returns from it.

Using higher priority, seems to solve the issue.

If the calling tasks has priority of at least 3, it seems to be fine. (I haven't tried higher)
The lwip recevie, transmit and tcp_ip task has the FreeRTOS priority at 3,3 and 4

The NVIC priority are set accordingly to Cortex M3 and FreeRTOS guideline. (Higer is lower:-))

Any idea why it does that?

Thomas


________________________________
______________________ Appended by AGRAMKOW Fluid Systems A/S _______________________

This e-mail and any attachments may contain information which is confidential, proprietary, privileged or otherwise protected by law. The information is solely intended for the named addressee (or a person responsible for delivering it to the addressee). If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender Immediately by return e-mail and delete it from your computer.





****************************************************************************
This e-mail has been scanned by http://www.comendo.com and does not contain virus.
****************************************************************************

[Szymon Tarnowski]

Hi,
Function netconn_write internally post request data to the lwip tasks and
then enters infinite loop until lwip task finishes job.
I am not sure about FreeRTOS under Cortex architecture, but I suspect that
application task has higher priority and enters infinite loop, but
scheduler never run lwip task. So lwip taks could not mark request as done,
so application tasks is stuck in infinite loop.
--
Szymon

Hi all****
I have a LPC1788 running FreeRTOS and lwIP.****
When a task, using netconn_write function, has a to low FreeRTOS priority,
then it can lockup sometimes.****
I have a function I use for sending Ethernet data via the netconn API.
To protect the TX function I use a critical section so one task can
complete the transmit before a new one can do it.****
But if I the calling task has a low FreeRTOS priority the task is stuck in
the netconn_write(..) function??
It seems strange to me. It never returns from it.****
Using higher priority, seems to solve the issue.****
If the calling tasks has priority of at least 3, it seems to be fine. (I
haven't tried higher)
The lwip recevie, transmit and tcp_ip task has the FreeRTOS priority at
3,3 and 4****
The NVIC priority are set accordingly to Cortex M3 and FreeRTOS guideline.
(Higer is lower:-))****
Any idea why it does that?****
Thomas****
** **
------------------------------
______________________ Appended by AGRAMKOW Fluid Systems A/S
_______________________
This e-mail and any attachments may contain information which is
confidential, proprietary, privileged or otherwise protected by law. The
information is solely intended for the named addressee (or a person
responsible for delivering it to the addressee). If you are not the
intended recipient of this message, you are not authorized to read, print,
retain, copy or disseminate this message or any part of it. If you have
received this e-mail in error, please notify the sender Immediately by
return e-mail and delete it from your computer.
------------------------------
This e-mail has been scanned by http://www.comendo.com and does not contain virus.
------------------------------
_______________________________________________
lwip-users mailing list
https://lists.nongnu.org/mailman/listinfo/lwip-users

[Simon Goldschmidt]

Post by Szymon Tarnowski
Function netconn_write internally post request data to the lwip tasks and
then enters infinite loop until lwip task finishes job.
I am not sure about FreeRTOS under Cortex architecture, but I suspect that
application task has higher priority and enters infinite loop, but
scheduler never run lwip task. So lwip taks could not mark request as done,
so application tasks is stuck in infinite loop.

Not exactly. What you describe by "infinite loop" is actually an OS wait call. If that one doesn't lead to the scheduler telling the tcpip_thread to run, there is something seriously wrong with the OS-part of the lwIP port.

However, in that priority constellation you can of course still lock out all network traffic by programming an infinite loop yourself, so unless you really require it to be like that, the tcpip_thread should have a higher prio, I guess.


Simon

[Nikolas Karakotas]

Hi,

Have you set this flag:
configUSE_PREEMPTION 1

Also in your Idle tasks do you call vTaskDelay?

Regards,
Nick

From: Thomas Johansen
Sent: Tuesday, January 15, 2013 10:55 PM
To: lwip-***@nongnu.org
Subject: [lwip-users] Stuck in netconn_write()

Hi all

I have a LPC1788 running FreeRTOS and lwIP.

When a task, using netconn_write function, has a to low FreeRTOS priority, then it can lockup sometimes.

I have a function I use for sending Ethernet data via the netconn API.
To protect the TX function I use a critical section so one task can complete the transmit before a new one can do it.

But if I the calling task has a low FreeRTOS priority the task is stuck in the netconn_write(..) function??
It seems strange to me. It never returns from it.

Using higher priority, seems to solve the issue.

If the calling tasks has priority of at least 3, it seems to be fine. (I haven't tried higher)
The lwip recevie, transmit and tcp_ip task has the FreeRTOS priority at 3,3 and 4

The NVIC priority are set accordingly to Cortex M3 and FreeRTOS guideline. (Higer is lower:-))

Any idea why it does that?

Thomas





--------------------------------------------------------------------------------
______________________ Appended by AGRAMKOW Fluid Systems A/S _______________________

This e-mail and any attachments may contain information which is confidential, proprietary, privileged or otherwise protected by law. The information is solely intended for the named addressee (or a person responsible for delivering it to the addressee). If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender Immediately by return e-mail and delete it from your computer.




--------------------------------------------------------------------------------

This e-mail has been scanned by http://www.comendo.com and does not contain virus.

--------------------------------------------------------------------------------



--------------------------------------------------------------------------------

[Thomas Johansen]

Hi,

Yes, I use configUSE_PREEMPTION 1

There is no vTaskDelay() in my Idle task, but the __wfi instruction. Schould wait for the next tick interrupt

Thomas

From: lwip-users-bounces+tjo=***@nongnu.org [mailto:lwip-users-bounces+tjo=***@nongnu.org] On Behalf Of Nikolas Karakotas
Sent: 16. januar 2013 00:09
To: Mailing list for lwIP users
Subject: Re: [lwip-users] Stuck in netconn_write()

Hi,

Have you set this flag:
configUSE_PREEMPTION 1

Also in your Idle tasks do you call vTaskDelay?

Regards,
Nick

From: Thomas Johansen
Sent: Tuesday, January 15, 2013 10:55 PM
To: lwip-***@nongnu.org
Subject: [lwip-users] Stuck in netconn_write()

Hi all
I have a LPC1788 running FreeRTOS and lwIP.
When a task, using netconn_write function, has a to low FreeRTOS priority, then it can lockup sometimes.
I have a function I use for sending Ethernet data via the netconn API.
To protect the TX function I use a critical section so one task can complete the transmit before a new one can do it.
But if I the calling task has a low FreeRTOS priority the task is stuck in the netconn_write(..) function??
It seems strange to me. It never returns from it.
Using higher priority, seems to solve the issue.
If the calling tasks has priority of at least 3, it seems to be fine. (I haven't tried higher)
The lwip recevie, transmit and tcp_ip task has the FreeRTOS priority at 3,3 and 4
The NVIC priority are set accordingly to Cortex M3 and FreeRTOS guideline. (Higer is lower:-))
Any idea why it does that?
Thomas


________________________________________
______________________ Appended by AGRAMKOW Fluid Systems A/S _______________________

This e-mail and any attachments may contain information which is confidential, proprietary, privileged or otherwise protected by law. The information is solely intended for the named addressee (or a person responsible for delivering it to the addressee). If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender Immediately by return e-mail and delete it from your computer.


________________________________________
This e-mail has been scanned by http://www.comendo.com and does not contain virus.
________________________________________
________________________________________
_______________________________________________
lwip-users mailing list
lwip-***@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
________________________________________
This e-mail has been scanned by http://www.comendo.com and does not contain virus.
________________________________________

______________________ Appended by AGRAMKOW Fluid Systems A/S _______________________

This e-mail and any attachments may contain information which is confidential, proprietary, privileged or otherwise protected by law. The information is solely intended for the named addressee (or a person responsible for delivering it to the addressee). If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender Immediately by return e-mail and delete it from your computer.



****************************************************************************
This e-mail has been scanned by http://www.comendo.com and does not contain virus.
***************************************************************************

[Chris Williams]

I noticed that someone is using the LPC1788 with LwIP.

Can you point me to the driver for this part? I want to use it in my
next project.

I looked in the contribs and ports and it does not seem to be there.

Thanks for your help.

Chris.

[FreeRTOS Info]

Post by Thomas Johansen
There is no vTaskDelay() in my Idle task, but the __wfi instruction. Schould wait for the next tick interrupt

Good - the idle task must *never* block. Which task would run if the
idle task was blocked?

Later versions of FreeRTOS include a tickless idle mode that stops the
tick interrupt and sleeps in the idle task, but that is very different
to blocking the idle task because when the MCU is sleeping nothing is
executing.

Post by Thomas Johansen
To protect the TX function I use a critical section so one task can complete the transmit before a new one can do it.

Does the Tx function use FreeRTOS API calls? If so then you can't use a
a critical section. Use a mutex instead.

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for microcontrollers. More than 7000 downloads per month.

+ http://www.FreeRTOS.org/plus
Trace, safety certification, UDP/IP, TCP/IP, training, and more...

[Thomas Johansen]

Post by Thomas Johansen
To protect the TX function I use a critical section so one task can complete the transmit before a new one can do it.

Does the Tx function use FreeRTOS API calls? If so then you can't use a a critical section. Use a mutex instead.

The TX function does not use any API calls.
The critical section, is it actually a semaphore.

Thomas

______________________ Appended by AGRAMKOW Fluid Systems A/S _______________________

This e-mail and any attachments may contain information which is confidential, proprietary, privileged or otherwise protected by law. The information is solely intended for the named addressee (or a person responsible for delivering it to the addressee). If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender Immediately by return e-mail and delete it from your computer.



****************************************************************************
This e-mail has been scanned by http://www.comendo.com and does not contain virus.
********************************************