NetBurner Community Forum

1)Does it do this with the ethernet cable unplugged?

2)When you set the IP address did you do it via the monitor or via the ipsetup utility?

3)Another useful piece of info is does it do this at 57600 instead of 115200?

4)Are you using the USB port or the DB9 port?

5)Is ANY thing attached to the other serial port(s)?

6)If you try a DIFFERENT static IP address does it still fail?

7)IF the answer to #6 is no, is there something else trying to talk to this address while the FLA is running?

Answers:

#1 - Yes it does fail with ethernet disconnected. It fails when the network cable is disconnected.
#2 - Both IPSetup and the Monitor. I have it setup with the IPSetup utility right now. Before I used the monitor.
#3 - No, it is successful at 57600. Like pulling teeth waiting for the file to transfer though...
#4 - USB Port. However I just tried it @ 115.2kbps on the wired serial port and it fails too.
#5 - No... nothing is attached to the serial ports.
#6 - I tried 20.20.20.200 and it still fails.
#7 - No, nothing else is on the network. Wireshark reports no packets being transferred. (fails when disconnected)...

So it appears that it is baud rate related... but why do you have to have the IP set to 0.0.0.0 or run it at 57.6 kbps?

Weird bug.

The Configured IP Address of my unit is still 0.0.0.0, the factory demo uses DHCP so when the FLA happens it had a normal DHCP address (which in my case was 192.168.22.184). Just tried to repeat today and after the FLA I got a checksum error. Reflashed with AutoUpdate and the next FLA worked. So there is something flaky about FLA the unit. Also once I get a trap or any type of error, the recommend approach is to power off and power on and break into the monitor on the cold boot. This becomes problematic if you're using USB for power and serial communications because unplugging the usb cable will upset MTTY and I don't think I'm fast enough to plug in the USB and get MTTY connected in time to hit SHIFT-A. You mght need to move to a power brick and the normal serial port for solving this.

Regarding your response to Paul, I'm a little confused. Updating flash over serial and debugging with the serial port are unrelated. Standard operating procedure is to flash the unit with TCP/IP via AutoUpdate and to still use cout (or printf if you must live dangerously) for serial port debugging purposes. Flashing with TCP/IP in no way deactivates the serial port for other uses.

The 57600 vs 115200 test, pretty much nails the problem.
Its over running the serial buffer on a large download. As the Mod54415 has gobs and gobs of RAM,
making the buffer bigger is not a hard thing to do...

It could also be the problem that the task running the command processor and download is at too low of priority....

Fixing this in already fielded units is a bit harder as the hardware is setup with a hardware WP preventing one from
modifying the monitor under any condition. The eventual fix will require a jumper between pins on the bdm connector...
detailed instructions on this will be part of the eventual update.

Thanks for looking into it. Now that I know what is going on I can just get around it for now if I need to. So far I have not needed to flash any firmware over the serial port.

Thanks again,
Chris Favreau