Crystals

Could be Nigel ... i ran into this problem on one of the first projects i ever did on PIC's, and i didnt know to much about what i was doing... its a few years ago also, so i dont remeber the details exactly...

I do seem to remeber the information i found about this problem relating it to the chip arcitecture, but i could be completly wrong about this, so dont take my word for it.

anyways, was just an idea, a thing to look into ... ive had this problem, and the #build(reset=0x002) solved it. Thought i should share it, just in case it would work again :=)

One other thing: if i remeber right, in mplab ide you can chose to only overwrite the part of program memory you are actualy using... If looking at the ROM location counter on mplab i can see it actualy stops before location 0x7fff. I would asume it means it doesnt overwrite the entire ROM. If you do this, then wouldnt old code be left in the unwritten part of the ROM, thus making the senario i portrad earlier possible (the "random" goto thing). ofcourse it would be running parts of old code, and not random garbage, but the results could be the same.

Again .. just an idea. Please corect me if im wrong

No disrespect, but this is a problem with using C when you don't already have a reasonable working knowledge of assembler - you're trying to work around a problem without knowing where the problem might lie, examination of the assembler code produced would probably explain what was happening.

By the way, it's common practice for the first instruction (at 0x0000) in any PIC program to be a jump - because the interrupt vector on these PIC's is at 0x0004, and you usually want to jump over that. But if the PIC is reseting and reaching that address, then it's working correctly anyway.

Have you,

tried it with another power supply?

tried it with another cristal?

tried to add the necessary instructions to set (and reset after a well calibrated delay) an output port pin, to be checked with a scope or a logic probe?

post the object hex code produced by your compiler...so we can disassemble it and see what's going on...

I assume that you are using the "A" version of the chip and the programmer is also set for programming the "A" version...I say this because from your posts, you have coded up for the "A" version and both of my Xeltec programmers don't like programming the "A" version if it's not an "A" version chip in the socket. The differences in the chip are minor as far as I am aware, but it may be significant in the way your compiler produces the code for each.

ombrastein said:

One other thing: if i remeber right, in mplab ide you can chose to only overwrite the part of program memory you are actualy using... If looking at the ROM location counter on mplab i can see it actualy stops before location 0x7fff. I would asume it means it doesnt overwrite the entire ROM. If you do this, then wouldnt old code be left in the unwritten part of the ROM, thus making the senario i portrad earlier possible (the "random" goto thing). ofcourse it would be running parts of old code, and not random garbage, but the results could be the same.

Again .. just an idea. Please corect me if im wrong

Click to expand...

When you write to a PIC, the first step of the programming process is to erase the chip completely, so you can't leave random instructions anywhere. The exception to this is if you program using a bootloader, when it obviously can't be erased as the bootloader must remain in place (but this is an internal programming process of the target chip). Normal external programming, just like an EPROM, can only change 'ones' to 'zeros', it can't 'unprogram' a 'zero' to a 'one' - so you have to erase the PIC to all 'ones' before programming.


If (and it's a big IF), you only want to change any existing bits from 'one' to 'zero', in an already programmed PIC, then that is perfectly possible - and even works on OTP devices - assuming you can find some software that allows you to do it?. But generally the software won't allow that - but I've done it, as I have the source code for my programmer.

I had a suspison i was wrong about that one

Thx for clearing that up.
Ill look at the assembly code from ccs compiler and see if i can figure out what caused the strange behavior. Im sure you are right about that too. Its probably a bug in the ccs compiler and not the chip itself. Wish i could find the site where i found this problem originaly, but i cant seem to find it again.

Anyways, if it is related to ccs compiler then this has no relevance to the problem this thread is about.

Hi All

Would just like to say thanks very much for all your comments and help.

I managed to borrow a 100mhz oscilloscope and allowed me to see the crystal actually working on my circuit. I also followed the diagram on page 150 of the pic16f877a datasheet which had a few resistors/cap for the MCLR line.

Unfortunately I was still unable to see any change. I went back to the drawing board and re-checked my fuse settings and found a value in the datasheet call - 'Low Volts Program'

I unchecked this, and this solved all the issues. The circuit imediately puts +5v on the required pins \o/

Again thanks for your time.

Rich