Robin2:
If this is just for debugging why not rig up a pushbutton that signals the need to save the data and press that just before you upload the new code?
I strongly favour continuing with this Thread as it contains a lot of useful background info....R
Last question first, I'll keep the thread going then, but if its allowed maybe I'll re-title it to something that better describes the way the conversation went. Either that or start a new thread which references this one, inviting those with alternative solutions to post on the original thread. I'm aware I can rig up another way of doing a save. But see, that suggestion is an example of how a thread can get so sidetracked, that it loses it's original meaning. If someone GOOGLE'd for anything to do with stealing or intercepting an ARDUINO's reset vector, and found this thread, they would be very dissapointed. I understand many novice designers ask the WRONG question, and its great when people can reply in such a way that the real problem is better explained. But sometimes, the question might be best addressed with an actual definitive answer.
To your suggestion to add a button, yes... there are many ways to modify code or add to an existing circuit to accomplish my goal of saving data, WITHOUT using my originally sought out method. I'm sure you can understand though that software only solutions are often best. In my case, for example, a PCB and finished enclosure for a project was already cut and somewhat finalized, when a latent "less than ideal" behavior was discovered. Thats expected. Even if its not really a bug, needs for improvements usually reveal themselves over time. But while troubleshooting, it became apparent that the inability to save immediately before a reset was a detriment to quickly verifying a fix. But any add on like you described at this point would mean tacking on wires and adding some secret button I would not want any end user to mess with. Additionally, for future upgrades/improvements, it would be an advantage (and one less point of error for a field installer) if all that was necessary was to jack in a USB port and perform the upgrade, knowing that the end users scheduled and ongoing processes would resume as expected. Finally, since I am making the USB port accessible, its always possible some curious user might jack it into a PC. If that is done, the resulting reset could once again cause an issue with current daily scheduled processes, because states were not saved.
Bottom line alternatives will always exist, but the software only solution I requested would be best IMO, for my current and future projects. And I'd still like to know if my software only approach is feasible.