Does anyone here have much experience with integrated devices / compilers and such? I'm wondering if it is within the realm of possibility to modify the VOTER bootloader, which is currently sourced from the ASL VOTER GitHub repo as ENC_C30.cof, a single compiled binary. I assume that the source code was lost along with Jim Dixon.
The reason for needing to make a modification is a long story, but the short/silly sounding version is that I need to modify the bootloaders LED flashing sequence.
The bootloader itself? No, there is no source for it. It was never released before Jim passed, so it only exists as a binary.
Even then, I suspect Jim only had a binary copy. I believe he purchased the bootloader from a third party, if memory serves correctly. That would by why there are instructions on how to hex edit the binary to change the default bootloader IP address… probably because he didn’t have the source to re-compile from.
Lee
Thanks for the info, Lee. That makes sense.
I'm not sure if you are familiar with K3MKs "Thick Client" Module, but it is a modernized redesign of the original VOTER through-hole board. The latest revision has a hardware watchdog chip that was intended to auto-reset the onboard processors if the HB LED stops flashing for a period of time. We found, however, that the watchdog timer is not very accurate, and depending on your luck, the chip you have may or may not have a timer that expires during the ~2s blink gap that occurs during the bootloader sequence, immediately following the 3 initial blinks of all LEDs.
My curiosity wanted to know if we could just decrease the duration of the blink gap, add more blinks, etc... AKA throw software at a hardware problem 
Yes, I am aware of the Thick Client. I would not call it a “modernization”, more of a re-packaging. AFAIK, it still uses the same schematic, just laid out on a custom board to allow for the easier integration of a GPS module (I’ve done something similar myself, but not to that extent).
As for the watchdog, you’re barking up the wrong tree (pun intended). If you are having a problem with the watchdog inadvertently triggering due to the HB LED pattern, the solution would be to increase the time constant of the watchdog to reset after a longer period (ie 10 seconds). Do you need to trigger after 2 seconds of inactivity? No. This isn’t NASA and a mission-critical operation here.
That said, in my over 7 years of running VOTERs (and RTCMs), I have never had one “lock up” and require a hard reset. If there is a situation where that is happening on a regular basis, that is a different issue to resolve.
I’m also sure we’d hear about the issue from other users that have been running them for the 15 or so years now that they have been available.
In my opinion, the watchdog would seem to add nothing more than added complexity, extra parts, and a means to inadvertently reboot the device.
Lee
A modern repackaging, I guess. Finally, something cost effective with an internal GPSDO. A true "one box" solution for VOTER simulcast. No more external GPSDOs and cables going all over the place.
The purpose of the watchdog was not to automatically reset things in case of an issue. It was just to restart the internal GPS module whenever the dsPIC itself was remotely rebooted. It's not tied to anything other than the reset pin of the internal GPS.
I have built several VOTERs, two different revisions of the thick client, and the only times I have had lock up issues are if a GPSDO gets screwy and the 9.6MHz clock gets unstable.
Anyways, I'm not the one who had the idea of the watchdog chip and I didn't make the design. I just ordered the PCB and parts and built it. I was just wondering if it would be possible to fix the functionality in software for this unit I have in front of me that's already assembled.