Error programming 10F222

[JoelMurphy]

Hello,

I've just started working with the 10F222, and haven't been able to get anywhere due to a 'Code Programming Error at 0000'. I've poked around on the threads and found a couple of interesting things [apparently, bit 5 of Option_Reg interferes with the function of GPIO.2..?]. Anyhow, I'm using PBP, and the meLabs USB programmer. Firmware has been updated on the programmer. ZIF adapter is connected correctly. Chip package is DIP.
The process goes like this.

Write some simple test code [below, board set up with LEDs on pins 3,4,5]
Ask PBP to compile [no errors or warnings. Yes!]
Set OSC, MCPU, WDT, MCLR, Code Protect in meProg configuration window.
Ask meProg to program, and get a message
'Device not blank, program anyway?'
Well, yes. I want you to program the chip after all. Click OK, and get message
'Code Programming Error at 0000'

I've read the chip with the meProg, and it's blank.
I've tried all the chips [10] in my batch.
Any advice will appreciated.







OPTION_REG = %11000000
ADCON0 = 0
TRISIO = 0
GPIO = 0

Main: 'chase the LEDs
high GPIO.0
pause 500
low GPIO.0
high GPIO.1
pause 500
low GPIO.1
high GPIO.2
pause 500
low GPIO.2
pause 500

goto MAIN

[JoelMurphy]

Hello.
been around the thread alot today. almost all of the posts in regard to this issue have to do with the EPIC serial programmer. I'm using the USB programmer. difference no?.
i tried many suggestions to no avail. i still get this error at 0000.
one suggestion was to read the chip first. ok. so i read the chip, that worked, and then i tried to program it and voila! of course, i just programmed the garbage that was read from the chip. bunch of zeros. so, at least the chip will program! but still, MY code is not sticking...

[JoelMurphy]

tried prying up the Vdd and Vss pins and giving them separate power during programming. same error at 0000.
noticed that the DIP and SOIC versions have the Data and Clock pins in different locations. tried jumping them during programming. same problem.

i notice also that the datasheet for the 10F222 calls these pins ICSPDAT and ICSPCLK. I'm using the meLabs USB Programmer with ZIF adapter... could this be screwing me up? I program chips often and with great success. you might say it's a living... gotta get this 10F222 to work so I can pay rent!

i've used MPASM and the other one.

could somebody try to program this code on a 10F222?
i'm at the end of my rope...




@ Device PIC10F222, IOFSCS_8MHZ, MCPU_OFF, WDT_OFF, PROTECT_OFF, MCLR_OFF

ADCON0 = %00000000
TRISIO = %00000000
GPIO = 0
pause 1000
Main:
high GPIO.0
pause 500
low GPIO.0
high GPIO.1
pause 500
low GPIO.1
high GPIO.2
pause 500
low GPIO.2
pause 500

goto MAIN

[JoelMurphy]

have tried a couple of things and they are funny.

i compiled some code that i'm currently using on a 16F88 and it programmed correctly.
i tried to program the 16F88 with the code written for the 10F222 and the same code error at 0000 occured! with the wrong chip in! then, i took out the chips and tried to program an empty ZIF adapter. and it gave me the same error! not even a 'target device does not match selected device' warning.

ha ha ha ha hahahahahaha

seriously. time for a break. hope to hear from you soon.

[Charles_Leo]

The PIC10F parts require a special programming adapter, even when using the 8-pin DIP package. They won't work in the standard adapters like the 8-40 pin or the 8/18/20 pin.

[JoelMurphy]

holy crow.
i was planning on setting up a breadboard to do ICSP on the thing... i'll still give that a go, while i'm waiting for my shipment from meLabs!
i have used the 12F parts [8 pin] with the standard ZIF with great success, and just assumed... yeah, right.
it is still possible to be smarter than yesterday.

thankyou kind Charles for waking me from my stupor.

[JoelMurphy]

Hi,
Got that 10F ZIF adapter. I had also thrown together an ICSP setup on my breadboard. Both work! Iʻd rather use the ZIF, and free up the breadboard!

SO, after getting a good test running, I put together my first draft program and got ʻUnable to fit Variableʻ error. Nice. Turns out that PBP uses 22 bytes of RAM for storing data that it uses to run my code. Well, the 10F222 has 23 bytes of RAM... I got 1 byte variable to use in my PBP program! This is a rude awakening.
The essence of my project is to fade 3 LEDs. Not much heavy lifting going on here. I started incorporating the TMR0 in my software PWM loop. That worked barely. The basic structure of my PWM loop is:

FOR X = 0 TO 100
FOR Y = 0 TO 100
IF Y < X THEN
GPIO = 1
ELSE
GPIO = 0
ENDIF
NEXT Y
NEXT X

to fade the other way, you just mirror the above loop.
You see that Iʻm using 2 byte variables here...
So what Iʻve done is to commandeer the OSCCAL register. There is an issue with bit 0 of OSCCAL and that it effects GP2. I just increment OSCCAL by 2 when Iʻm using it. I got some usable LED fading happening and found a free variable! :cool:
Iʻm still not happy though. I really need one more byte var to get the effect that I want. Anybody have any ideas? Is it possible to tap into the RAM area that PBP uses? Maybe thereʻs a DEFINE somewhere that I can make do my bidding...?

Iʻll post the code soon. Itʻs on another machine
Joel

[JoelMurphy]

Here's the code that I'm working with.



@ Device PIC10F222, IOFSCS_8MHZ, MCPU_OFF, WDT_OFF, PROTECT_OFF, MCLR_OFF


OPTION_REG = %11010010 'GPWU_OFF, GPPU_OFF, TOCS_OFF, TOSC_HIGH>LOW, PSA_TMR0, PS_1:8

ADCON0 = 0
TRISIO = 0
GPIO = 0

Time var byte

pause 100

Main:
OSCCAL = 2
GOSUB FADE1A
PAUSE 1000
OSCCAL = 2
GOSUB FADE2A
PAUSE 1000
OSCCAL = 2
GOSUB FADE3A
PAUSE 100

GOTO MAIN




Fade1A:
FOR TIME = 0 TO 250
IF TIME < OSCCAL THEN
IF TIME < 80 THEN
GPIO = 7
ELSE
GPIO = 6
ENDIF
ELSE
GPIO = 7
ENDIF
NEXT TIME
OSCCAL = OSCCAL + 2
IF OSCCAL = 250 THEN
OSCCAL = 2
GOSUB FADE1B
RETURN
ENDIF
GOTO FADE1A
Fade1B:
FOR TIME = 0 TO 250
IF TIME < OSCCAL THEN
GPIO = 7
ELSE
IF TIME > 170 THEN
GPIO = 7
ELSE
GPIO = 6
ENDIF
ENDIF
NEXT TIME
OSCCAL = OSCCAL + 2
IF OSCCAL = 250 THEN
RETURN
ENDIF
GOTO FADE1B

'the other two subroutine blocks are the same as above
'with GPIO = 5 and GPIO = 3






It looks like it might be possible to use POKE and PEEK to access the RAM area that is restricted... I'm going to play around abit, I could get away with 1 more byte var, but I would love to have 2 more!

[JoelMurphy]

Well, I think I got what I need.
I have been tweaking the options and have found that if I use MPASM I can get two more byte variables! So total including commandeering the OSCCAL register is 4 byte variables. I'm on my way.
Would love to know if anyone has any further ideas about how to squeeze more RAM out of PBP