DK-TM4C129X - Lose ability to ping board when more components are added

Even without reloading the program:

I see the same behavior where I do a system reset and run and the network is up,

pause the program, do another system reset, run it, the network is down

pause again, do another system reset again, run it, newwork is up. 

Even when the network is down, my blink LED task seems to run everytime, it's just the network piece that is intermittent.

Any other ideas of things I can try? 

Steve,

Would you please try recycling the power to see if test always works after power-on?

Thansk and regards,

Zhaohong

It's hit and miss, sometimes it works sometimes not.  Same thing if I hit the reset button on the board.  The network seems to come up about 80% of the time.   

At first glance, I would suspect a ressource overflow. Either you miss interrupts because they take too long, or you overwrite memory (the latter includes stack overflows). Have you made a worst-case load analysis ?

You might want to check that no interrupt handler calls code that implicitly relies on other interrupts. That could introduce nasty interdependency bugs which are hard to track down.

@ f.m.  I'd hit the like (or second this) button - if forum had one.

Thoughtful and xtal clear - hat's off on this one...  (not so much re Gimp {elsewhere})

Cordialement...

Steve,

I would suggest you trying the following to debug the issue.

(1) Toggle one or more I/O pins at important points in your code. From the I/Opin toggling, you check if the system is running and if the CPU is overloaded.

(2) When there is no ethernet communication, can you save the content of all EMAC and PHY registers so that we can see what is wrong? I would suggest to always save the EMAC and PHY registers at the beginning of your test so that you can check if they come out of reset correctly by comparing the values between the successful runs and failed runs.

Thanks and regards,

Zhaohong

...  (not so much re Gimp {elsewhere})

You might be right, but I like to consider the posters background. For a private project, posters are usually out for a quick solution, and usually don't ask for solid proof, clean code or reproducibility. Of course, my guess might be wrong here ...

It could be my dev kit is flakey because I can run the UDPecho sample program with no changes, hit the Reset button and it will occassional not be on the network. I'm going to order another kit to see if it acts the same way. 

Or the UDP-echo code might skip som 'less important' initialization settings, which are zero at power-up, but not so after reset. Sample/demo code sometimes bravely omits certain defensive code measures, rendering it unsuitable for robust industrial application. That's why it's called sample/demo - and it is usually free ...

Steve,

Where did you get this UDP-echo example? I could not find it in the examples in Tivaware. I would like to take a look. Startup/initialization issues are very important to us.

Thanks and regards

Zhaohong

It came with the tirtos 1_21_00_09 download.  

It looks like this issue has been found in some other posts.

Inconsistent ethernet on TM4C129ENCPDT

f. m. said:

Sample/demo code sometimes bravely omits certain defensive code measures, rendering it unsuitable for robust industrial application.

While ethernet use - your board - may be inconsistent - one notes, "stunning consistency between writing above - and past "word picture" - authored by this reporter..."  (i.e. attribution - s'il vous plait...)

That said - f.m.'s comment re: "Reset vs. Power-Up Reset" wins approval/consideration - our small group...

Steve,

I have been watching the discussions about the Ethernet module on TM4C129X. Can you trying the following method to see if it would help.

Disable the flash prefetch buffer before the initialization of the Ethernet module. This will slow down CPU code execution significantly which is effectively slow down the write and read to the Ethernet module. You can re-enable the flash prefetch buffer after the completion of Ethernet module initialization. This can be done by setting the FPFOFF bit in the Flash Configuration Register (FLASHCONF). This register is memory mapped to the address of Base 0x400FDFC8.

Please let me know if this method works for you.

Thanks and regards,

Zhaohong