MCF5329EVB dBug 4c breaks TFTP

[PaulS]

Does anyone have a copy of the source code for dBug 4a?  4a was shipped with my EVB and worked well with "dn" downloading images via TFTP.  dBug 4d shipped with LTIB and I installed that in order to gain autoboot functionality.  Unfortunately this broke tftp in a very interesting fashion -- ARP appears not to work correclty anymore with a subset of our Ethernet switches.  The "dn" comand simply sits silently without timing out (no bars twiddling) unitl some external event "fixes" the problem.  For example, if I ping the EVB from the TFTP server, the "dn" immediately starts twiddling, and completes the download.

The ping has be from the TFTP server in order for the "dn" to work, although to the EVB actually succeed in getting replies from other hosts.  I assume that dBug is wating siliently trying to ARP for the server in some way that's not compatible with our ethernet switches.  When we ping from the server, dBug fills in the ARP entry for the TFTP server from the incoming ICMP frame.  I'm not sure if this means that the outgoing ARP frame is bad or that its interpretation of the ARP reply has changed.

I'll get out the packet sniffer and find some root causes.  I don't mind finding the solution to the problem myself, but it will be a lot easier if I have the source code to 4a so I can tell what changed.

Thanks!

[KH_SRNL]

Hi Paul.  I'm looking for a copy of D-Bug12 v4.0.0b18. Since you found older d-bug code, I was hoping you may have ideas on where to locate this rev.  The b32 version (available on Freescale) doesn't work correctly with my debug pod.

[PaulS · Accepted solution]

 I ended up tracking down an old 4a image and I got my satisfaction.  The problem isn't with ARP exactly, it's a problem with timers.  My network sometimes drops the first frame sent on the network, and the board never times out reception of an ARP reply and never resends.  I tracked this down to a single line that was changed in dbug/src/cpu/coldfire/mcf5xxx/mcf5xxx_timer.c:

  timer_set_secs(uint8 channel, uint32 secs)
 {
     uint32 timeout;

     /* Get the timeout in seconds */
-    timeout = (uint32)(((timer[channel].period * 0xFFFF)/1000000000) + 0.5);
+//    timeout = (uint32)(((timer[channel].period * 0xFFFF)/1000000000) + 0.5);
+    timeout = (uint32)(((timer[channel].period * 0xFFFF)/1000000000));

     if (timeout == 0)
     {

        timer[channel].reference = 1;
        return FALSE;
    }

It turns out that the period for the MCF5329 is set to be:

#define TIMER_NETWORK_PERIOD    1000000000/0x10000

The timer init sets (timer[channel].period  = (float) TIMER_NETWORK_PERIOD), and then the math above does the division again, so even in the best floating point implementation the result is 0xFFFF/0x10000 which is very nearly 1, but not quite.  This is why I think the original code fudged upwards by 0.5, but this was deleted, and hence on the MCF5329, no timers.  Reverting that change fixed everything.

Message Edited by PaulS on 2009-06-03 07:47 PM