View previous topic :: View next topic |
Author |
Message |
crystal_lattice
Joined: 13 Jun 2006 Posts: 164
|
16F886 config bits verification fail |
Posted: Sat Jul 19, 2008 3:02 pm |
|
|
Could anyone please explain which connection they use to program the 16F886, ie. do you use the modular jack, or the ICSP connection.
I'm using a ICD1 with CCS firmware. The software detects the chip, does the programming but fails on the verification. Thus I'm not sure if i have to use the ICSP connection. I've never used the ICSP connector before hence the confusion.
There has been posts regarding incompatibilities with CCS ICD firmware and the 16F886 chip but it sounds like the chip is not recognized at all.
Any help would be greatly appreciated. |
|
|
crystal_lattice
Joined: 13 Jun 2006 Posts: 164
|
|
Posted: Tue Jul 22, 2008 1:37 am |
|
|
I've played around with the ICD settings (Normal and Fast options) and it seems to program and verify now. I can even get a simple program running. However I seem to encounter problems with the printf.
Running a simple while loop with a 1000ms delay and a printf and toggle_output statement causes the led to flash as expected but the terminal is showing garbage. I am using the internal 8Mhz osc with no clkout.
I don't think it could be CCS config that is causing problems as I've tried a bootloader for 4Mhz and 8Mhz which was precompiled. These don't work either as the PC loader says it can't find the pic. (Tiny bootloader build 197) Unless the the chips have some trick to them??
It is not the RS232 HW as this works fine with other projects. Setting the baud rate down to 9600 does not help either. |
|
|
treitmey
Joined: 23 Jan 2004 Posts: 1094 Location: Appleton,WI USA
|
|
Posted: Tue Jul 22, 2008 8:19 am |
|
|
When I here of garbage on a serial terminal, I think of a bad ground(ie the PC ground not the same as PIC) or a problem with the crystal ie: delay set wrong.
Check both of these. |
|
|
crystal_lattice
Joined: 13 Jun 2006 Posts: 164
|
|
Posted: Wed Jul 23, 2008 7:00 am |
|
|
Hi thanks for taking the effort of looking at my problem, was thinking no one had any advice...
The HW is the same as in other projects and they work fine, the pic has been tested at both 3.3v and 5v. The use delay statement uses the correct clock setting.
As said before, a bootloader hex loaded into the PIC does not work. I was thinking today to maybe set the internal osc so that the clock output apears on one of the osc pins. Then I want to check on a scope and see that the freq is in range.
The Pic does feature a register where one can 'calibrate' the clock so maybe i can do some adjustment here..? Just don't think it is needed as the datasheet states that the clock has been factory calibrated to 1% (or is it 0.1%, don't have the datasheet in front of me..) accuracy, so 'manual' adjustment should non be neccesary. |
|
|
crystal_lattice
Joined: 13 Jun 2006 Posts: 164
|
|
Posted: Thu Jul 24, 2008 12:57 am |
|
|
Got it working!! I checked the frequency on the clkout pin and get a calculated(2.6div @ 0.2us/div) reading of 7.69Mhz not sure if that will cause a baud of 9600 to be out of spec. I then proceeded to do a series of osctune settings and doing a printf after each adjustment.
After setting the osctune to 0x01 the printf started to work. I looked in the datasheet but could not find any info on how much the osctune reg can [censored] the freq. According to the datasheet the reg is initialized to 0x00 upon any reset, but I am thinking that either it is not initialized to 0x00 or that the 'factory calibrated freq' is wronf/off. I have not checked the freq after the osctune but will do so tonight to confirm the new freq. |
|
|
|