Anyone Using a PIC12F629 and C?

[mrmonteith]

I'm looking for someone that has worked with a PIC12F629 using C and using the internal oscillator. I found some assembly code that turns on and off the ports and works fine. However I have yet to get any of them turned on or off. It should be a simple matter of setting TRISIO and GPIO appropriately.

Michael

 

[eng1]

I'm looking for someone that has worked with a PIC12F629 using C and using the internal oscillator. I found some assembly code that turns on and off the ports and works fine. However I have yet to get any of them turned on or off. It should be a simple matter of setting TRISIO and GPIO appropriately.

Michael

I've used the PIC12F629 with C and the internal oscillator. So, do you want to toggle some output pins? Have you already started writing the program? One often forgets to turn the comparators off.

 

[mrmonteith]

Yes, done that, thanks. The assembly code I do know never does that. At this point the very basic minimum to turn on a single port would do. But even that doesn't seem simple. I've made sure my configuration bits are set. The bad part is the datasheet shows having to manipulate memory pages, etc. At this point any help is better than where I've been at for 2 weeks.

Michael

 

[kchriste]

Well, post your code and we'll see if someone can help you. Don't forget to surround your code with the code tags. (Remove the *s)
[*CODE][*/CODE]
So you are saying there's no:

	movlw	0x07
	movwf	CMCON

in the assembly example you have? If so, then bits 0,1 & 2 won't be digital IO pins and will revert to analog comparator mode. Bits 3,4 & 5 can be digital IO without turning off the comparators though.
In C you would do this:
CMCON = 0x07;
To turn off the analog comparators.

 

[mrmonteith]

#include <htc.h>
#include <delay.h>
//__CONFIG (UNPROTECT & INTIO & MCLRDIS & PWRTDIS & WDTDIS & INTIO & BOREN);
__CONFIG(0x3FD4);

unsigned char LED_D1	= 0b000100;	// GP2

void main(void)
{
	OSCCAL	= 0x3ff;
//	STATUS 	&= 0xDF;
	GPIO	= 0x00;
	CMCON	= 0x07;
//	STATUS	|= RP0;
	TRISIO	= 0x08;	// GP3 is always input, rest output
	GPIO	= LED_D1; 
  while(1)
	{
		GPIO0 = 0x00;
		DelayUs(1500);
		GPIO0 = 0x25;
		DelayUs(1500);
	}
}

You'll have to forgive the code. I started off with just basic set CMCON and TRISIO, then set GPIO as you want bits on/off. I've played with various combinations. Same with configuration bits. I've tried setting it from the programmer and then letting code set it.

Michael

 

[Pommie]

You don't need to worry about bank switching when using C as the compiler takes care of that.

What is GPIO0?

My guess as to what would work is,

#include <htc.h>
#include <delay.h>
__CONFIG (UNPROTECT & INTIO & MCLRDIS & PWRTDIS & WDTDIS & INTIO & BOREN);

void main(void)
{
    GPIO = 0x00;
    CMCON = 0x07;
    TRISIO = 0x08;    // GP3 is always input, rest output
    while(1)
    {
        GPIO = 0x00;
        DelayUs(1500);
        GPIO = 0xff;
        DelayUs(1500);
    }
}

Mike.

 

[mrmonteith]

Tried that code too. Nothing. Now you start to see why I'm pulling my hair out.

Michael

 

[Pommie]

How are you programming your chip. Can you single step? Can you post a schematic of your circuit?

Mike.
P.S. going to bed now - 2am here. Will look tomorrow.

 

[eng1]

Tried that code too. Nothing. Now you start to see why I'm pulling my hair out.

Michael

Increase the delay, the LED is flashing too fast.

#include <htc.h>
#include "delay.h"

__CONFIG (UNPROTECT & INTIO & MCLRDIS & PWRTDIS & WDTDIS & BORDIS);


void DelayMs(unsigned char cnt)
{
#if    XTAL_FREQ <= 2MHZ
    do {
        DelayUs(996);
    } while(--cnt);
#endif

#if    XTAL_FREQ > 2MHZ    
    unsigned char    i;
    do {
        i = 4;
        do {
            DelayUs(250);
        } while(--i);
    } while(--cnt);
#endif
}



void main(void)
{
    GPIO = 0x00;
    CMCON = 0x07;
    TRISIO = 0x08;    // GP3 is always input, rest output
    while(1)
    {
        GPIO = 0x00;
        DelayMs(250);
        GPIO = 0xFF;
        DelayMs(250);
    }

}

EDIT: typo corrected. Also, remember to define XTAL_FREQ = 4MHz when you build the project.

 

[mrmonteith]

Tried the code. Didn't work. But I'm hoping I get a chance to check it with my meter tomorrow. I just had to at least try a quick run of it.

 

[mrmonteith]

HTSoft found the problem. They said so far it's a hardware issue but going to respond to me later on the exact reason. But the workaround is a setting in MPLAB:
Project - Build Options - Project, then Global Tab - Use OSCAL
You uncheck that, recompile, program the PIC and it works.

Thanks for all the assistance. This is one to keep a note on.

Michael

 

[Pommie]

I guess they do a call to 0x3ff to get the oscal value and your programmer has written over it.

What programmer do you use?

Mike.

 

[mrmonteith]

Actually HTSoft gave this response as the answer:

Actually it's an MPLAB/Microchip issue.

When you use the OSCCAL, the calibration value is at the last address (3FF) of the memory. The first thing that the program do is to call this address.

But on the chip, the value at the address 3FF is wrong, so the program just continue and as it reaches the end of the memory, it starts again at the beginning, and turn forever like this.

You can see this if in MPLAB after programming the device you read it by using the button Read target device.

To fix this you can go in the menu Debugger -> Settings and in the tab Calibration Memory, you can check the checkbox Allow ICD2 to program calibration memory, and choose the new value.

I've found an other issue is that when I use a project in MPLAB to program the chip, the code on the chip is cut at the address 0x00B.
But if I import my .hex file just in MPLAB, with no project open, and I program my chip, everything is ok.

We have sent a mail to our contact at Microchip to have more information about these issues.

I'll get back to you when I'll have more information.

BTW, i'm using a Clone PICKit2 from Sure Electronics.

Michael

 

[eng1]

When you use the OSCCAL, the calibration value is at the last address (3FF) of the memory. The first thing that the program do is to call this address.

Yes, location 0x03FF contains a RETLW instruction that returns the calibration value. That location shouldn't be overwritten. You use a CALL instruction to get it, then you move it to the OSCAL register. But your program was just loading the OSCAL register with a constant (0xFF = LOW 0x3FF). In my opinion, checking or unchecking that box shouldn't have made any difference? (the oscillator frequency was not tuned, of course)

 

[mrmonteith]

Well, don't know what was going on but it sure wouldn't work until I did uncheck it.

Michael

 

[Pommie]

Yes, location 0x03FF contains a RETLW instruction that returns the calibration value. That location shouldn't be overwritten. You use a CALL instruction to get it, then you move it to the OSCAL register. But your program was just loading the OSCAL register with a constant (0xFF = LOW 0x3FF). In my opinion, checking or unchecking that box shouldn't have made any difference? (the oscillator frequency was not tuned, of course)

The compiler was doing the call instruction and therefore going round in a continuous loop.

Mike.

 

[eng1]

The compiler was doing the call instruction

I see... I was misled because the disassembling listing does not included the code generated by MPLAB for the calibration.