Matrix user forums

Please help!

I have been trying to send my program to a PIC12F629. It runs okay in Flowcode 3 simulation, but when I try to transfer it to the chip in the 8/14 pin slot on the version 3 board, it fails with the message below.
(If I transfer the same program to a PIC16F648A in the 18 pin slot, it transfers and runs okay).
Any help would be appreciated- I am stuck!

Thanks,

Michael
----------------------------------------------------------

Launching the compiler...

BoostC Optimizing C Compiler Version 6.52 (for PIC16 architecture)
http://www.sourceboost.com
Copyright(C) 2004-2006 Pavel Baranov
Copyright(C) 2004-2006 David Hobday

Licensed to FlowCode User under Single user Pro License for 1 node(s)
Limitations: PIC12,PIC16 max code size:Unlimited, max RAM banks:Unlimited
.
.
.
Starting preprocessor: "C:\Flowcode working\BoostC\pp.exe"
.
.
"C:\Flowcode original programs\Flowcode backup of working files\Tutorials\008 pic12f629.c" -i "C:\Flowcode working\BoostC\include" -d _PIC12F629 -la -c2 -o "008 pic12f629.pp" -v -d _BOOSTC -d _PIC16


.........

008 pic12f629.c success

success

Return code = 0

Launching the linker/assembler...

BoostLink Optimizing Linker Version 6.52
http://www.sourceboost.com
Copyright(C) 2004-2006 Pavel Baranov
Copyright(C) 2004-2006 David Hobday


Warning unreferenced functions removed:
FCM_INTERRUPT_TMR0 in: C:\Flowcode original programs\Flowcode backup of working files\Tutorials\008 pic12f629.c
FCM_INTERRUPT_PORTB in: C:\Flowcode original programs\Flowcode backup of working files\Tutorials\008 pic12f629.c

Building CASM file

Memory Usage Report
===================
RAM available:64 bytes, used:64 bytes (100.0%), free:0 bytes (0.0%),
Heap size:0 bytes, Heap max single alloc:0 bytes
ROM available:1024 words, used:762 words (74.5%), free:262 words (25.5%)


Successful

Return code = 0

Launching the programmer...

Sending program...
Saving OSCCAL
Erasing the PICmicro
Restoring OSCCAL
Writing program memory

.........

Writing configuration memory
Writing id-locations
Reading program memory
Reading configuration memory
Finished reading PICmicro contents
Programming failed:

Configuration word(s) check failed
Program memory check failed

(NOTE: if the PIC is code-protected, this message will be
displayed even if the program has been sent correctly)
That took 5.391 seconds

Return code = 0

FINISHED
--------------------------------------------------------------------------------

I think there is a problem with some of the FCD files for low pin-count chips. I'll email a new one for the '629 now...

Steve,

Thanks for the file.
Unfortunately I still get the same error/fail messages. I have placed the new file in the correct folder, because when I go to Flowcode->Chip->Target, it shows both the new 12F629.fcd file and the older one (which I had renamed to 12F629old.fcd).
Any ideas? I am desperate!
Thanks,

Michael

Please send us the FCF, C and HEX files for your program to our support email address and we'll have a look.

In the FCD file for the 12F629, try changing this line:
to this:

Hi Steve,
I also tried a very simple Flowcode program-

Begin
Output to led (Port A1)
Delay 1 second
End

Still have the same problem. ie: Runs okay under simulation, compiles ok, but fails on transfer to pic12f629 chip.

Any ideas?

Best regards,

Michael

Michael,

Did this work??

steve wrote:In the FCD file for the 12F629, try changing this line:

Code: Select all

OutputCmdOneBit="trisio = trisio & %i;\nif (%o)\n\tgpio = gpio & %i | %m;\nelse\n\tgpio = gpio & %i;\n"

to this:

Code: Select all

OutputCmdOneBit="trisio = trisio & %i;\nif (%o)\n\tgpio = (gpio & %i) | %m;\nelse\n\tgpio = gpio & %i;\n"

