In the following, I will assume that you are using something lkike AT89C52, with 8kB of internal code memory (flash), i.e. 0-1FFFh.

Above, I said, that after the program "ends", the '51 fetches the unprogrammed bytes from the flash, which are FFs, and it happily executes them as MOV R7,A ; until the program counter reaches 2000h.

What happens next, is usually said "undefined". Nevertheless, it is often quite well defined, but you simply cannot rely on it.

For example, if you have connected pullups to P0 and use them as outputs (i.e. nothing external pulls them low), the mcu starts to "fetch" code from "external memory" - basically it emits PC to P2/P0 and then reads the code byte from P0. So, if P0 is pulled up "hard" enough (i.e. the RC constant of unloaded pin and the pullup is less than the time between end of outputting the low address and latching in the new data), the mcu will "see" more FFs, execute them up to FFFFh (this takes a few ms, a human won't notice), where PC rolls over to 0000h, which is the reset vector, so the program so to say restarts. If you have some peripherals connected which pull some of the pins low, it will see an another "code" - try to figure out what happens if this is for example permanently "E7h" or similar. Try experimenting with various values and estimate the probability that the program will run up to FFFFh. (A remark, there is no guarantee that the PC will roll over to 0000h from FFFFh, but in the older, simpler '51 derivatives it is quite likely so; also note that this is not equivalent to reset as the default reset value of SFRs is not restored by simply "walking" to 0000h).

But there is an another scenario, too, if the P0 is completely floating. Usually, the pin capacitance is enough to "keep" the value previously emitted as the lower address, so you fetch 00h from 2000h, 01h from 2001h, 02h from 2002h... Try to figure out, what will be the likely execution path of this (use a simulator or a disassembler).

Yet another behaviour can be expected, when you set the protection fuses so that external program memory is not "allowed". The behaviour is again undefined by the manufacturer, but it well can be that it 1. resets deliberately, 2. works according to any of the two scenarios above, when fetch from address >2000h is attempted.

There are many other scenarios, but none of them such that you want to rely on them. Nevertheless, you can try to play with this if you want for a while: write a short program, reading code byte from 2000h, 2001h, etc. using MOVC, and sending out via serial port, observing on a PC in a terminal program. If you do this in a loop, you can then play with several things, e.g. trying to set the protection fuses and see what changed, or if the bus is floating, see what happens if you put your fingers on the pins. You can then try to "run" such "code" in a simulator, or disassemble it, to see, what will happen in reality if it will be executed.

The morale of this whole exercise is (besides the fun, and besides the obvious one - you shall never let your program run away beyond the "END"), that even rather corrupted programs may sometimes behave relatively normally or predictibly. For example, if one does not notice that his program exceeds the, or if one uses absolute ORGs so that code segments overlap, he can get a relatively well working program, only with some small mysterious "resets" or "quirks".

JW