??? 11/21/09 16:03 Read: times |
#171019 - Neither way fixes anything. Responding to: ???'s previous message |
Kai Klaas said:
Richard said:
I agree that the measure you recommend will mitigate the risk of the code wandering off into the weeds if there's uninitialized code space, but ... after all, it doesn't cost any extra to fill unused code space with NOP's. With the AT89S52 and ISP programming it is like the following: Before you can program the flash code memory you must fully erase it, which leaves "FF" everywhere in the code memory. Programming means substituting these "FF" by the code bytes and leaving the unprogrammed bytes to "FF". So, a micro eroneously jumping out of the code range will execute "MOV R7,A" instructions while incrementing the program counter over and over again, until it skips to "00", which is the same as if the micro would undergo a hardware reset. So, the micro wouldn't endlessly run ill, and it's not needed to fill the unused code space with NOPs either. Kai Klaas First of all, this should not happen. Secondly, if it does, it's clear evidence of broken hardware of or broken code. However, if you fill the unused memory with NOP's, a single-byte instruction, the MCU will ultimately end up at 0x000, which is where it would go on a RESET, and R7 hasn't been altered, though the initialization code might just put it in a different state anyway. Nevertheless, it would be harmless, perhaps either way, aside from the fact that it just might get "lost" again. I doubt there's a significant advantage in doing either, so your "default" value is probably as effective as the 0x00 (NOP). RE |