View previous topic :: View next topic |
Author |
Message |
jreinhart
Joined: 07 Jul 2009 Posts: 3
|
Trouble with the PIC16F688 |
Posted: Tue Jul 07, 2009 7:14 am |
|
|
I'm having trouble getting this device to run the way I want.
My first issue is the clock speed doesn't seem to be setting up correctly. That is, I'm attempting to use the internal 8MHz clock. When I toggle a pin in the main loop, it toggles at only 284kHz.
My second issue is I can't seem to debug with this chip. I get:
"Could not start target: The target was not halted after reset. Check the target oscillator and MCLR."
I'm using the same ICD connections I've used for several PIC designs. No cap on MCLR line and 47k pullup. I've used the diagnostics tool in ccsload to make sure voltage levels on the ICD lines are correct and everything checks out.
Here the code I'm trying to run:
Code: |
#include <16F688.h>
#device adc=10
#device ICD=TRUE
#FUSES NOWDT //No Watch Dog Timer
#FUSES INTRC //Internal RC Osc
#FUSES NOPROTECT //Code not protected from reading
#FUSES NOBROWNOUT //No brownout reset
#use delay(clock=8000000) //Use internal clock, 8MHz
#define LED PIN_C4
void main()
{
setup_oscillator(OSC_8MHZ);
setup_adc(ADC_CLOCK_INTERNAL);
setup_adc_ports(sAN4|sAN5|VSS_VDD);
setup_comparator(NC_NC_NC_NC);
while(1)
{
output_toggle(LED);
}
} |
Nothing stands out, not sure what I'm doing wrong here. Any help would be greatly appreciated. Thanks!
My compiler version is 3.249 and I'm using an ICD-U40 |
|
|
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Tue Jul 07, 2009 7:50 am |
|
|
PIC16F688 doesn't provide built-in debugging capabilities. An ICD2 debugging header (Microchip Part# AC162052) is required.
I don't understand the observed timing problems. I'm using PIC16F688 with INTRC oscillator, and the timing is correct, including UART baud rates. You possibly need to set OSCON accordingly.
Code: | #byte osccon = 0x8f
osccon = 0x7c; // 8 MHz |
|
|
|
Guest
|
|
Posted: Tue Jul 07, 2009 7:54 am |
|
|
Look at the .LST file.
Comment out the other feature setup lines of code.
You are not using fast_io so there can be TRIS code around the toggle
statement that takes more cycles - plus ICD overhead.
So the freq you see may be just about right - given the situation.
Evaluate the .LST file to see for yourself. |
|
|
jreinhart
Joined: 07 Jul 2009 Posts: 3
|
|
Posted: Tue Jul 07, 2009 8:06 am |
|
|
It's unfortunate that I can't debug with this chip. I wasn't aware. This will make it tricky to work with and test the A/D.
Well, based on other posts I've seen, I had already tried manually setting the osccon register and that didn't change anything.
I should also add that I've tried setup_oscillator(OSC_4MHZ) to see if I could even affect the clock. The toggle speed remained constant at 284kHz.
I looked at the .lst file and the toggle loop is about 4 instructions long. The fact that the observed toggle rate is so much slower than expected, (like 28 times slower), plus the fact that I can't seem to affect the rate with setup_oscillator() leads me believe the clock isn't being setup properly.
I'm stuck. |
|
|
Ttelmah Guest
|
|
Posted: Tue Jul 07, 2009 8:26 am |
|
|
Worth remembering though, that 'output_toggle', takes several instructions. The tris bit for the requirted bit is cleared, then the latch is read, bit modified, finally the new bit is output. It will be longer than the four instructions you quote.
Code: |
.................... while(true) output_toggle(PIN_B0);
0051: BCF 06.0
0052: MOVLW 01
0053: BCF 03.5
0054: XORWF 06,F
0055: BSF 03.5
0056: GOTO 051
|
Changed to use PIN_B0, but this is the length the code will be....
At 8MHz, 2MIPS. So expected toggle edge every 333KHz. Only takes a slight error in your measurement, and 284KHz, is exactly what is expected - no factor of 28.....
Best Wishes |
|
|
jreinhart
Joined: 07 Jul 2009 Posts: 3
|
|
Posted: Tue Jul 07, 2009 8:52 am |
|
|
Ttelmah,
Thanks, you're right. I was thrown off by the fact that I didn't seem able to affect the system clock with setup_oscillator(). I was able to slow it down by manually setting osccon. Seems to be some problem with setup_oscillator for this chip and my compiler version. So, short of not being able to debug, it seems things are working. Thanks again. |
|
|
|