ccs compiler with pic12ce674?

I'm not surprise that you see MCLR high. You don't initialize it to anything and the GPIO register bits are undefined on power-up.

Have you tried running this in the MPLAB simulator? Make sure you are looping. Make sure your bit toggle statements are being executed.

Possible culprits:

I notice that other places, you use TRUE and FALSE. The true in the while statement is lower case. C is case-sensitive. I assume there's a #define true 1 somewhere in an include file, but I don't know that for a fact. If it some leftover variable, then your #ZERO_RAM directive probably set it to 0 and nothing in your loop gets executed.

Another possible culprit is the delay_ms function. I have no idea if it's implemented with a timed loop or uses a hardware timer. You might want to make sure it actually completes.

To see if your loop is actually being executed, you might try initializing toggleState to TRUE so GP4 gets set high the first time through. Or initialize GP4 to 1 before entering the loop and see if it goes low the first time through.

The GP3 pin is equivalent to an open collector output (technically it's an open drain, but I'm old school). I'm not sure what the default state of that pin will be after a reset, but I don't see you clearing it anywhere in your code. Do you have a pullup resistor on the GP3 (RA3 in CCS) pin? I've gotten burned more than once by forgetting that it needed one.

I've had problems with CCS IO setup functions in the past. They tend to make assumptions about the order you will set up things, and so sometimes don't clear or set a bit you would expect them too. There is a warning in the 12CE674 datashet about GP4 comes up as an analog input after reset. Perhaps setup_adc_ports isn't setting up ADCON1 correctly. I'd look at the assembly code listing for that function call and see what the code is really doing. You could also check to see if the pin is really an output, by connecting a 1K resistor from the pin to the pluss side of your power supply, if the pin doesn't look like a nice solid low, it's probably configured as an input.

CCS produces tight code, but I have a few problems with it. They use different names than Microchip does, which makes looking stuff up in the Microchip datashets a chore. Their io setup functions are often buggy. In their defense they support a whole bunch of different chips which tend to have very subtle differences.

If you're new to pic development, you might want to try a simple blink the LED program on a different pin, just to make sure your development environment is working.

Mark

This is precisely why I never use those type of functions in the CCS library. I use the CCS compiler for midrange PIC development, but I do all my own I/O setup and initialization by accessing the setup registers directly. It looks a lot like assembly language, but at least I know what it is doing.

-Robert Scott Ypsilanti, Michigan (Reply through this forum, not by direct e-mail to me, as automatic reply address is fake.)

Many thanks to those that have replied. I've implemented all your suggestions but the problem remains.

I modified the program to only toggle pin 5 (PIN_A2). I initialized the output to a high state before the loop. When I checked the output bit with a logic probe, it shows as an open. I pulled it to high through a 10K resistor and it shows as a high then. Pulling it low shows as a low. Apparently the initialization is not working correctly.

I've printed the assembly output and will code it into MPLAB to check operation. I will post the results but I probably won't be able to get at it until late this week due to work. I've also run into the inevitable program, test, erase cycle bottleneck (I only got 3 of the erasable parts so tests have to wait for the erase cycles :) )

I found in the datasheet where it specifies that the PIN_A3 (pin 4, the MCLR input) can only be used as an input.

Many thanks to those with suggestions.

The cause of the problem was the UV erase cycle on the eprom version of the PIC. The oscillator/calibration value was also erased. When a default value was loaded during programming, the program executed as expected.

Dave