• State TI Thinks Resolved
  • Locked Locked
  • Replies 13 replies
  • Answers 2 answers
  • Subscribers 32 subscribers
  • Views 1689 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.

EK-TM4C1294XL: TM4C1294

Stefania Franci
Prodigy 60 points
Part Number: EK-TM4C1294XL

Hi everyone,
we have developed different devices around the TM4c1294 and his ethernet interface. We used the LWIP stack library without the OS and the devices are very stable.
But we've experienced a strange fault on the network interface during testing the devices on a large infrastructure lan. The network interface drops the connection and refuses to 
turn up. No response from ping and to or from other network port used to talk with the device.
All the other functions was still alive (sensors and display) but no answers from the LAN.
It is necessary to turn off and On the device to solve the problem. We tried to confine the device into a VLAN and it solved the problem but is impossible to apply on the real installation.
Seems that the big amount of data and broadcast, requested by the Microsoft OS connected on the same subnet, carrys the TM4c1294 into an unrecoverable error due to overflow or other reasons that we don't know. 
Have you ever faced the same issue? 

thanks and best regards
Maurizio

 

  • 0
    TI__Guru**** 190986 points
    Hi Maurizio,
    Can you check the EMACSTATUS and EMACDMARIS registers? Do you see any error flags set? If yes, which are set?
    Is it possible for you to put two TM4C129 devices on the same broadcast domain? Will both see the same problem when huge amount of broadcast frames are sent by the MS OS? Or only one will fail?
    I will also suggest you post the same question to the LwIP forum and see if anyone experienced the similar problem and how to approach the problem if it is stack related.
  • 0 in reply to Charles Tsai
    Prodigy 60 points

    Thank you a lot Charles,

    No, i never checked the EMACSTATUS and EMACDMARIS register.

    Yes we have exactly two devices on the same area but the customer says that they are on different subnet. So, one is working properly and the other freezes the netwotk activity after a "non defined" condition.

    I'll try to post the same question on the forum you suggested, hoping this helps me to solve the issue.

    meanwhile if you have other suggesions i will apreciate them.

    Thanks and best regards

    Maurizio

     

     

     

  • 0 in reply to Stefania Franci
    Guru 117855 points

    May it be asked if, "Stefania" serves as the (pardon) "bait" ... while Maurizio, "Casts and then reels-in the (thus far) fish-less line?"

  • 0 in reply to cb1_mobile
    Prodigy 60 points

    Nono, why we should do this?

    we've two different accounts that are on the same office. "Stefania" is my colleague and we are in the same project.

    We never wanted to use this account like a "bait"........(WHY???)   

    we are both trying to solve an issue and i'm the software developer that uses her account because of i forgot mine......that's all. Now, is there  anyone that can help us? 

    I found that on LWIP 1.4.1 TI released a patch for the  PBUFF memory leaks  called tiva-tm4c129.c  under the path: <TivaWare_Directory>/third_party/lwip-1.4.1/ports/tiva-tm4c129/netif/tiva-tm4c129.c"

    and now the devices are under test .But  We have the same issue also on another product that uses the old stack 1.3.2  and we are facing the same problem: when connected to a large netwok ,randomically , TCP stops working and is cecessary to turn OFF and ON the device.

    Seems to be the same PBUFF issue.

    Any suggestions?

    thanks and best regards

    MAURIZIO (and STEFANIA)

  • 0 in reply to Stefania Franci
    TI__Guru**** 190986 points
    Hi Maurizio,
    What is the result after you switch to lwip 1.4.1? Does it make any difference?
  • 0 in reply to Stefania Franci
    Guru 117855 points

    My point - along w/a (likely failed) attempt at (slight) humor - is that Vendor Agents are "taught" to, "Reply w/Poster's name" - and the TWO Names (may) - in time - cause confusion!     Especially as "different" Vendor Agents arrive, "on the scene."

    Your explanation is (most) valid - and not one that I (had) considered...  

  • 0 in reply to cb1_mobile
    Prodigy 20 points
    :-) you are right...
  • 0 in reply to Charles Tsai
    Prodigy 20 points
    Good evening Charles, the 1.4.1 seems to be stable but it is very hard to simulate what happens on the large network. First of all we are unable to reproduce the exact case when the issue pop's up . We've tried to use Network simulator to bombing the device (both LWIP 1.3.2 and 1.4.1 )with lots of junk data. Also putting in loop an old HUB just to create an high random data flow to the micro interface, but it resist and is very stable.
    Today our client says that the issue happens again (but on the LWIP 1.3.2 device) this confirm that the environment is responsible of the issue. The connected the device on the same subnet with more than 300 PC's (equipped with windows 7-10) and is impossible to create a VLAN to confinate the network traffic. So i'm very frustrated. This because the issue is random but is critical because the devices act as a production-line data collector and when the TCP hangs, all data are lost because we need to turn off and on again the device because the stack was unable to restart also after a software reset. Is possible that the windows PC's generates MULTICAST or BROADCAST packet that carries the LWIP into a loop?

    Help me !
    Thanks and best regards
    Maurizio
  • 0 in reply to maurizio damiani34
    TI__Guru**** 190986 points
    Hi Maurizio,
    Did you have a chance to read the EMACSTATUS and EMACDMARIS registers?

    According to your description, the 1.4.1 is more stable than 1.3.2 even though you don't see any failure in your own environment. Looks like your customer has also tried the 1.4.1 and didn't see any problem. Is this correct? Only 1.3.2 experienced the issue. Can you reprogram the failing unit firmware from 1.3.2 to 1.4.1 on your customer side. This will prove if the stack version is at play here. If this is the case then it could be a stack related issue that I hope the LwIP forum can provide some guidance.

    Too many broadcast/multicast messages can certainly jam the network. This is a network management issue that the IT department at your customer's end can look at. I'm not sure how continuous broadcast messages would affect
  • 0 in reply to Charles Tsai
    Prodigy 60 points

    Good evening Charles.

    Now, there are 2 devices (one with 1.4.1 and another with 1.3.2)  on the same lan and both are working fine so i'm not able to know if  the 1.4.1 is working better than the 1.3.2. I need to wait the issue to evaluate.

    Meanwhile  i will modify the firmware to print on the LCD the  EMACSTATUS and EMACDMARIS registers (this because once the issue happens  there is no way to read the device by network interface)

    Do you know a valid tool to generato UDP and TCP traffic to try to emulate the issue in our lab Something that generates traffic on different port (multicast, broadcast ect) ?

    The application is very simple :

    - A tcp socket is listening on port 4001 waiting a 16 byte command string

    - on connection accepted, the software answer with a 16 byte of data

    - the connection is closed by the device.

    this cycle is repeated every minutes.

    Another soket is open on the port 80 to allows the tiny web server to run for device configuration.

    And also in this case the device is in listen state .

     


    thanks and best regards

    Maurizio

  • 0 in reply to Charles Tsai
    Prodigy 60 points
    Another question Charles,
    searching on the forum i found that someone has a similar problem :

    - Application using lwIP stops working after 4-5 days on a TM4C1294XL LaunchPad

    seems that his application stop responding after a undefined period of time and someone suggested to check il the TCP_UDP flag is disabled.

    Seems that UDP if defined always enabled by default. So if i specify on the lwipopts.h that i don't want to use it, the "opt.h" override my settings by set it to 1 by default.

    So if i try to change on "opt.h" the default settings from 1 to 0 , when compiling i receive an error related to the "dhcp.c" file. So is impossible to disable it!

    This means that the UDP socket is always working. May a brodcast fillup the UDP buffer and create a memory leak or an undefine state also if o never defined a port where to listen?

    I've disabled all the related routines that uses UDP (locator and update)....

    What do you think?

    Regards

    Maurizio
  • 0 in reply to Stefania Franci
    TI__Guru**** 190986 points

    Maurizio,
    You are right that the very first message DHCP sends is DISCOVER which is a broadcast message as the client has no idea what DHCP server's IP address is. Since TCP doesn't support broadcasts, the UDP is used.

    The EMAC module has the filter that you can use to filter out broadcast messages but I'm not sure if this is something to look at for experimental purpose. If you suspect a memory leak I will suggest to try increasing the heap size and see if that will make a difference. You might want to consult LwIP forum on how they best manage the heap memory.

  • 0 in reply to Charles Tsai
    Prodigy 60 points

    Hi Charles,

    tomorrow i'll try to investigate the UDP socket hoping to find something that triggers the error. I need to generate multiple broadcast just to stress the DHCP .

    i'll keep you updated.

    Thanks and best regards


    maurizio