CCS C works on proteus not on physical PIC.

[ViperARG]

Hi my name is Agustin, I'm a noob on PIC MCU´s. I have quite many pics mcu´s and none seem to work with CCS, they work only with XC8, but I really can´t program with XC8 because I have to code way more than CCS and is more complicated. I downloaded working codes from projects on youtube and internet in general and they seem to work for the people who made the videos and they work on proteus in my PC. But when I take the .HEX and UPLOAD it ( yes it says program complete ) with my pickit 3 but it won't do a thing, not even blink an LED. Then I program myself the chip on XC8 and start working like a charm, I don't know what I'm doing wrong cause I have pic12,16,18 and it just wont work on CCS, is not the code, is not the pic, is not the pickit3. It has to be an option where I'm missing or something, it´s been 2 entire days trying to figure this out with no success is driving me crazy. Please help =(

proof that it uploads the code into the chip, and same HEX works on proteus. MPLAB IPE 3.50

Programming...

The following memory area(s) will be programmed:
program memory: start address = 0x0, end address = 0x47
configuration memory
Programming/Verify complete
2017-01-08 00:03:34 -0300 - Programming complete
Pass Count: 11

[PCM programmer]

[ViperARG]

[PCM programmer]

1. What is your CCS compiler version ? It's given at the top of the .LST
file. It's a 4-digit number such as 5.066 or similar.

2. What is the Vdd voltage of your PIC board. Is it +5v ?

3. Is it possible that you have erased the last address location in the
12F675 (0x3FF) ? That location holds a RETLW instruction that returns
the OSCCAL value. CCS adds code to call this location near the start
of your program. If it's not there, your program will not run properly.

You can use the Pickit3 to read the program memory and then view it.
Look at address 0x3FF. What is there ? is it a number or is it erased ?
If it's erased, it will be 0x3FFF.

[Ttelmah]

I suspect PCM_programmer's suggestion that you have erased the chip fully, is probably the cause.
I've just tried this with 3.249, 4.099, 4.141, and 5.066, and with all it runs fine.

So, do what he says and read what is in location 0x3FF.

Most programmers have an option to save this value automatically for you to prevent this happening.

[ViperARG]

[Ttelmah]

On the 675, this:
"Target has invalid calibration data"

is saying what is wrong.

On these chips the top instruction in memory, is programmed at the factory. It is a RETLW xx
where 'xx' is the calibration data for the chip.

The code at the start calls this to get the calibration for the chip. If the instruction has been erased, the chip will then hang.

Fortunately you can write a value back (but the clock will then be uncalibrated). Add:

#rom 0x3FF = {0x3480}

Which will put the 'mid range' value into the chip.

Beware though. As soon as you have done this, remove it from your code. Otherwise every chip you program with this code will have it's calibration destroyed. Then look at your programmer and see if it has an option to preserve the calibration data, to avoid this happening again.

The 877a, does not have an internal oscillator. Needs a crystal or something similar before it can work.

Proteus will believe you if you say 'chip is running at xxMHz'. The real chip won't....

[ViperARG]

I gonna try it and tell you how it went, many thanks to you and the people of this community, coming from Arduino IDE this is some scary stuff. Everything is so raw =D.

[temtronic]

comment.
Three things you MUST know...

1) Never, ever trust Proteus. It's full of bugs, errors and faulty DRCs ! See PIC101 sticky.

2) Never believe ANY simulator! Real World testing is the ONLY testing that is TRUE!

3) Never, ever 'think' a 'Wizard' is all powerful ! He (she/it/??) will configure a PIC to what HE wants NOT what you NEED !

PICs are very powerful and the CCS compiler does a great job of getting C into them ! Mind you I'm biased as I started with V2.534, 20 years ago ???? They sent a spiral wound manual back then !

sigh...
Jay

[ViperARG]

[temtronic]

re: calibration


#rom 0x3FF = {0x3480}

Which will put the 'mid range' value into the chip.

As Mr T points out, x3480 is the middle of the callibration.

You need to perform some tests, changing the value until the calibration is correct. Microchip explains how to do this in the datasheet.

Every PIC will have a different number stored even within 'batch lots'. Also the RC oscillator is temperature sensitive( again check the datasheet) to '4MHz' won't be 4MHz at say 5*F ! This WILL change ALL 'timings', so if you need accurate timing, use a xtal and 2 caps.

Jay

[asmboy]

Make the change to preserve calibration in your programmer.

Then throw away the chip you had trouble with...

The chip HAS to be cheaper than
the time you put into trying to rescue it.

I just spent enough non-billable time in writing the
two sentences above to pay for several new chips .....
LOL!

[temtronic]

yup, at even a lowly $60/hr for R&D iv'e donated a LOT of my time to this project

[Ttelmah]

Some comments:
First you now begin to see how Proteus can mislead you.
Second erasing the calibration memory, is very carefully discussed in the data sheet. Including telling you that most programmers will have an option to save this.
Accuracy of the internal oscillator will be a few percent at best, but obviously now will be much worse. You need to simply write a program that writes to the OSCCAL register, perhaps under keyboard control and change the calibration (if it is running fast, reduce the value), until the chip runs reasonably. Once it does, record the value, and then write this to the calibration.

[ViperARG]