It worked properly for far too long, so it was about time for me to run into another seemingly impossible problem with this otherwise excellent bootloader.
I’m trying to figure out why, but there is a particular function I’m trying to add to my helicopter control code that disagrees with the bootloader. I don’t think the function itself has anything to do with it, but just for completeness, the function is:
PPM[2]=control[2]*(vmin+vlog)/(voltage+vlog);
PPM is a volatile global array of unsigned characters
control is a volatile global array of long ints
vmin and vlog are constant global unsigned ints
voltage is a volatile long int
The code compiles fine, uploads fine over an AVRISP, and runs fine. When I try to upload the exact same .hex file using the bootloader it seems to upload fine, in that it passes all the checksum tests, but after reseting it crashes immediately. When I read the hex file back off of the Baby O over an AVRISP, one line always has this difference in it:
:10148000BB1FA617B70710F0A61BB70B881F991F25 - Original Compiled Hex
:10148000001F2617B70710F0A61BB70B881F991F60 - Read Back After Bootloading
Well, of course the checksum is recalculated when I read it back, so that doesn’t count as a change, but why on earth would this be happening?
I monitored the serial bytes going out of my com port while I bootload, and they match the original compiled file. I’m pretty sure the intended bytes are arriving at my Baby-O anyway (not getting messed up by the serial radios for example), since they pass the checksum test. If I change the function slightly to:
PPM[2]=control[2]*(vmin+vlog)/(voltage);
Or move it to another part of the code, it bootloads fine. Of course, this does me no good, since I need it how it is where it is, but when I move it back and recompile it I get the same problem.
Uhhh, and suddenly it’s working fine. I just put the code back the way I wanted it, bootloaded it, and it’s working fine. It also passes a verification test, so it perfectly matches the compiled hex code. Man, I hate intermittent problems, they always come back to byte you later!
The only thing I can think of is that maybe I’m getting close to the AVR’s flash cycle life. I do flash it a LOT. But is ISP flashing it with a external programmer really that different from bootloading? I imagine the same physical write process is occurring, only drawing it’s source bytes from the SPI hardware rather than the USART hardware. Something to ponder anyway. Any ideas?
-Adam