If not, does a program transfer to the PIC that outputs to the complete port? For example, "Output 0xFF to PORTA"?

Hi Steve,

I tried:

Code:
OutputCmdOneBit="trisio = trisio & %i;\nif (%o)\n\tgpio = (gpio & %i) | %m;\nelse\n\tgpio = gpio & %i;\n"

and unfortunately it did not work.

I also tried it with the original fcd file and the second fcd file you sent the other day.
I then tried your suggestion of Outputting to all ports- still no sucess.

Okay, in desperation I made the simplest program possible:

Begin
Delay 1 second
End

Works on simulation but when trying to send to the chip and using any of the 3 fcd files- No success.

I have 2 pic12f629 chips and tried both- no difference.

Any ideas?

Best regards

Michael

Hi Micheal,

I think I've got it. There is a problem with PPP which means it does not restore the OSCCAL properly under certain circumstances.

Here's the workaround...

In Flowcode, go to "Chip..Configure" and then select the "Options..." button. About 3/4 of the way down on the left hand side is an option "Use IncX Cmd" - make sure that this is unticked and then press "OK".

This should solve the problem, but will increase the programming time by a fair amount.

Please let me know if this works for you.

I will look into why PPP has developed this bug and hopefully provide a proper fix for it.

Hi Steve,

Thanks for the idea.
I just tried "Use IncX Cmd" off- but unfortunately, no success.
Also tried it with all 3 different .fcd files. No success.
It did take slightly longer to compile, but we are only talking a couple of seconds.

I guess it's back to the drawing board.


Best regards,

Michael

Hi Steve,

I had an idea.
I looked over the documentation for E-blocks Version 3 development board (Document code: HP488-30-3).
On page 14 there are pin out details for the different devices.
On page 16 at the top, there are 2 pictures- one for the 8 pin device and one for the 14 pin device.
It appears to me that they are mislabelled?
I think that the top picture should read 8 pin device (it is marked 14 pin), and the picture below should read 14 pin device.
I noticed this because the second picture labelled 8 pin device refers to pins 12 and 13- slightly difficult in this time/space dimension?
The 8 pin port lines seem to be correctly named though.....GP0 GP1 and GP2.

I am suggesting this because maybe this mislabelling (referring to pins 12 and 13 on a 8 pin device) was somehow carried through in the programming/writing of PPP or the .fcd file?????

Hope it helps,
Best regards,

Michael

Hi Michael,

I'm surprised the "IncX" fix did not work for you. I finally replicated the problem here and this was the fix that worked for me. Remember you need to click "ok" to both the "options" screen and the "config" screen to apply the changes.

Please tell me the version of PPP and of the firmware for the board (both of these can be found in the "about" window of the PPP software).

And thanks for pointing out the mistake in the documentation - I will get that fixed. Unfortunately, this will not account for the programming problem - if the wrong pins were connected, then PPP would not be able to detect the device ID.

Hi Steve,

Thanks for the effort- it's very frustrating here too.

I have double checked that I correctly put the "IncX" in properly.
Even when I restart Flowcode and check again, the setting for "IncX" is still unchecked.

When running PPP I get: Version 3.8.11.24
Firmware version = 7

I just swapped the chip back to PIC16F648A in the 16 pin slot- no problems programming my "short" "Delay 1 second" only program. Even if I Recheck the "IncX" box.
Put the PIC12F629 back in, and fail problem returns.

I am stumped.

Best regards,

Michael

The version numbers check out. I wonder if the chip itself is damaged? Do you have access to other 12F629 chips?

You could also try running PPP itself to download the HEX file created by Flowcode. Once you have downloaded the HEX file, try to read it back using PPP (via the "view..view PICmicro" menu) and email to me both the original HEX file created by Flowcode and the one uploaded from the PIC.

Steve,

This topic is not a mainstream one for me but if you can spoon feed me with an amended fcd file to use (or not as the case may be) I will try and program a 12f629 and let you know what happens.

Regards,

Mark

Thanks for the offer of help, Mark. I'll email a new FCD file shortly.

