• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 30 subscribers
  • Views 1304 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TM4C129 launchpad lwIP receive callback not fired despite tcp buffer grow

Stefano Pessina
Prodigy 150 points
Other Parts Discussed in Thread: EK-TM4C1294XL

Dear all

I work with TM4C129 launchpad on an application that include a tcp/ip communication and I implemented it using lwip 1.4.1.

On the network there is only one partner but it doesn't implement any flow control...Its task is only "send a 28 bytes each 5 ms about".

My trouble is: When communication starts, around ten packets are received and lwip receive callback is correctly invoked, but, after that, no callback are fired for some seconds. After that, for next three callbacks execution the datagram passed from lwip to my callback include between 1300 and 1460 bytes  (many "packets" from the partner in one). This behaviour is repeated cyclically.

Someone can help me for fix this behaviour?

What I have understand about this trouble:

1) It doesn't happen if the network part implements a right flow control but in this case I can't modify the partner program

2) It's significatly reduced when I reduce computation time of callback function (remove debug cout calls) and SysTick timer function (where lwipTimer call is present). I can clearly disable debug cout calls but I can't remove systick function that manage other time-sensitive PID tasks.

More implemetations details:

1) SysTick interrupt is called each 1 ms

2) Inside SysTick tick there are functions called at for example 5/10/15 ms. lwIPTimer is one of that and it's called each 5 ms 

3) SysTick priority is 0x80 and Ethernet Tick 0xC0. In my consideration PID tasks are more time-sensitive than eth com ones. 

Thanks you so much for your attention, if you have some suggest please answer to me.

Best regards

Stefano Pessina 

  • 0
    TI__Guru 59540 points
    Hello Stefano,

    Might it be possible to reduce your SysTick call to every 5mS to improve the loading if nothing faster than 5mS is needed?

    Also, are you using the TI-RTOS lwip implemenation? If so, I can move your post to the TI-RTOS forum where you might get more targeted support for their drivers.
  • 0 in reply to Chuck Davenport
    Prodigy 150 points
    Hello Chuck

    Thanks you for answer. Yes I can reduce SysTick call to 5 ms and this reduce significatly the trouble, but I don't tested it for long time as in real application. Do you think it could be a lwip configuration problem?

    About TI-RTOS implements, I'm not sure but I can tell you in lwippots.h the NO_SYS is defined; so I think that the answer could be no, I don't use TI-RTOS.

    Thanks you so much, best regards
    Stefano Pessina
  • 0 in reply to Stefano Pessina
    TI__Guru 59540 points

    Hello Stefano,

    My suggestion was based on your earlier comment that the issue seemed to be related to the amount of time spent in the callback function and that reducing the time in the callback function would reduce the occurrence or severity of the issue. So, reducing the CPU load resulting from the 1ms systick would allow less time in the callback function "calculations" and allow more time to service the received packets. Note that I am not an Llwip expert so this seems more an intuitive solution/answer than one based on knowledge about the lwip setup within your application.

    My original question about the TI-RTOS was primarily due to the fact that persons often will use an RTOS when implementing this type of functionality so that it can manage the tasks within the application. If you're not using one, that is OK. It was simply a fact finding question.

    You mention that you are using the lwip-1.4.1 software. Is this the software included in TivaWare under the third_party directory? Have you had a look at the launchpad examples; specifically the enet_lwip example under ..\..\examples\boards\ek-tm4c1294xl\enet_lwip\examples\boards\ek-tm4c1294xl\enet_lwip to see if there might be any helpful guidance in this example/implementation?

  • 0 in reply to Chuck Davenport
    Prodigy 150 points

    Hi Chuck

    Thanks you for your answer. I agree with you about the solution to reduce load on cpu allow more time for communication, I'm only a little scary about the stability of this approach because during the application lifecycle cpu load can increase. This is the reason because I ask here about lwip configuration (I'm a newbie about lwip).

    To answer at your question, yes I found lwip-1.4.1 in TivaWare folder (version 2.0.1.11577) and I start from enet_lwip example to build the ethernet communication task in my application.

    Thanks you for your support.

    Regards

    Stefano 

  • 0 in reply to Stefano Pessina
    Guru 11940 points

    I'd like to add a few comments here.

    First, one cannot expect that examples (like this one, and the other TivaWare examples) are rigidly tested for all scenarios, and fit for commercial purposes. (This comment is more directed towards other threads/complains). Rather, they are a free-of-charge example showing how it could be done, and guideline for one's own development.

    Second, I would be careful with small MCUs and Ethernet. For 100MBit/1GBit, that boils down to about 10 MByte/sec. or 100 MByte/sec. throughput, both are practically beyond the reach of a Cortex M4. Application processors (Cortex A and Intel CPUs) manage this with special peripherals with large receive buffers (several kBytes). So, depending on your net load, you will definitely hit the breaking point somewhere. In short, error (overload) management is important. Or, chose a more powerful application processor.

  • 0 in reply to f. m.
    Prodigy 150 points
    Hello f.m.

    Thanks you for your answer. I agree with you, the examples are only start points.

    Your focus about the processor choice is very interesting. In my opinion many not expert people (also me), when buy this kind of launch pad, think only that its is equipped with an ethernet port so it can be used for each ethernet communication. This is a wrong consideration/missing analisys during my processor choice.

    Thanks you for your support, I will take care about your advices.

    Regards
    Stefano
  • 0 in reply to Stefano Pessina
    Guru 11940 points

    In my opinion many not expert people (also me), when buy this kind of launch pad, think only that its is equipped with an ethernet port so it can be used for each ethernet communication.

    Yes. Once one walked into this trap, the next investigation will (hopefully) include more own considerations, and less marketing buzz.

    It's not difficult to do some rough estimations before. A processor/MCU can only execute so and so much instruction per second, and needs so and so much cycles for interrupt entry/exit. So anything that requires high throughput (graphics, imaging, USB, Ethernet, etc.) will quickly saturate or overload your MCU, especially if it has no dedicated hardware support.