int32_t
Tesla Spotter
Yeah, I get that. This is going years back now, but our devices had supposedly non-volatile memory and excellent battery contacts too, but due to memory corruption issues we ran into years ago with slightly imperfect battery contacts and/or on-off switches, we developed a suite of tests to stress the system and try to corrupt the memory. The tests primarily involved making a mess of the supply voltage while the device was initialising. It worked (i.e., caused things to fail) at first, but as the years went by the silicon got better, and it hasn't been a problem in years since modern silicon isn't bothered by voltage dips during power-up: the device's POR circuit holds the device in reset until the supply voltage is above a reasonable threshold to guarantee proper operation.I "fidgeted" with some of them at the tire store... Demo units. They are sealed tight. Vibrations may make the tuned circuits mess up, but the batteries are really tight. Then the battery doesn't have the instant power to transmit anyway, so I'm sure there is a capacitor to absorb supply spikes. Finally, they only transmit every few minutes. A lost unit for a minute or two is insignificant.
The antennas store their "listening" addresses in EEPROM or flash. When I bench analyzed a unit, I could reprogram it, and remove power, then test it later, and the addresses remain.
The thing is, tight or not, any battery contact short of actually soldering or spot-welding the battery to the electronics is going to disconnect given the vibration a tire will see on the road, however briefly. (We didn't think our battery contacts were the problem either until some testing proved otherwise.) Whether or not these brief disconnects can affect memory is a function of how good the chip's brown-out detect circuit is and other stuff. It's much easier to go with @markwj's hypothesis that it's software-related -- because I missed that minor point that two units went bad, not just one.