Programming via external phy

[SeeCwriter]

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.

[TomNB]

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?

[SeeCwriter]

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.

[pbreed]

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

[SeeCwriter]

Correct on all counts.

[TomNB]

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?

[SeeCwriter]

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

[pbreed]

Can you send a schematic and part number of Jack?

[pbreed]

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

[SeeCwriter]

What is a flood ping?