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.

LM3S8933: TCP communication problem on firmware based on enet_io lwip example

Part Number: LM3S8933

Hello,

We have the following issue, we have been using the LM3S8933 micro controller for several years, using a custom firmware strongly based on the enet_io examples with LWIP.

Lately we have encountered a problem reported from our customers, the problem is with the TCP communication with requests that has a payload above 512 bytes. We recalled the products and investigated. 

Up until now we have 2 micro controllers on which we witness the following problem. If we decrease the TCP_MSS configuration in the lwipopts.h file from 1024 (our default setting) to lower values, the issue seems to be resolved. On one malfunctioning micro the TCP_MSS required value for the TCP to work is 512 while the 2nd micro we need to reduce the value to 256 in order for the TCP to work.

I want to mention that we have thousands (might be even more than 100K) of micros working perfectly well. 

We Debugged the  LWIP requests in the firmware and no fault was raised, the LWIP works on the malfunctioning micros exactly as on the normal micros and no error is witnessed.

It looks like there is a problem with these 2 specific micro controllers, and more likely in the memory section of the MAC layer or the PHY layer.

Unfortunately our explanation was not accepted by the managerial level in my company and I need your support. If you have encountered similar sporadic behavior or you are aware of some malfunctions similar to what I described, please let me know.

I can add images of the malfunctioning micros if you need production dates or LOT codes.

Also please let me know If you have some suggestions for further investigation.

Thanks,

Michael

 

  • Hi,

      If the same firmware works on thousands of devices on the field for so many years, there is no reason to believe it is a firmware issue. I will suggest you do a ABA swap test.

    - Swap out the problem MCU to a good know board. If you continue to see the same problem then it is most likely a MCU hardware issue although we don't know what is the root case. If you don't see a problem then the MCU is good. 

    - swap in a good known MCU to the problem board. If it continues to work then there is a no problem with the board. If you start to see the same reported failure then it is your board problem.