stumbling over XC8 syntax and OSCCAL management

[bxdobs]

not new to PIC or MCU's but working with old W7 and PicKit3 ... meaning I had to reload mplax 5.3 with XC8 2.1 ... perhaps why the online help isn't always working for me

trying to work with a 12F629 with intosc ... provided CP is ON the factory OSCCAL might still be available BUT if CP is OFF it is presumably destroyed (which is detailed in many places) ... there is seemingly no way to read back the factory setting ... or ... restore some form of this for production level CP chips ... could potentially write some elaborate code that pushes the Factory Value into an EEprom location BUT not sure if this is foolproof as how does one determine if 0x3FF is still valid?

MPASM used to allow reserving the final location in code so as not to overwrite the factory value ... here is an example I used to use for the 10F206 in the mid 2010's

Code: [Select]

OscCalVal CODE 0x1FF
  RES 1
my initial thought was I could throw a retlw blah at the last address OR stop using this vector and add inline code in System_Initialization that just uses some middle-of-the-road value for OSCCAL.

attempts to simulate a retlw blah at 0x3FF in XC8 by using the online XC8 Knowledge Base failed

This example fails because XC8 v2.1 doesn't recognize @ 

Code: [Select]

char _OSCCAL(void) @ 0x3FF
{
 asm("retlw 0x80");
}

This code refuses to generate any code

Code: [Select]

char _OSCCAL(void) __at(0x3FF)
{
 asm("retlw 0x80");
}

My KISS expectation is that either the XC8 Compiler or PicKit3 would have some method of NOT destroying 0x3FF plus possibly provide some way to read the contents of this address out of a virgin chip ... or ... at least determine if it is MIA ... if a call is made to 0x3FF using _OSCCAL_VAL() and the code is MIA (retlw blah missing),  presumably this would be a 0x00 (Nop) ... won't the PC roll over to 0x00 for the next instruction meaning any call to 0x3FF will invariably go back to the reset vector causing all sorts of havoc ... basically call 0x3FF over and over again until the STACK overflows (may even keep calling after a stack overflow)

[Ian.M]

The Microchip tools have to read the factory OSCAL RETLW from program memory and preserve it on the host PC  through the whole chip erase and reprogramming sequence, then write it back at the end before writing the CONFIG word.  This often goes wrong, and stupidly Microchip don't write the OSCCAL value it tried to read to a timestamped log file, nor do they allow user modification of the OSCCAL RETLW, so when it gets FUBARED, there's no easy way back.  This was so problematic that all newer PICs with an OSCCAL feature save the factory OSCCAL value in CONFIG memory space so it can be excluded from chip erase.

See Loss of OSCCAL value during programming.

If you've got a PICkit 2 its easy as its standalone software has an OSCCAL recalibration routine.   If you need to manually fiddle with OSCCAL and bandgap bits, I posted a PK2devicefile.dat [here] that lets the PICkit 2 standalone software (and I believe the  PICkit 3 standalone programmer (scripting tool) v3.10) treat the OSCCAL location as normal program memory, and also modify the bandgap calibration bits in the CONFIG word.

There's also an XC8 command line flag to disable OSCCAL handling in the startup code.  That lets you do it yourself in main() - check the reset flags to determine the type of the last reset.  If it was *NOT* a reset but a program memory wraparound, the OSCCAL RETLW is missing, so skip trying to calibrate and possibly signal an error, otherwise, in inline assembler, call 0x3FF to get the factory OSCCAL in W then stuff it in the OSCCAL SFR.

N.B. the Microchip forums are (as usual) FUBAR and borked.    They ported them to a new forum software and server and in the process managed to break many user contributed internal links. 
Read the old Microchip forum internal post number(5 or 6 numeric digits) from the broken URL and append just the number to:

Code: [Select]

http://www.microchip.com/forums/FindPost/ and you should be able to follow the broken link! 

[woofy]

Just as a side note, be careful with that retlw instruction at 3FF. It is a retlw on the 12F629 which resets to 0000. You then call 3FF to get the cal value.
On other chips such as 12F509 its a movlw instruction. The reset is at 3FF so it executes the movlf then rolls over to 0000 with the cal value already in W.
Thankfully, Microchip changed to automagically setting the cal at power up on later devices.

[bxdobs]

Update:

Corrections to my original post:

1) The MPLAB X IDE with a PicKit3 DOES provide the option to read the contents of a device

2) When  MPLAB X programs a device it appears to be automatically protecting the value at 0x3FF contrary to all the warnings about turning CP off

Had to take a few back steps ... par for the course ...
- repaired my PICDEM Lab board (Vss was never connected to the two full-length rails on either side of the breadboard) Was this by design or an MB manufacturing defect?
- repaired the breadboard which was ONLY mounted with double-sided tape and had come unstuck with at least half the shorting bars falling out ... reassembled and put two self-tapping screws in the holes that were already there for the purpose of keeping this assembly attached to the PCB (but never used)
- hooked up my PicKit 3 and started going through the options that MPLAB X IDE provided
- also modified a hex code disassembler in Excel that I built for the 10F206 to decode the 12F629 intel hex files  (bitmap for 12F629 instructions don't match the 10F206)
- the MPLAB X IDE Read to file option worked to show what is in 0x3FF on a Virgin Chip and freshly programmed chips ... the chip I read contained retlw 0x38

Not seeing a way to force MPLAB X to write back these Hex Files (bypassing the Compile/link process) ... that could allow restoring the 0x3FF locations

The chip I had been using from several years back, appears to be toast ... while MPLAB X IDE states it is a 12F629 it fails the OSCCAL test (states it has an invalid value) PLUS even after erasing the memory it still shows the same code when read back ... plus ... also fails to write/verify

Expecting that if CP was on these devices should be able to be reflashed ... CP should just disallow reading

The new Virgin Chip accepted a small bit of code and verified that MPLAB X IDE (XC8) and PicKit3 were magically maintaining the value of 0x3FF