10F222 no response?

Hi Gang, Long time no post.

I've got a 10F222 that's been programmed successfully (custom ZIF connection, verifies and reads back fine), with simple test code to blink an LED on GPIO.0 - but for the life of me I cannot get it to work, whether the LED is connected to the output as active-high or active-low.

Is there something I've overlooked here? Suggestions? I've been stymied before with something as simple as turning a comparator off, but this is such a simple microcontroller and has very little housekeeping.

Code:

' set parameters ' ADCON0=0 'all digital I/O TRISIO=%0000 'all outputs (GPIO.3 is input only so it's ignored) Define OSC 8 '************************************* ' variables and constants ' tempvar var byte '*********************************** ' Other housekeeping peekcode $1FF, tempvar 'OSCCAL calibration value POKE $05, tempvar 'OSCCAL register location '************************************************************** ' begin program GPIO.0=0 loophere: GPIO.0=1 pause 500 GPIO.0=0 pause 500 goto loophere end

Re: 10F222 no response?

Since there is no #CONFIG in your code I reccon you know that the default ones are what you want? I don't have access to those at the moment but what about MCLR? Is it enabled in the default CONFIG and if so, do you have it pulled up?

Also, looking at the datasheet there is no mention of TRISIO, it seems to be called TRISGPIO in that device. It's possible that the PBP header files aliases it and I suppose you should get an error if it doesn't know TRISIO but still...it sticks out.

1 Attachment(s)

Re: 10F222 no response?

Quote:

Originally Posted by HenrikOlsson

Since there is no #CONFIG in your code I reccon you know that the default ones are what you want? I don't have access to those at the moment but what about MCLR? Is it enabled in the default CONFIG and if so, do you have it pulled up?

Also, looking at the datasheet there is no mention of TRISIO, it seems to be called TRISGPIO in that device. It's possible that the PBP header files aliases it and I suppose you should get an error if it doesn't know TRISIO but still...it sticks out.

Thanks for your reply!

Yup, I have MCLR set as MCLR, and also have the pullup option set AND have a 10k pullup externally. Attachment 9910

I tried using TRISGPIO first and it threw an error so I changed it to TRISIO and THEN it compiled without errors, so that's where I currently am.

This has me stymied. I have tried another chip just in case, and I get the same results.

Re: 10F222 no response?

no error ?

Quote:

PRO(TM) Compiler 3.1.6.4, (c) 1997, 2022 ME Labs, Inc.
All Rights Reserved.

C:\USERS\ACETR\DOCUMENTS\PROJETS_MCHIP\10F_BLINK.B AS ERROR Line 20: Redefiniton of LABEL GPIO.
C:\USERS\ACETR\DOCUMENTS\PROJETS_MCHIP\10F_BLINK.B AS ERROR Line 22: Redefiniton of LABEL GPIO.
C:\USERS\ACETR\DOCUMENTS\PROJETS_MCHIP\10F_BLINK.B AS ERROR Line 4: Syntax error.
C:\USERS\ACETR\DOCUMENTS\PROJETS_MCHIP\10F_BLINK.B AS ERROR Line 17: Syntax error.
C:\USERS\ACETR\DOCUMENTS\PROJETS_MCHIP\10F_BLINK.B AS ERROR Line 20: Syntax error.
C:\USERS\ACETR\DOCUMENTS\PROJETS_MCHIP\10F_BLINK.B AS ERROR Line 22: Syntax error.4: Syntax error
17: Syntax error
20: Syntax error
22: Syntax error
4: Syntax error
17: Syntax error
20: Syntax error
22: Syntax error
Halting build on first failure as requested.
BUILD FAILED: Wed Feb 19 17:47:40 2025

...

Re: 10F222 no response?

You are compiling for the correct chip, 10F222?
Not sure at this point but I had a look through my code folder I found one piece of code for the 10F222. It's likely something I wrote in response to a question on the forum:

Code:

'**************************************************************** '* Name : Frequency Generator.pbp * '* Author : Henrik Olsson * '* Notice : Copyright (c) 2017 Henrik Olsson * '* : All Rights Reserved * '* Date : 2017-03-07 * '* Version : 1.0 * '* Notes : For 10F222. * '* : * '**************************************************************** #CONFIG __config _IOFSCS_8MHZ & _WDT_OFF & _MCLRE_OFF & _CP_OFF #ENDCONFIG DEFINE NO_CLRWDT 1 ' Forces manual use of CLRWDT GPIO = %0000 TRISIO = %00111101 ADCON0 = %01000001 ' GPIO 0 = Analog, ADC Enabled SPK VAR GPIO.1 Trigger VAR GPIO.2 GO_DONE VAR ADCON0.1 SomeValue CON 75 SomeConstant CON 12 Main: IF Trigger THEN GO_DONE = 1 SPK = 1 ' Set pin high WHILE GO_DONE : WEND ' AD conversion will always take the same amount of time PAUSEUS SomeValue + (ADRES * SomeConstant) GO_DONE = 1 SPK = 0 ' Set pin low WHILE GO_DONE : WEND ' AD conversion will always take the same amount of time PAUSEUS 16 + SomeValue + (ADRES * SomeConstant) ' The 16 above is to make the dutycycle closer to 50% than what it was ' without it. I'm quite surprised such a high number was needed and I'm ' not sure why that is. ENDIF Goto Main

Looking at the code now, 8 years down the road, I see a forgot to DEFINE OSC 8 which might explain the comment towards the end. That same comment, however, seems to indicate it WAS tested on an actual hardware.

Re: 10F222 no response?

Oooops, my fault ... wrong chip selected :rolleyes:

this one looks to work fine...

Code:

' set parameters ' ADCON0=0 'all digital I/O TRISIO=0 'all outputs (GPIO.3 is input only so it's ignored) DEFINE OSC 8 DEFINE OSCCAL_1K 1 '************************************* ' variables and constants ' tempvar var byte '*********************************** ' Other housekeeping 'peekcode $1FF, tempvar 'OSCCAL calibration value 'POKE $05, tempvar 'OSCCAL register location '************************************************************** ' begin program GPIO.0=0 loophere: GPIO.0=1 pause 500 GPIO.0=0 pause 500 goto loophere end

But you should use PEEKCODE along with POKECODE ... but POKECODE needs a CONSTANT to be stored !

Re: 10F222 no response?

Quote:

Originally Posted by Acetronics2

Oooops, my fault ... wrong chip selected :rolleyes:

this one looks to work fine...

Code:

' set parameters ' ADCON0=0 'all digital I/O TRISIO=0 'all outputs (GPIO.3 is input only so it's ignored) DEFINE OSC 8 DEFINE OSCCAL_1K 1 '************************************* ' variables and constants ' tempvar var byte '*********************************** ' Other housekeeping 'peekcode $1FF, tempvar 'OSCCAL calibration value 'POKE $05, tempvar 'OSCCAL register location '************************************************************** ' begin program GPIO.0=0 loophere: GPIO.0=1 pause 500 GPIO.0=0 pause 500 goto loophere end

But you should use PEEKCODE along with POKECODE ...

I'm not writing to CODE area though, it's writing to the OSCCAL register, location $05. Am I wrong in thinking this should do it? It didn't recognize OSCCAL and threw an error when I tried writing it to the register directly using that naming convention.

Re: 10F222 no response?

As far as I know OSCCAL the thing is only for calibrating/adjusting/tweaking the actual oscillator frequency so that it's within specification. It should not be needed to get the chip running and I don't think it relates to your problem.

With that said

Code:

peekcode $1FF, tempvar OSCCAL = tempvar

Or perhaps even

Code:

PEEKCODE $1FF, OSCCAL

Should do it. But again, I'd remove it from the code until you get a blinky running.

Re: 10F222 no response?

Quote:

Originally Posted by HenrikOlsson

As far as I know OSCCAL the thing is only for calibrating/adjusting/tweaking the actual oscillator frequency so that it's within specification. It should not be needed to get the chip running and I don't think it relates to your problem.

With that said

Code:

peekcode $1FF, tempvar OSCCAL = tempvar

Or perhaps even

Code:

PEEKCODE $1FF, OSCCAL

Should do it. But again, I'd remove it from the code until you get a blinky running.

Thanks - it's setting OSCCON that's the issue apparently. If I don't bother, it works fine. Anything else, nope. It does NOT like OSCCAL being mentioned. The PEEKCODE $1FF, OSCCAL compiles, but has the same "he's dead, Jim" result.

However, having said that, Acetronics2 used "DEFINE OSCCAL_1K 1", which I can only assume grabs the value for OSCCON from the last code address on a 1K pic and uses it in a snippet of code to drop the value into its rightful register. In this case, it would wrap-around while reading from $3FF (the referenced 1k mark) since there's only 512bytes, but it should still result in the same thing happening.

Thanks guys, for the input - blinky is blinking and I'm away to the races. I would NOT have thought that a poke to the OSCCAL would lock things up, regardless of the value written to it, and the fact that it's not recognized as a register is a head-scratcher.