Problem with enet_lwip running on EK-TM4C1294XL LaunchPad

Just to add to the above, when the application is started, the Virtual COM Port messages are:

        Waiting for IP.

        Waiting for link.

If an Ethernet cable is plugged in, then

        Waiting for IP address.

That's as far as it gets.

I've even tried enet_io, with the same behaviour.

With an Ethernet calbe plugged in, I get:

        For enet_lwip: no IP address

        For enet_io: no IP address

        For enet_weather: IP address 169.254.207.171

However, I am not able to ping 169.254.207.171, but this may be a problem outside the board/code.

Hi Amit,

That fixed it. (Not a good way to implement an LED flashing routine!)

I managed to find out, before the fix, that AutoIP did indeed generate an IP address, but it took 10 minutes and 50 seconds.

Once lines 188-209 are commented out, the time to generate an IP address reduced to 39 seconds. It is interesting to note, that for enet_weather, it takes just 27 seconds.

Thanks for pursuing this and getting me an answer. Much appreciated. I can now move on.

Regards, Vito

Hi Amit,

For the next release, and I think we are talking about the same thing, all that needs to be done is comment out lines 197, 198, 207 and 208. This way you get the quick AutoIP adress and maintain the flashing LED display indicating that an IP address is not yet available. It's basically what the LM3S9D96 enet_lwip does.

Don't forget to also update enet_io.

While I've got you, the DK-LM3S9D96 example enet_lwip has one other very nice feature. Even if an Ethernet calbe is not connected, it would AutoIP an IP address. This is very handy.

Regards, Vito

Some insights into what was actually happening:

1) lwIPHostTimerHandler is being called by lwip at a rate of 10 times per second (that is, every 100 ms) [as determined by the parameters input to SysTickPeriodSet and lwIPTimer].

2) The LED flashing routine was taking about 5 seconds to complete.

Therefore, lwIPHostTimerHandler, rather than completing its tasks in well under 100 ms, was taking 5000 ms to execute its tasks. The CPU was basically starved of any non-interrupt time. This resulted in everything slowing down.

Amit,

It would be nice if the example was improved in two ways:

1) Get the whole search for a DHCP server and if unsuccessful get an AutoIP IP address assigned in 10 seconds (or 20 seconds at the most) [This can be done by simply altering the input parameter to lwIPTimer from 10 to 20 or the halving the input parameter to SysTickPeriodSet, but this may have other repercussions.]

2) Get an IP address assigned even if there is no Ethernet connection.

Regards, Vito

Hi Amit,

I like the DK-LM39D96's example  behaviour, which was to assign an IP address regardless of whether an Ethernet cable was attached.

The reason for this is that, about 20 seconds after the device was switched on it would have an IP address. If I then wanted to talk over Ethernet (using a custom application, which requires the IP addres to be entered), the IP address was immediately available to me and I could proceed without waitng (after plugging the Ethernet cable in).

Not a very strong preference, which would be even less of a concern if AutoIP was called sooner so that an IP address is avialable, say, 10 seconds after the Ethernet cable is plugged in.

Regards, Vito

Hi Amit,

I was having the same problem as Vito faced. Glad to find out that it is able to be shortened to 39 seconds.

But, is there anyway to further shorten the duration of this process?

Best Regards,
Mike

Mike,

Here are my notes relatignto this subject:

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

lwIPHostTimerHandler is called by lwip every 100 ms to allow the top-level application to perform periodic tasks. (Such tasks could be incorporated into a 100 ms periodic task and lwIPHostTimerHandler could go!)

The frequency of lwIPHostTimerHandler being called can be adjusted by the parameter for SysTickPeriodSet and/or lwIPTimer. Here’s the result fo some experimentation

Enet_lwip values shown in blue. Maybe lwIPTimer would be better served with an input parameter of 20 or 50. Maybe HOST_TMR_INTERVAL could be set to 0 and the required tasks handled with application periodic tasks.

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

The main number you want to look at is "IP add avail".  Hope it makes sense.

I am using TM4C129EXL, in my case lwIPHostTimerHandler() does not been called at all. but the original code works fine, what I have done is create a  new project, copy and paste all the code to the new project, the project could compile, but the lwIPHostTimerHandler() is never touched by the code, seems some issue with triggering the interrupt.  the sample I used is the enet_lwip sample.

Shan