10F222 no response?

[picster]

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.


' 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

[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 (https://ww1.microchip.com/downloads/aemDocuments/documents/OTH/ProductDocuments/DataSheets/40001270F.pdf) 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.

[picster]

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 (https://ww1.microchip.com/downloads/aemDocuments/documents/OTH/ProductDocuments/DataSheets/40001270F.pdf) 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. 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.

[Acetronics2]

no error ?



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




...

[HenrikOlsson]

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:

'************************************************* ***************
'* 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.

[Acetronics2]

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

this one looks to work fine...



' 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 !

[picster]

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

this one looks to work fine...



' 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.

[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

peekcode $1FF, tempvar
OSCCAL = tempvar
Or perhaps even

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

[picster]

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

peekcode $1FF, tempvar
OSCCAL = tempvar
Or perhaps even

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.