Pic Programming Errors

[Malc C]

Guys, I'm trying to help a fellow poster who has just got into PIC programming. He has a JDM programmer (as do I ) and we are both using PicBASIC pro.

I wrote the folloing simple test program for him, compiled it using MPSAM (linked vis the Microcode studio software) and loaded the resulting HEX file into a 12F675 via my Microchip PicKIT1 programmer without any errors. The LED on GPIO 0 (pin 7) sat there flashing away for all its worth :)


@ __CONFIG _INTRC_OSC_NOCLKOUT & _WDT_ON & _PWRTE_ON & _MCLRE_OFF & _BODEN_ON

TRISIO.0 = 0 'Set GPIO.0 to output.
ANSEL.0 = 0 'Set GPIO.0 to digital
CMCON = 7
VRCON = 0 ' Voltage reference disabled
OPTION_REG.7 = 0


led var GPIO.0

main:
high LED
pause 1000
low led
pause 1000
goto main



However if we use the JDM programmer and other software such as WinpicPRO, ICPROG and PICpgm the programming fails, which I think is down to the config bits or OSCAL values. As I can regenerate the OSCAL and set the Bandigap via the PicKIT1 software I've tried all manor of settings, copied the DEV files to the same folder as Winpic, pointed Winpic to the MPLAB dev folder.. and entered the same HEX shown for the config bits in the PicKIT1 software into the Winpic software and it still fails.

I've attached the BAS file and the resulting HEX file, and hopefully somone can shed some light on what settings need to be appled to Winpic to get it to program the 12F675

[Gary Warner]

Set the watch dog timer to off; _WDT_OFF.

[Malc C]

Gary, Thanks for that, however ....

Changed the setting and re-compiled - loaded into Winpic and it errored again. so I re-calibrated the OSCAL and loaded the code via the PicKIT software and loaded the code fine.

I then stuck that chip in the JDM programmer and used Winpic to program the code and it errored again - reported OSCAL or Bandigap errors.

However now for the quirky bit....I erased the chip in the PicKIT - I then place dthe PIC back in to the JDM and launched Winpic again - this time it programmed fine !! - I hadn't changed any settings to the previous session...

I've attached some images which might make sence to someone, and hopefully the other board member might be able to use to test his code

Thanks

[Gary Warner]

I just noticed the WDT thing. I use PicBasic's ME Labs compiler and serial programmer. So, your problem is a bit hard for me to follow. Someone else is going to have to jump in here.

Gary
--

[Mr.RC-CAM]

I don't use your programming software, but from the looks of the screenshots, yours is not setup to save the OSCAL and Bandgap before erasure. It seems to me that you should think about doing that. This will help ensure that the factory installed values are reused during the programming.

From my experience, the biggest fault of the hobby programming systems is that they have a very casual treatment of the factory installed values. This causes a lot of grief, at least as measured by the emails I get. In contrast, the commercial programming systems go out of their way to ensure these values are retained/restored during each reflash cycle.

[Malc C]

Thanks for your comments, and I couldn't agree more, but the price difference between hobby programmers and commercial / proffessional is such that most hobbiest are stuck with these problems. The PicKIT programmer saves the factory set values for the OSCAL and bandgap and is a very powerful programmer behind the simple fire and forget GUI. Its only drawback is the number of PICs it supports, having no ISCP socket and only a 14 pin DIL for onbard programming / testing.

For me the problem is/was that I've just done a fresh re-install of windows and all the applications and it was a long time ago when I had Winpic set up correctly and my poor old grey cells are finding it harder to remember things as I get older ;)

[Mr.RC-CAM]

the price difference between hobby programmers and commercial / professional is such that most hobbyist are stuck with these problems. What is frustrating is that the solution is just a simple matter of having the app creator change the default settings of the programming app so that it protects the factory data.

If I had to guess, the "no special treatment for..." check boxes on your last screenshot are involved with this. If not, the best recourse is to record the OSCAL and Bandgap for each of your new/unused PIC chips and hang on to the info for later recall. That way you can ensure that the factory info can be manually restored as you re-flash the parts. If using the factory data does not help, then an email to the programming system author would probably be needed (bug report).

[Malc C]

Again, I agree that if its such a simple thing to do, then why do so many of these free applications not feature this function.

I gather that the OSCAL and Bandgap settings are not critical unless you require precision timing, but if you have overwritten the config bits and can't write them back, or regenerate the OSCAL due to hardware limitations, how can you reset the pic so that it can be re-flashed. I assume that a pic that has had its factory settings over-written will not function properly again until the OSCAL is reset / regenerated ?

[Mr.RC-CAM]

Again, I agree that if its such a simple thing to do, then why do so many of these free applications not feature this function.The authors that create the free apps deserve a lot of credit for their efforts. But, I think some of them are just too tired to refine the creature features, or have strong opinions about how their app should work.

Case in point: A couple years ago I bought a cheap programmer just so I could understand why so many folks were having problems with them. I downloaded a VERY popular freeware app program to run it. Within moment of using it, I found a bug concerning its failure to properly write the ID Locations (it was treating it like it was a 'C' part, rather then the 'F' part I was using).

I emailed the author and reported the problem. He wrote back and claimed nothing was wrong. I politely forwarded the spec from the data sheet. He then admitted that he had not looked at the spec, and despite being an issue, he felt his method was best. I suspect he was either too tired of working on the app too care, or just felt his way superseded Microchip's.

Beyond that, my experience with the programming software showed that it was easy for a user to inadvertently mess up the chip programming. Even I experienced that, and I have been burning chips since the 1970's. It just seemed so simple {to me} to make the user interface more goof proof, but I don't think the authors are in to that.

I assume that a pic that has had its factory settings over-written will not function properly again until the OSCAL is reset / regenerated ?As far as I know, outlandish values in these locations will not prevent the chip from working. I just think you will have incorrect timing or brownout thresholds (but this is a good question to throw at the Microchip tech support group). If you don't care about timing, and are not using the brownout, then perhaps casual erasure is not an issue at all. However, it is unusal to not require accurate timing, at least in projects related to R/C projects. I suspect that 99% of my R/C designs would misbehave if the OSCAL was sufficiently buggered up.

It is not all that bad though. As long as the user is careful to restore the factory values then I think half the battle is won. So, if the programming app s/w cannot do this for you, then just manually enter the factory data as you reflash.

It might be best to report your problem to the app author. Maybe there is a bug that needs attention and maybe he/she will want to fix it.

[Malc C]

Thanks once again for your comments. Maybe I'll drop the author an e-mail, or possibly the other poster may wish to take the matter up directly, afterall it is his PICs that are possibly, how did you put it "buggered" :) :)