Configuration error

My simple program compiles OK but when I try to program, I get "configuration error". I don't understand how the configuration can be in error, it is what it is, isn't it? This is my program:
code
rem device 12F675
CMCON = 7 'SETS DIGITAL MODE
TRISIO = %00111100 'MAKES GPIO.2,3,4,AND 5 AN INPUT
DEFINE OSCCAL_1K 1 'PRESERVES OSCILLATOR CALIBRATION
J VAR BYTE 'DEFINE VARIABLE J
low GPIO.0

END

If I try to erase the micro, I get "configuration error". I am using MicroCode Studio. I found Melanie's post on configuration fuses but I don't know enough to understand.

What version of PBP are you using? PM or MPASM(version?).

Have you done anything to the 12F675.inc file in the PBP directory?

I am using melabs programmer version 4.01, microcode studio version 2.3.0.0 and compiler version is picbasic pro 2.46. I don't know if that answers your question. I have not looked at the include file (or know where to find it).

Did you select the correct device in the dropdown list in MicroCodeStudio? Most programing softwares autoselect the device based on the device that the loaded .hex file was compiled for. (I don't know about the one you're using though). So, if you select the wrong device in MCS you'll get the wrong device in the programing software.

Works for me
but like HenrikOlsson said make sure you have 12f675 selected
16f628 is the default on mine

Code:

---

'****************************************************************
'*  Name    : UNTITLED.BAS                                      *
'*  Author  : grounded                                  *
'*  Notice  : Copyright (c) 2009 Copyright  *
'*          : All Rights Reserved                              *
'*  Date    : 9/15/2009                                        *
'*  Version : 1.0                                              *
'*  Notes  :                                                  *
'*          :                                                  *
'****************************************************************
rem device 12F675
CMCON = 7 'SETS DIGITAL MODE
TRISIO = %00111100 'MAKES GPIO.2,3,4,AND 5 AN INPUT
DEFINE OSCCAL_1K 1 'PRESERVES OSCILLATOR CALIBRATION
J VAR BYTE 'DEFINE VARIABLE J
low GPIO.0

END

---

I did a read on the 12F675 and it came up "code protected". How did that happen? I thought default was not protected. How could I read the memory if it was protected? I suppose I will have to throw away the two that I tried to program. I hesitate to try a 3rd 12F675 but they are cheap, thank the Lord.

Look at the program that your programmer uses. Some have a way to set the fuses there. If you have one like that find out how to disable that option. It is nothing but trouble.

Dave,

Unsure that this matters, but I had a heck-of-a fun time with an 833 chip last week, due in no small part to the programmer. Current numbers are:
Programmer 4.31
MCS 3.0.0.5
PBPro 2.50c

Microcode studio is an easy fix. The programmer should probably be upgraded, and unless somebody more literate than I takes issue, I'll say that you're ok with PBPro.

There is a "configuration" window that shows up under the "view" menu in the programmer. I've never had an issue with it, it will over-write any settings you put in the code. Is it the best way? Who the heck knows. It can make your life miserable if you are trying to do something specific and not pay attention to it.....

Hope that helps
Gary

OK, I tried a 3rd 12F675 and altho I made sure the configuration was xt_osc and not code protected, the program failed with configuration error and when I read the memory, it comes up lp osc and code protected. I don't know what to do except uninstall and re-install the program.

Hi Russ,
I use the PICKit2 and sometimes encounter that same scenario. The PICKit2 doesn't have an erase button (working from memory here as I am not home) so they say to select the chip you are using and program blank without selecting a hex file, to erase. This usually fixes the PIC and it programs when I load the hex. Crazy though it seems, when I get one like that my old JDM Clone won't erase it either.

Quote:

---

Originally Posted by Russ Kincaid

OK, I tried a 3rd 12F675 and altho I made sure the configuration was xt_osc and not code protected, the program failed with configuration error and when I read the memory, it comes up lp osc and code protected. I don't know what to do except uninstall and re-install the program.

---

What programmer are you using?

Quote:

---

