NetBurner Community Forum

Using a MOD54415 with the phy on the motherboard. When programming using Autoupdate, the module gets programmed but Autoupdate never displays a message indicating the success or failure of the programming. It just sits there forever until the Cancel button is clicked, then it pops up a Programming Failed message. But as I said, the module does get programmed correctly and it reboots as usual.

When programming a module that has the phy on it, with the same file, Autoupdate works normally.

I captured the programming with wireshark, and the only difference I see is with the handshake at the end. After all data is transferred, Autoupdate sends two UDP packets of 24-bytes each to the module, and the module with no phy echos those same two packets back. And this handshaking continues every 11-seconds. But the good module responds with only one 24-byte UDP packet and is done.

I'm looking for ideas on how to proceed.
Using v2.9.2 of the tools.

Hello,

The MOD54415 is manufactured with the PHY chip on the device itself. How are you able to put it on your board? Do you mean the RJ-45 and magnetics?

Yes, the RJ-45 connector and magnetics is what I was referring to. Sorry for the confusion. That's what the hardware designer calls it.

This is a 54415, not a 54417 and its using autoupdate nad 2.X code not the new 3.X tools correct?

Correct on all counts.

Since it works on the other module, I would suspect a hardware issue first, even though it seems like it is just the end confirmation of the update.

Are you using the RJ-45 jack with integrated magnetics purchased from NetBurner?

How are you connected to the 10-pin header on the module? Have you designed your own circuit board and followed all good practices on routing?

I agree that this is a hardware issue with our hardware, not software. The Ethernet interface works, even reprogramming works. It's just that Autoupdate never finishes with a programming complete message. My guess is that Autoupdate is not getting a final response that it likes. So it keeps pinging the module every 11-seconds seeking the right response. In case there is a clue, below are the final handshaking packets after all data has been transferred. I am sending the same s19 file in both cases. And since the same file is used in both cases, why wouldn't the PC->NB packet data be the same for both cases?


Successfull reprogramming packets:

PC->NB: 42 55 52 4e 41 04 84 75 00 40 36 d9 c0 08 62 24 df 37 31 aa f8 6d 7e 75
PC->NB: 42 55 52 4e 41 04 84 75 d9 36 40 00 24 62 08 c0 aa 31 37 df f8 6d 7e 75
NB->PC: 42 55 52 4e 41 00 84 75 00 40 36 d9 c0 08 62 24 df 37 31 aa f8 6d 7e 75

Failed reprogramming packets:

PC->NB: 42 55 52 4e 41 04 84 75 00 1a 5a 21 c0 08 62 24 df 37 31 aa f8 6d 7e 75
PC->NB: 42 55 52 4e 41 04 84 75 21 5a 1a 00 24 62 08 c0 aa 31 37 df f8 6d 7e 75
No response

11-sec later:

PC->NB: 42 55 52 4e 41 04 84 75 00 1a 5a 21 c0 08 62 24 df 37 31 aa f8 6d 7e 75
PC->NB: 42 55 52 4e 41 04 84 75 21 5a 1a 00 24 62 08 c0 aa 31 37 df f8 6d 7e 75
NB->PC: 42 55 52 4e 41 05 84 75 00 1a 5a 21 c0 08 62 24 df 37 31 aa f8 6d 7e 75
NB->PC: 42 55 52 4e 41 05 84 75 21 5a 1a 00 24 62 08 c0 aa 31 37 df f8 6d 7e 75

Can you send a schematic and part number of Jack?

You could also try a flood ping and see what the packet loss looks like on the two....

What is a flood ping?