LCD readout with 12f629

I have a dedicated 16f84 pic tied to a LCD display which allows me to use Debug commands to readout parameters with a single wire at 2400 baud from PIC's under development.
I am now working with a 12f629 PIC and can not get readable data from it. The program does function. I am using the 629's internal RC oscillator at 4mhz and my Debug settings reflect this. I changed the REG setting to GPIO.5 but the compiler says its not a defined pin.


Define OSC 4 ' Set Xtal Frequency
Define DEBUG_REG PORTB.3 ' Debug PortB for 16f84
Define DEBUG_BIT 2 ' *** Debug pin Bit-0 ***
Define DEBUG_BAUD 2400 ' *** Debug Baud Rate ***
Define DEBUG_MODE 1 ' Set Serial Mode to Inverted
Define DEBUG_PACING 200 ' Delay 'in Us' between

I also tried the serial communicator with the SEROUT command but couldn't get anything readable.

N2400 con 4

Serout GPIO.5,N2400 ,[seq,10]

I have read: Debug commands do not work on 12 bit core PICs (?)
An external xtal is necessary (tried that}
The defines may have to be tweaked (?)

Does anybody have any other suggestions?

Quote:

---

Originally Posted by Homerclese

Define DEBUG_REG PORTB.3 ' Debug PortB for 16f84
Does anybody have any other suggestions?

---

Suggest you change the DEBUG_REG port... :)

Read the 12F629 with your programmer.
Check the Last location in program memory.
If you're lucky (very lucky), there will still be a value there for calibrating the internal oscillator.

If there is? You can use ...

Code:

---

DEFINE OSCCAL_1K 1

---

If Not? You can set the Internal Oscillator to center frequency with...

Code:

---

OSCCAL = $80

---

--------------------

The 12F629 is a 14bit core, so debug will work. It's also the smallest in code size. Which is a good thing for a 12F629 with only 1K of Flash.

--------------------

And, like skimask almost said. Get rid of the .3 in your Define DEBUG_REG
Define DEBUG_BIT selects the PIN to use.

Another "forest for the trees" thing again!

REG GPIO - BIT 5 Got it! Thanks.

The value in the last memory location shows up in the calibration section of the memory read. The value was still there (3438). The OSCAL define fell out of the program as I played with the code. Debug works now.

Stepping back a bit, when I first started playing with the 12f629 I thought I had damaged two chips. They would work and then stop. Resetting would sometimes get them going. At one point they both seemed dead. Now, I read them out and find no calibration value. I have the "calibration program" option unchecked, so I don't know how they got wiped out. I tried OSCAL $80 and the chip came to life. It looks to be running about 40% faster than it should. Because of this, Debug stopped working with this chip.

So.....

It seems that the calibration value is more than just a tweak. Loose it and you stop. Yes?
The rest of my 12f629's have the same value (3438) in the last location. Can I write to that location and restore the chip, or can I find an OSCAL value that comes close? Is that what OSCAL $80 does?

Quote:

---

Originally Posted by Homerclese

It seems that the calibration value is more than just a tweak. Loose it and you stop. Yes?
The rest of my 12f629's have the same value (3438) in the last location. Can I write to that location and restore the chip, or can I find an OSCAL value that comes close? Is that what OSCAL $80 does?

---

Lose the cal value and your 2400 baud value becomes something like 2300 or 2500 or whatever. Baud rates can only stand to be about 5% off at the very most. The datasheets say that the OSCCAL value can change the internal clock speed from -12% to +12%, so the 40% might not be entirely correct.

As far as putting $80 back into OSCCAL, I think it was more coincedence that everything work. Most likely that a value of $80 in OSCCAL brings you that much closer to 4mhz and you might still have to do some tweaking to it. As far as I know, the best way to get the correct value is to write a program to switch a pin and watch it on an o-scope or freq counter. I'm not sure if there are any programmers out there that'll find the correct value for you. I could be wrong though. My Warp13a won't do it for me.

I wrote a little pin out program and read it with a frequency counter. With a good calibration value for a 4MHZ clock, the pin frequency was 97.48 KHZ.

With a 12F629 PIC that lost it's calibration value, using OSCAL $80 the frequency was 115.35 KHZ.

Changing the OSCAL values yielded:

$70 = 112.25 KHZ
$50 = 105.04 KHZ
$30 = 98.40 KHZ
$2D = 97.40 KHZ

So OSCAL = 2D to get this particular chip back on frequency. Debug is working again.

Quote:

---

Originally Posted by Homerclese

I have the "calibration program" option unchecked, so I don't know how they got wiped out.

---

It's not only the programmer that can cause the loss of the calibration.

Another way to lose it is to turn on Code Protection.
When protection gets turned off to program the chip the next time, the chip itself erases everything to protect from someone just turning of protection and reading the program.
The oscillator Cal gets erased along with the program.

So Code protection probably shouldn't be turned on until the Last time it's programmed.

Hi, Homer

I saw I-don't-remember-where a simple trick not to loose the cal value ...

The chip has 8 pins ... the cal value 8 bits ...

just put a drop of white paint facing the pins corresponding to "1" bits ... or a small sticker under the chip.

simple !!!

Alain

If you do erase this, it can be restored using POKECODE. Assuming you have found the best value, say $2D, you can use POKECODE @$3FF, $2D to replace it.

This produces;

org 3FFh
retlw 2Dh

Then when you use DEFINE OSCCAL_1K 1, this inserts a call to the last program code location, lands on the retlw (return with literal in the W reg), which, in this case, would be 2Dh. On return, W reg is moved in the into the OSCCAL reg for you.

If you use DEFINE OSCCAL_1K 1, and this location has been erased, it just wraps around from 3FFh back to square 1, and you have a continuous loop because there is no longer a retlw 2Dh instruction there.

The best way I have found to get the factory OSCCAL value is to setup OSC2 to output Fosc/4 and watch this pin with a scope. When you hit the magic number, you'll see 1MHz output on OSC2.

Then use POKECODE to store this value in the last program memory location, and you're good to go.

If you don't have access to a scope, you can setup a loop sending each new OSCCAL value to a serial terminal program. When you get close, you'll start seeing values on-screen. When it's way out of tune, you'll see garbage characters, or nothing.

Normally you'll have 15 to 20 values show up. I take the one in the center, and use that for my OSCCAL value to be restored with POKECODE.

Using the OSC2 1 MHZ method I was able to get a reading of 1.0016 MHZ with an OSCAL value of $39. A fair tweak from $2D.