The PICKit2 doesn't have an erase button

---

Mine does :)

Russ,

Take it to the step where you actually program the chip, press "view" and open the "configuration" window, and post what the settings are, here, would you? I'm interested in what it's telling you.....
By default, they should match -exactly- the listing in the 12f675.inc file in c:\pbp (or wherever it lives)
If you've changed them in the config window and saved it, then the saved values will be the default.

By way of example, you should have an option for setting the osc. The default may be XT, but you can change it to INTOSC and save the settings. Quite handy (I can see Dave cringing right now - sorry) handy if you never plan to use any other compiler...... not so handy if the code needs to be portable.

I am having quite a time with some code that makes Thomas the Tank Engine look complex. Oddly enough it's a 12f675. AND, the routines are simple and have been used a few times, not precisely the same, but the methodology. Now it won't run. I loaded a working file into the same chip on the same development board and it won't run either. The working file was built last week, and the MeProg software upgraded shortly thereafter.

Gary

Any time I try to program a 12F675, the default configuration is LP osc and code protected.


If I change the configuration to EXTOSC and NOT PROTECTED and try to program, I get a configuration error.


Now, when I read the part, the configuration changes to LP osc and code protected.

I am using the Melabs programmer. I can make a jpg image of the configuration window but don't know how to post it.

Below the message box when you reply there is a "manage attachment" button.

Sounds like a programming cable problem.

If you have nothing connected to the programmer, and try to read back a 12F675, it'll show these configs.

Code:

---

Oscillator      LP
Watchdog timer  Disabled
Powerup timer  Enabled
MCLR Pin        Input Pin
Brown out      Disabled
Code protect    Protected
Data EEPROM    Protected

---

And it'll show all 0000's in the code window.

Check the connections again, especially at the 10-pin connector on the programmer.
Make sure the connector is alligned correctly.
<br>

Thanks, Darryl but the connector has not been messed with and it worked OK before. The read does read the hex file that was loaded.

OK, if it reads the memory then it wasn't the cable.

Quote:

---

I am using melabs programmer version 4.01 ...

---

You might try the latest version of meProg which is up to version 4.31 now.

The beta can be downloaded here ...
http://www.melabs.com/support/progsoft.htm

hth,

I did download the beta programmer and tried to program a 12F675 that had already been successfully programmed. First I read the memory; it was 3FFF in all locations. That was not correct but I tried to program it anyway. The process went smoothly and verified OK. I then read the memory; it was 3FFF all over. I clicked on the verify icon; it reports an error. Is this another IC for the dust bin?

Quote:

---

Originally Posted by Russ Kincaid

I did download the beta programmer and tried to program a 12F675 that had already been successfully programmed. First I read the memory; it was 3FFF in all locations. That was not correct but I tried to program it anyway. The process went smoothly and verified OK. I then read the memory; it was 3FFF all over. I clicked on the verify icon; it reports an error. Is this another IC for the dust bin?

---

You can erase them don't throw them away all you have to do is open the pickit2 software and turn code protect off and then erase the chip.

The best way to do it is place the 12f675 in a solderless bread board fire up the pickit2 and reset code protect.

If it don't let you put a new chip in first let the pickit2 detect it then remove it and place you locked chip in then unlock and erase

You don't have microcode set for the right chip is why this is happen. What happen to me is that it set for default which is 16f628 and I changed it to the 12f675 before I compiled it still built for the 16f628
I then ended with a locked chip I then clean out the folder and started over saved the project as 12f675 from the start and it worked fine

be80be,
If the OP was using a PicKit2 ...
To bad he is not.

Quote:

---

Originally Posted by Russ Kincaid

... and tried to program a 12F675 that had already been successfully programmed. ...

---

Curious ...

Do you know if the program that was already loaded in it was using the Internal Oscillator with MCLR disabled?

I've had some difficult times trying to reprogram 675's and F88's after that scenario.
But I was able to get them back by turning on power to the chip at just the right time in the programming sequence. Took 10-15 or more tries each, but did get them all back.
<br>

