I have a couple of 16F877A chips both of which are showing a stuck byte at memory location 0x0005. The rest of the chip appears fine (I've no idea how this happened, it just refused to programme one day).
Since the stuck location is very near the beginning of the memory space is there any way I can just jump past it - perhaps inserting a dummy test right at the beginning?
I could just buy a couple of new chips, but being part Scottish the prospect doesn't appeal half as much as working round it for free.
Thanks - Skipweasel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It might be worth double checking the programmer, it sounds very odd to have the same word fail in two different chips! I've had problems before where a program was trying to toggle the programming pins (PORTB.6 or B.7) at a very early stage, which was stopping my PICkit 2 from working properly. A few clicks on the Erase button seemed to fix it - eventually the PICkit must have put the chip in to programming mode before the program could start up. Have you got anything attached to the programming pins other than the programmer?
Also, are you sure it's location 5 only? When you recompile a GCBASIC program, that is the first location that will change from the old version. (Locations 0 - 4 are typically 2805 3FFF 3FFF 3FFF 0008 on any 12F/16F.) Could there be other locations after 5 that are also not programming correctly?
Kent, that's a good idea for how to work around a stuck location - it could just be the time of night here, but I couldn't think of a way to skip a location! #option bootloader 6 should do the trick. The downside to that approach is that the interrupt wouldn't work any more, and any code left over in locations 0 - 5 would still run when the chip is powered up.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I built a blank hex-file and burnt it to the chip, then built one full off FF and burnt that - only the 0x0005 location failed.
It's a K149BC programmer which I've had for ages and haven't had trouble with before - but then this is the first time I've use the 16F877A. It still seems to be programming other chips without fuss.
Perhaps I'll wander through the programmer's setup file and check that it's pulling the power pins in the right sequence etc.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hugh I see what you mean about the interrupts, bummer. That means changing the context save routine to start out with some nop's, ugghhh. Hopefully its a programming thing.
I've just experienced a fast timer interrupt messing things up with programming. So enabling timers after a delay at the start helped me get past this problem. This really bugged me because previous code of shorter length worked fine, added some more code, and no dice.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have a couple of 16F877A chips both of which are showing a stuck byte at memory location 0x0005. The rest of the chip appears fine (I've no idea how this happened, it just refused to programme one day).
Since the stuck location is very near the beginning of the memory space is there any way I can just jump past it - perhaps inserting a dummy test right at the beginning?
I could just buy a couple of new chips, but being part Scottish the prospect doesn't appeal half as much as working round it for free.
Thanks - Skipweasel
Try the bootloader function if this is a program memory situation like:
Ooops, 0x001 lands a vector on ORG 5 in the asm listing, so maybe 0x002 or ????
It might be worth double checking the programmer, it sounds very odd to have the same word fail in two different chips! I've had problems before where a program was trying to toggle the programming pins (PORTB.6 or B.7) at a very early stage, which was stopping my PICkit 2 from working properly. A few clicks on the Erase button seemed to fix it - eventually the PICkit must have put the chip in to programming mode before the program could start up. Have you got anything attached to the programming pins other than the programmer?
Also, are you sure it's location 5 only? When you recompile a GCBASIC program, that is the first location that will change from the old version. (Locations 0 - 4 are typically 2805 3FFF 3FFF 3FFF 0008 on any 12F/16F.) Could there be other locations after 5 that are also not programming correctly?
Kent, that's a good idea for how to work around a stuck location - it could just be the time of night here, but I couldn't think of a way to skip a location! #option bootloader 6 should do the trick. The downside to that approach is that the interrupt wouldn't work any more, and any code left over in locations 0 - 5 would still run when the chip is powered up.
I built a blank hex-file and burnt it to the chip, then built one full off FF and burnt that - only the 0x0005 location failed.
It's a K149BC programmer which I've had for ages and haven't had trouble with before - but then this is the first time I've use the 16F877A. It still seems to be programming other chips without fuss.
Perhaps I'll wander through the programmer's setup file and check that it's pulling the power pins in the right sequence etc.
Hugh I see what you mean about the interrupts, bummer. That means changing the context save routine to start out with some nop's, ugghhh. Hopefully its a programming thing.
I've just experienced a fast timer interrupt messing things up with programming. So enabling timers after a delay at the start helped me get past this problem. This really bugged me because previous code of shorter length worked fine, added some more code, and no dice.