oscillator code and placement within program

I have a problem when using this oscillator code:

<b>
poke $19,%00000111
poke $85,%00000100

high 0
asm bsf RP0
call 03ffh
movwf OSCCAL
bcf RP0
endasm
</b>

I need pin 0 to be high right off the start. If I use the ASM code anywhere other than the very front of the program the program will not run. I sort of suspected the ASM code had to be in the front, but moved it around to experiment a bit.

So, how can I make pin 0 high at the beginning and still calibrate the internal oscillator?

I'm stumped. I've spent most of the afternoon trying to come up with the solution.

Thanks.

Bart

Hi Bart,

The calibration code should only take about 5-6us to run. If that's a problem you should deal with it using a pullup resistor or something similar. However, i must say that i'm a bit confused why your code will not run the way you've written it. It may have something to do with PCLATH, i'm not sure how PBC handles this. It shouldn't be a problem if the ASM code is at the very top of your program(as you've already realized). My advice .... don't mess with it, leave it at the top.

The code you've written will ouput LOW level on pin 0 for a few us. First you make the pin an output with "poke $85,%00000100", after that you tell the pin to be high with "high 0". In the short time between theese commands, pin 0 will be driven low. The solution is to set the pin to your desired value BEFORE you make it an output.

I recommend you to add a pullup to pin 0 and write the code like this ...........

Code:

---

asm
    bsf RP0
    call 03ffh
    movwf OSCCAL
    bcf RP0
endasm

poke $19,%00000111
poke $05,%00000001  'Make sure bit0 starts high
poke $85,%00000100

' Rest of your code

---

My somewhat fading memory tells me that it's essential that your asmcode is "tabbed". Everything located on the first position on a line will be interpreted(by the assembler) as a label, not code. Beware that i might be wrong about this.

/Ingvar

Thanks.

I will make this program change and see what happens. I'll also try it with and without indents.

I'm not sure about the pull up resistor issue. What do you mean by this? It is to be an output so how do I tie a resistor in there anywhere and not have it do something funny?

Bart

Hi Bart,

When you put power to the pic it starts with all it's pins configured as inputs. Nothing you can do about that, just the way things are. They will remain inputs until you tell them to be outputs. During this time the inputs "float", meaning they could be anything between 0 and 5 volts. If the device you're controlling with such a pin is sensitive enough it could get triggered by this floating signal. A simple way to prevent this from happening is to connect a resistor between the pin and Vcc, this is called a pullup. When the pin is floating(input) this resistor will "pullup" the pin to a high state. If you want the pin to be low on startup you should connect the resistor to GND, now you have a pulldown. When your program sets the pin to output, the resistor isn't needed anymore but it won't do any harm either, exept consume some current(biggers res = less current). Your pullup(down) could be anything between 1k and 1M, it all depends on your application. If the device you're controlling is current(not voltage) controlled, like a LED or bipolar transistor, you don't need a pullup or down. If it's a FET or IC you probably do.

/Ingvar

Well, I tried the various changes here with no success.

IF I do NOT use the assembly code the thing fires up with pin0 high just as it needs to be. Well, it may be firing up low, but there is no noticable period of it before it goes high.

IF I USE the assembly code and the extra POKE command there is a good 1 second delay between start up and the pin going high. That is NOT ms, but SECOND. Sure seems like a long time to execute the calibration routine.

Does this make any sense to anyone?

Bart

Once again, the assembly code call the OSCCAL value... if your device lose his calibration and load $FFFF as value but expecting something like $3480... for sure it's certainely not the great value. so the oscillator is not running at the great speed there, IMO this is why it give you the 1 second delay.

is by any chance you can change the OSCCAL value to ... let's say $3480 and post what happen now!!!

Now it seems to work.

I did force in that value initially, but I put it in as a decimal not a hex (stupid me).

I swear this stuff is going to drive me crazy although I feel I am learning something!

Thanks.

Bart

Hi Bart,

Been going thru your problems with OSCAL. I make it a point of reading content a fresh MCU and checking the last position -03FF for 12F629 and force the number while programming. I also use another method - I limit the erasing of the chip to a value well short of the max (03FF or 1K in my case) so the programmer never resets it to 3FFF.

I don't know if this is good programming practice! I have used it with no problems.

I also set WPU (weak pull up register) on always on all I/O. If TRIS changes any pin to an output it PIC auto diasbles it anyway so no harm done.

-warrier

Thanks. I did get it working once I used an average value as suggested and remembering to put it in as a hex number and not a decimal number.

I did read the chip when it was new and there was no value in that position. I'll see what future ones say.

How did you erase only a portion of the chip? I'm using IC-PROG and perhaps that isn't possible. I'm sure the calibration part of that program is off regardless. Even with a value at that address it always tells me that it can't find a calibration value and would I like to use the one at 3FF. Well, duh. I don't know where it is expecting to see it.

Bart

The software in most sensible programmers gives you the option to avoid the Calibration and Bandgap bits when either erasing or programming. One reason to avoid noddy programmers and amateurish supporting software. If you choose the cheapest option in this business, you often get what you pay for.

The Calibration Value is unimportant unless you plan on using critical timing functions such as in Software Communications (ie DEBUG, DEBUGIN, SERIN, SEROUT) or need accurate timing measurements (such as COUNT or PULSIN etc).

The Bandgap Bits are only used for trimming the onboard voltage reference used for POR and BOR to ensure they meet the published specifications - again for all intents and purposes this is unimportant and can be ignored in most cases.

Yes, it is the cheapest option. In the event I never build anything else I don't want to invest in anything better. Bad enough having to buy pbc.

The bandgap setting is clearly listed for "default" or a couple other options. It's just the calibration that doesn't appear to be, but according to other using IC-PROG it doesn't overwrite that value or erase it. I've seen no evidence of that, but I do know for sure that the chip contained no value in that location as the first thing I did was read the new chip and look for it.

Bart

Melanie:

I use the internal oscillator in many applications so I could have the CLKIN & CLKOUT available as I/O pins, especially when using the 8pin (12F) and the 6pin (10F) versions! "Accidentally" erasing the chip before programming and using the define OSCCAL_xK 1 statement can send the chip to the la-la land.....

You know a lot about the internal harware config but modifying the oscillator value with 255 will certainly be way out from a value with a number closer to 100.

Reading a new chip and getting all 3FFFh value means the chip has been erased and not "fresh". As I understand it the last position without the 34xxh is the only difference between a new chip and an erased or programmed chip......

-warrier

I'll be getting more chips in the next couple of weeks so I can actually start building this project.

I'll read them all and see what I see for the calibration.

The calibration is not that critical for what I'm doing. Assuming I do anything else in the future it may be more important. Why wait until later what I can learn today?

Bart

There's something seriously wrong somewhere if your PIC hangs or goes walkabout regardless what value is used for Calibrating OSCCAL.

No, it is working fine. Without the value though the calibration routine just took a long time to process which set up a delay on start up that shouldn't have been there. Once I put in the "fake" value as suggested things fired up right away as they should have.

The program is basically done. A couple little tweaks to do as I go about making the boards and what not.

Bart