Quote:

---

Originally Posted by Darrel Taylor

Curious ...

Do you know if the program that was already loaded in it was using the Internal Oscillator with MCLR disabled?

I've had some difficult times trying to reprogram 675's and F88's after that scenario.
But I was able to get them back by turning on power to the chip at just the right time in the programming sequence. Took 10-15 or more tries each, but did get them all back.
<br>

---

The only chips i have had problems with has been 12f675 16f88 and 18f1320
what happens on the 16f88 and 18f1320 is you set the configure for ex-osc
and have none

Also take a look at...

http://www.picbasic.co.uk/forum/show...=&threadid=171

Post #13 "Conclusion"

Some 'Micropower' PICs when set to INTERNAL OSC and INTERNAL MCLR can start executing their code whilst sitting in your programmers socket... for example, your programmer has just applied power (say for a verify cycle) and the damn thing starts executing it's code whilst sitting in the socket rather than doing what the programmer expects it to do...

Just added that as a reminder of a phenomenom first experienced six years ago... and for folks to be mindful of what could happen...

Thanks, Melanie, I think you have explained my problem. I don't understand why this 12F675 (which still has not been removed from the ZIF socket) now generates this error message: "target device does not match selected device". I only get this error on program and erase; verify, read and blank check do not produce an error.

I looks to me that I need to get a PicKit2 in order to salvage these devices.

Try this... erase the PIC (so it has no code - and if you're able at the same time preset XT OSC and EXTERNAL MCLR). Does it then still give you an error?

From what I remember six years ago, some micropower PICs coupled with some programmers gave problems. I recall I had a problem, but it was fixed when I reported it to the Vendor that supplied the programmer, and they came out with a new version of programming software. Even now, some PICs (even some batches from PICs that hitherto never gave problems) require to be ERASED before programming, so as default I set ERASE BEFORE PROGRAMMING on everything.

When you WRITE to your PIC (eg ERASE and PROGRAM) it is possible the programmer is trying to verify that your PIC is the one you selected, before it starts writing to the PIC (also because different devices also use different programming algorythms). If the PIC is off doing it's own thing (being powered by the programmer and running on INTOSC+INTMCLR) then it may not be giving the expected response to the programmer in the time slot alotted. In my programmer software I have the ability to DISABLE or ENABLE the "DEVICE ID CHECK". If you have that option on yours, DISABLE it. The chances are that READ operations (ie READ or VERIFY) don't check the device ID.

OK!
Here you go Russ.

I remembered there was one of those 12F675's that I couldn't recover, and amazingly I found it again.
It still had the same problem, couldn't program it, couldn't read the configs.

I put it in a breadboard, connected a 7805 to the VPP voltage from the meLabs programmer, with the 5V out going to VDD on the chip, so that the chip gets VPP before VDD. This is the sequence described in the programming spec.

It now programs, erases, reads, does everything perfect.

I've loaded the old program again and saw the same programming problem. Then hooked up the 7805 and wala it works.

Hope this works for you too.

http://www.pbpgroup.com/files/675_7805.GIF

Thanks for the idea, Darrel. While looking for a breadboard to try it, I found a PC board labeled "PIC12F675 programmer" It had my name on it but I have no memory of designing or building it. I checked the file date: it was March 2006, so I must have had a problem at that time and searched for a solution. This is the schematic:


I tried one of the bad devices and got an error: "device does not match target device", so I tried a brand new PIC12F675 and only tried to erase it. Still got the error, so I think the Melabs USB programmer has bit the dust.

Quote:

---

Originally Posted by Russ Kincaid

... so I think the Melabs USB programmer has bit the dust.

---

Maybe, but I'm not sure yet.

It may just be something that works out right in the physical wiring,
but the Pins in the schematic don't seem to correspond to the meLabs 10-pin connector.

http://www.pbpgroup.com/files/meLabs_10pin.GIF<img src="http://www.picbasic.co.uk/forum/attachment.php?attachmentid=3652&d=1253393140" />

Worth another look.
<br>