DM6437 flakey ethernet problem

Steve B said:

Then when I attempt to "Connect" I sometimes get at least partly connected because I get the greeting on the hostapp's GUI window.  When this happens I can also select the video statics tab or either of the other two stats tabs in the upper right region of the hostapp's GUI.   Never does the lower middle portion of the hostapp become active, though, and hence I am not allowed to select any of the more interesting and useful demo options.

I am not sure if this is the problem here but when you connect to the demo it is already running something and so the lower options cannot be selected, to make the options selectable you have to press the stop button at the very bottom of the host application, this will halt the video and let you change options so that you can press play and start the video up again with the new options.

I have seen unreliability in the detection method depending on how the network is setup, but if you have both connected to the same local switch with nothing else on the network than I would expect it to work relatively reliably, since you are assigning static IPs do you see any reliability difference if you are connected to just the local switch and not the rest of the network?

Bernie Thompson said:

Then when I attempt to "Connect" I sometimes get at least partly connected because I get the greeting on the hostapp's GUI window.  When this happens I can also select the video statics tab or either of the other two stats tabs in the upper right region of the hostapp's GUI.   Never does the lower middle portion of the hostapp become active, though, and hence I am not allowed to select any of the more interesting and useful demo options.

I am not sure if this is the problem here but when you connect to the demo it is already running something and so the lower options cannot be selected, to make the options selectable you have to press the stop button at the very bottom of the host application, this will halt the video and let you change options so that you can press play and start the video up again with the new options.

I have seen unreliability in the detection method depending on how the network is setup, but if you have both connected to the same local switch with nothing else on the network than I would expect it to work relatively reliably, since you are assigning static IPs do you see any reliability difference if you are connected to just the local switch and not the rest of the network?[/quote]

The ethernet unreliability is far more severe than our discussion so far suggests.   *If* I can get the Discovery to work and then *if* I can get Connected (already this is about a one in twenty tries probability) *then* if I just let the preview keep running and do nothing on the host GUI, after a bit ...... perhaps half a minute or so ...... I start getting network-related errors reported on the host's command window.   While this is happenng the host GUI is not really working.   Letting this continue results in the entire demo hanging up, apparently on both side.   I've *never* been ablt to get the "Stop" button at the bottom of the host GUI to work.   I agree with you that it is probably the lack of selecting that button that is keeping the middle portion of the GUI grayed out.

Later today I will try to get some network analysis tools working on the problem.   I'm planning to run a packet sniffer on another computer on the same subnet and see what sort of packets are actually flowing to and from the DSP and host.  It could be that my DM6437 EVM board has something wrong with its ethernet PHY or with some of the magnetics.  I wish I had some other more basic tests like ICMP echo ("png") or some sort of file transfer.   In answer to your suggestion.  Yes I have tried disconnecting the switch from the rest of the network.   No change.

By the way ... when the HTTP port is opened, should it be possible for an internet browser to visit the DSP's "page"?  I see from what is printed when the demo starts running that there is an HTTP port opened and activated.   That might be another avenue to use to help diagnose this problem though I'd need to know what to expect from the point of view of a browser.

Thanks for help so far.   I'll report back when I've done some packet sniffing ...

Further testing has shown the following:

1. The DSP board does an ARP request for its own IP address.  This seems curious since it knows both its MAC address and its static IP address.   Nevertheless, this isn't the problem since things sometimes work anyhow.
2. One time when I managed to get Discovered and then Connected, I observed that there was an assertion failure printed out on the CCS output window.  ASSERT FAILED: FVID_dequeue() failed in app_block_video_output.c line 518.   Note that because I had to change from "dhcp" to "static" addressing, I had to recompile the demo application.  I do not think I've made any changes except in the area of networking as I originally discussed earlier in this thread.  I did recently select -o2 (function-level optimization) though this problem happens both with and without that setting change.
3. Several other times when I was working with the board, attempting to capture some packets, I observed that the DSP stopped processing the video.   When I subsequently issued a HALT command from within the CCS debugger I learned that the program was at UTL_halt, SYS)EXITFXN.

I need to learn how to use the debugger better.   (I'm a beginner with this setup).    How can I use the available tools to figure out what it was doing right before the SYS_EXITFXN was called??   I was hoping that I could look at the call stack but I'm not yet sufficiently fluent with the tools to do that.   Any pointers?   This hang (or exit) is quite repeatable though it  happens after an apparantly different amount of elapsed time each run.