I created and use an ASSERT macro to validate param's passed to func's, as well as the value of global var's used by ISR's, etc. I noticed that occasionally while debugging, an ASSERT would trigger for a global var used in my A/D ISR. Upon inspection, I confirmed that it was used in a very small number of locations, and there was no way it could be out of range as the ASSERT indicated. I did confirm that both the CLR_MEMORY and INIT_VARS build flags in my start167.a66 file were set to 1, but that shouldn't have mattered anyway since the var in question was init'd to a valid value just prior to enabling the A/D INT in my initialization func. I tried to duplicate the problem, but it did not appear to be repeatable enough for me to catch (while looking for it --- I was too impatient). However, it did happen every once in a while, and one of those times I noticed that the ASSERT triggered before my main() function was called, which meant the A/D INT was getting enabled before I enabled it, or so I thought. I now think that the problem is due to the fact that I'm using a [very slightly modified] canned MONITOR program in bootstrap load mode (the Phytec KC167CR sample), without pressing the RESET button on my pcb in between loads of new code, and therefore, once my code runs that enables the A/D INT, it stays enabled forever (since my code never disables it, unless the uC gets reset somehow). I did confirm that once my A/D INT was enabled, I could stop the debugger, remove the line of code that enabled the A/D INT, rebuild and reload the code, and the A/D INT remained enabled! I looked through the code in the Phytec MONITOR sample, trying to find the associated code, to see if I could modify it to negate all INT's (other than the one for the serial port that it needs), but to no avail. Is the "correct" solution to this problem to always make sure the uC gets reset prior to loading new code in BSL mode, or am I missing something?