Steve,

The 12F629 programs fine. I checked this by reading the code back with PPP and by placing various signatures in the hex that could be verified.

However...

Flowcode consistently says the code cannot be verified and gives the impression that programming may have been unsuccesful.
The usual "hello world" led flash programme fails to run (tried a few config setups), though...

Configuring the chip with internal oscillator with external output gives a 1MHz output (4MHz internal/4) so the clock was OK.

The value of cmcon looks fine and adcon is not relevant for the 12F629. I tried a couple of other cmcon values but without success.

I can only speculate that some of the paramaters for the registers or in config may be awry? I recall that there were some updates of BoostC to cover the smaller chips?

If you have working code for a HP488 board then mail me and I will try that (later next week).

Hope this helps,

Mark

Mark / Michael,

Let me add what I have found to be wrong.

The 12F629 has a special OSCCAL value which is stored at location 0x3FF. When the chip is erased or reprogrammed, this value needs to be retained by the programming software (ie PPP).

When PPP has the "Use IncXCmd" option unticked, this works fine. However, with this option ticked the wrong value is retained (actually location 0x000).

The value at location 0x000 is generally a "GOTO" instruction. When the chip is reprogrammed with a new program, this old GOTO statement is retained and the program fails its verification process. It also means that the program may or may not work correctly (usually the latter).

When I have unticked "Use IncXCmd" here, the problem is solved. Mark: do you find this to be true?

Steve/Mark

Thanks greatly for the assistance.
I have ordered 3 new pic12f629 chips, but it looks like the problem may not be a faulty chip.
Unfortunately, this is now a bit beyond my technical capability- I'm a Flowcode convert!
But please, I hope you can solve the problem(s), and I will help as needed.

As this job is urgent, I have ordered some pic16f688 chips to temporarily construct the prototype gear, and will revert to the pic12f629 when the problem is fixed.

Best regards,

Michael

Steve / Michael,

I am away now until next week and will check when I return (if it is still relevant).

According to the PPP dialog OSSCAL is read and rewritten during programming, as to the value I'm not sure. My only evidence is that the frequency of the internal oscillator output pin was 1.0XXMHz so it should not be that far out.

If an incorrect value is placed then this should simply remove the factory 1% accuracy calibration for the internal oscillator and the tests using an external crystal clock source should not have been affected?

My impression is that either the ports are not being configured properly or that the config has an error. In other circumstances I would have expected to get some activity on the pins given that every one was programmed as being initially switched on (so incorrect delays would not figure).

Hope this helps. Have a good Bank holiday weekend.

Mark,

The problem I have experienced is not to do with losing the OSCCAL value (although that does happen). The problem is that the value at program location zero is mistakenly retained by PPP (instead of the OSCCAL value).

This typically means that the program will jump to an inappropriate location at the beginning of the program (because the first instruction in the HEX file is almost always a GOTO instruction). Obviously this can cause all kinds of wierd behaviour.

Have a nice long weekend!

Steve/Mark

Does the "inappropriate osccal value" mean that if the pic12f629 was "misprogrammed" in my earlier attempts with the original .fcd file and IncXCmd checked, that the chip cannot be programmed properly now?

Steve, what I am thinking is that when you programmed the chip you had made the changes, but when I did it earlier the value has been lost.
Not sure.......

I'll have some more pic12f629's on Monday and give the "new .fcd and unchecked IncXCmd" a try on one of them.

Best regards,

Michael

Michael,

The original factory OSCCAL value will have been lost, but it is generally not that important (and there are ways to restore it if you really need a more accurate clock).

However, the chip should reprogram ok after the "Use IncXCmd" option has been unticked. You said you still have the problem, which is a little concerning for me.

If you still have the problem on Monday, we'll have to try something else.

Steve,

Just one last thing before Monday.
Do I use the original .fcd file, the replacement one you sent, or the modified one with the brackets; or some combination???

Best regards,

Michael

I think the modified one with brackets should be the best, although there is probably not much difference between them all.