AutoUpdate can't find modules with my application (one NIC)

[Heliotopos]

Should the find functionality in AutoUpdate find MOD5234's on the network after my _APP.s19 is on the module?

It does find factory-new modules so I don't think it's a network problem. I can ping the module that has my build, and explicitly setting the IP in AutoUpdate address works fine for updating. I've seen a thread here from people with multiple NIC's having problems, but I only have one. I can see UDP broadcast packets with port 20034 in Wireshark when using find in AutoUpdate, but I don't see any traffic from the module in response. My PC and the module are plugged into the same switch on the office network. My application code does call EnableAutoUpdate().

Could this have to do with the AppName? I've looked at the AutoUpdate source and it looks like it reports the AppNames it gets in response, but it doesn't appear to ask for a specific one.

Thanks

[sulliwk06]

Are you using static or dynamic IP's? What does the network mask look like on your computer and the 5234? Maybe that will shed some light on it.

[rnixon]

What version of the tools are you using?

[Ridgeglider]

It's been a long time since I tripped on this, but I recollect that NB Find, and AutoUpdate would fail if the AppName is too long, something like more than 40 chars?? Somehow 56 chars sticks in my memory too for some odd reason.

[Chris Ruff]

Any chance that you have a task that is blocking? Placing an OSTimeDly(n) somewhere might bring AutoUpdate back online

Chris

[Heliotopos]

Well, this is embarrassing. For reasons that aren't clear, someone changed the UDP_NETBURNERID_PORT in constants.h in the 2.5.3 NNDK include directory against which our application is built. As soon as I recompiled AutoUpdate with the same port number, it worked perfectly.

Thanks for the replies... sorry to waste peoples' time.