UDP Networking Port Changed??

[demedeiros]

Hi All,

I have a system I built for underwater data acquisition. Reads some sensor info and sends the data up to a ship via ethernet (fiber really...).

The system was configured to use ports 8220 and 8225, and worked flawlessly for about a year. Recently, the port number changed to 40993 and 40988. Which interestingly is (2^16)/2 + the original port number.

[newguy]

I haven't had a look at your code. Have you changed compiler version in that time?

[Ttelmah]

I think he is talking about a failure on a running system. If so, can it be
hardware reset?. If so, did this fix it?.
If so then it sounds like a RAM failure. Could be EMC or radiation effect.
If it is wrong after reset, then it suggests a ROM failure. Do you write to
the program memory in the chip (using virtual EEPROM for example)?.
If so this can lead to cell failures after time.
It is two bits being set to '1'. Bit 14 in the two variables. The reference to
temporary place holder, suggests that something can change these values
in the data received?. If so, how is this checked?.
Do you have any test of the temperature in the system?. RAM and ROM
failures both become more common as temperature increases.
A change in the supply voltage could also cause problems. Is this monitored?.

[demedeiros]

This is on a running system, no changes have been made to the code in over a year.

Power cycling would be the same as a hardware reset right? I looked over the code and realized the port is being pulled from the external EEPROM. Power cycling does nothing as the new (incorrect) value is stored in the EEPROM.

Yes, via UDP the ports can be changed, however this is not being implemented (allegedly) on the server side program. Other than just confirming that the port was changed functionally (does it work? yup/no?) I dont have any logging of this.

Temperature really shouldn't be that warm. The ocean temp is fairly cool and the board is located in a large aluminum enclosure. However I should have data for internal temp as it is sent topside.

Supply voltage is not monitored, but that is an interesting thought!

[Ttelmah]

EEPROM bits fail to '1' when erased. It sounds as if two bits in your EEPROM
have erased. Now, this does happen with time. It is how EEPROM's fail.
Failures are more common when writes are done to the EEPROM. How old
is it?. What type is it?. Historically EEPROM type from a few years ago,
had 'lives' of only a few thousand cycles. Now the lives are millions of
cycles.
Now radiation could erase a cell. However normal ambient radiation is
very much attenuated by water (alpha particles a lot, beta less, and gamma
rays much less), However if this was in a site where there is radioactive
rock, or contamination of the water, this could happen. Also (of course),
if there is anything inside your unit which generates radiation, this needs
to be shielded (some test equipment does contain radioactive sources
and electronics then needs shielding from these). The two failures in
adjacent bytes, almost has the ring of a particle passing through the
memory.

[demedeiros]

Ttelmah, as always thank you for your incredible replies.

The EEPROM being used is the Microchip 24AA02E48, which appears to have greater than a million write cycles.

At this point im going to chalk it up to a hardware failure in the EEPROM. If this issue happens again I will take a deep dive into my code and try and figure out what is happening. In the actual app they are not changing the port so I may just hard code the port right into the PIC.

Thanks again!!

[Ttelmah]

You could consider adding error checking.
Perhaps a parity byte for each variable. Done carefully, you can even
usie something like Shannon encoding, and recover lost bots.