Mloader erros

[WingNut]

I've had flowcode 6 for a number of weeks and have managed to get everything programming and functioning as you'd expect. However, I have been fidlling with a little program to mimic the red and blue flashing lights of an emg vehicle, so figuring out timing is an important part of how the lights look. Hence I need to program and test. I've been using a PIC12f675. The device gets programmed ok the first time but also gives an error stating that the code could not be verified possibly due to code protect. Also since programming I cannot delete or reprogram the device. Code protect is not on and I have set the EB006-9 for ext 9v power. The chip is removed and placed into breadboard for testing. I use an antistatic bracelet and tools for removal and insertion of the chip.
Is this programmer defective. I've destroyed about 5 12f675's trying to figure this out

[Benj]

Hello,

This seems strange, the 12F675 is quite a common chip for us. What release version of Flowcode are you using? You can find out by clicking Help -> About.

Also you can run mLoader in stand alone GUI mode by running it from the "Flowcode 6/Tools/mLoader" directory. What version of mLoader do you have and can you autodetect the chip.

I would also like to know the jumper settings on your EB006 hardware and I will try and replicate your setup here.

Finally how about the 16F1937 device that came with the board is that functioning correctly?

[WingNut]

Hi, Im using flowcode 6.1.2.0 purchased just before Christmas.
MLoader version 3.2.3.7
Jumpers are 5v, PSU
USB programming and oscillator.
Ext power suppy is 9v dc
I couldn't see that flowcode was erasing the chip before reprogramming it so I started to use Mloader GUI to erase and it wouldn't autodetect.
I dont want to try the 16f1937 in case it wont erase

[WingNut]

Hi Benj. Did you get anywhere or do I have possibly a faulty programmer?

[Benj]

Hello,

I have tried a 12F675 here and it is working well and allowing multiple erase and re-programs without any problems.

Please can you attach your hex file and the Flowcode project if your using Flowcode and I will check it is not the hex file that is somehow causing the issue.

The EB006 is well tested and is known to work well so I doubt that it is this that has a problem. Once I have tested your hex file I should know more.

[WingNut]

Files attached. I'm afraid I don't share your opinion on things which are necessarily 'known to work well', having repaired CNC machines for 30 years. But have a look at the files

[Benj]

Hello,

I have programmed your hex file and this has caused a problem with my chip. I will investigate and let you know how I get on.

[medelec35]

If I remember correctly, this is an issue if target devices like 12F675 and 16F883 not able to be reprogrammed by some programmers if both MCLR and OSC set to internal.

Could that be the issue?

[WingNut]

Thanks for the efforts on this. Both your replies sort of suggest an issue with the chip, some sort of bug

[medelec35]

Just found this on the microchip forums:

There appears to be a feature / problem with my setup at least, probably for the OP too, and maybe for others.

This feature makes it seem, at first glance, as if the PIC12F629 will only program once.

What actually happens is that after the second programming cycle, the word at address 0x3ff mysteriously gets set to 0x0000.

It is this loss of the OSCCAL calibration word that then causes the OPs program to fail to run.

Commenting out the call to 0x3ff, means that the program will run, whether or not the word at 0x3ff has been set to 0.

(Of course the oscillator will no longer be calibrated)

I do not understand WHY the value at 0x3ff gets corrupted, but after a second programming using MPLAB IDE, program memory read will show a value of 0x0000 stored at address 0x3ff.

I suspect that this "feature" may be a bug, but would want verification from others to be sure.

I have tried various different programmer settings, but the problem seems to be repeatable, on my setup at least.

I imagine that the multiple power up operations during programming may be part of the cause, but I have not yet tried providing external power to get more insight into what is hapening.

My setup is:

Fairly old PIC12F629. Revision 0x10 reported by MPLAB PICkit 2 window
MPLAB v8.40
Genuine Microchip PICkit2, the old one with the black button, modified by adding debug pull-down resistors
Windows Vista 32 Home Premium

Anyone else out there that has the same problem? or am I missing something?

EDIT: Update:

I have now tried providing the target with power, and I can see similar symptoms to those descibed in this thread.

Programming the chip for the second time using MPLAB seems to cause very odd things to happen.

Sometimes code protect config bits appears to get set. If code protections stays off, then unused program words show as 0x0000.

All too weird for me. I just don't understand what is going on.

Standalone PK2 applications appears to work perfectly. Only programming via IDE fails, and even then, only second time around.

Tried another chip - problems remain.

EDIT2: Possible Workaround:

Seems that enabling MCLR resolves the issues. I have seen reports in other threads where MCLR_OFF with internal oscillator prevents erase (though I have never experienced this problem for myself), but if my experiments are valid, it seems as if the MCLR_OFF / internal oscillator combination may cause other issues too.

Still confused though.

Still don't really understand it.

Why does the standalone PK2 program seem to work in all situations, but IDE programming seems to have issues?

❞


Probably it is because the stand alone app is using the correct Vpp before Vdd program entry mode that is required when MCLR = I/O and INTOSC is configured.

What can and does happen when you have these two config settings is that with a Vdd first program entry mode the PIC is not firmly held in RESET and with the internal oscillator runnning it can, and as often as not, actually start the PIC executing code. As a result the PICs PROGRAM COUNTER is INCREMENTED. Then the Vpp rises enough to put the PIC in program mode HOWEVER THE PICs PROGRAM COUNTER IS NOT POINTING TO 0x000 any more and program mode entry does not reset it either. As a result of this your code is programmed into the PIC offset from where it should be. Any combination of Code, OSCAL, ID config and data EEPROM where applicable, can be shifted. This is why the OSCAL goes missing. It is actually written to somewhere it should not be, usually to a non existent address.

There are a number of counter measures to prevent this from happening. One is the VPP first program entry mode. This is covered in the programming specs and it is the most convenient and useful solution as it allows you to have MCLR = I/O and INTOSC enabled without problems. My guess is that the stand alone App is correctly using this mode while the MPLAB IDE is not.

Other counter measures are to avoid the MCLR = I/O and INTOSC = enabled condition as Dariog pointed out but this is not always very convenient.

In some of the later base and mid range PIC families there is another solution. A RESET PROGRAM COUNTER command has been added to the programming commands.

There is some information about this problem in the programming specs that covers this.

So, to me it really looks like the programming script in MPLAB is not correct while in the stand alone app it is.

[WingNut]

Thanks medelec. Reading the device back I get a config error (invalid config) on pickit2 and mloader. The hex file output from flowcode when loaded also gives the same error
Which kind of fits with what you've posted. The program works however!