CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

Problem with the ICD flag

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
berberis



Joined: 02 Feb 2006
Posts: 1

View user's profile Send private message

Problem with the ICD flag
PostPosted: Tue Feb 07, 2006 9:55 am     Reply with quote

I wrote the test program:
Code:
#include "18f6622.h"
#device *=16

#fuses PROTECT=15
#fuses WRT=15
#fuses EBTR=15

main()
{
}


When compiled this gave the listing:
Code:
CCS PCH C Compiler, Version 3.235, 27782               07-Feb-06 15:24

               Filename: C:\ccstest\main.LST

               ROM used: 26 bytes (0%)
                         Largest free fragment is 65510
               RAM used: 5 (0%) at main() level
                         5 (0%) worst case
               Stack:    0 locations

*
0000:  GOTO   0004
....................  #include "18f6622.h"
....................  //////// Standard Header file for the PIC18F6622 device //////////////// 
.................... #device PIC18F6622 
.................... #list 
.................... 
.................... #device *=16....................   
.................... #fuses PROTECT=15 
.................... #fuses WRT=15 
.................... #fuses EBTR=15 
....................   
.................... main() 
.................... { 
0004:  CLRF   FF8
0006:  BCF    FD0.7
0008:  CLRF   FEA
000A:  CLRF   FE9
000C:  MOVF   FC1,W
000E:  ANDLW  C0
0010:  IORLW  0F
0012:  MOVWF  FC1
0014:  MOVLW  07
0016:  MOVWF  FB4
.................... } 
.................... 
0018:  SLEEP

Configuration Fuses:
   Word  1: 0F00   NOIESO NOFCMEN RESERVED
   Word  2: 1F1F   BROWNOUT WDT BORV25 NOPUT WDT32768
   Word  3: 81F3   CCP2C1 NOLPT1OSC MCLR RESERVED
   Word  4: 0085   STVREN NODEBUG LVP NOXINST BBSIZ1K RESERVED
   Word  5: C00F   NOCPD NOCPB
   Word  6: E00F   NOWRTD NOWRTC NOWRTB
   Word  7: 400F   NOEBTRB


Which is what I expected, I changed the #device line to
Code:
#device *=16  ICD=TRUE


This changed the Configuration Fuses section to
Code:
   Word  1: 0F00   NOIESO NOFCMEN RESERVED
   Word  2: 1E19   NOBROWNOUT NOWDT BORV25 NOPUT WDT32768
   Word  3: 81F3   CCP2C1 NOLPT1OSC MCLR RESERVED
   Word  4: 0000   NOSTVREN DEBUG NOLVP NOXINST BBSIZ1K RESERVED
   Word  5: C0FF   NOPROTECT NOCPD NOCPB
   Word  6: E0FF   NOWRT NOWRTD NOWRTC NOWRTB
   Word  7: 40FF   NOEBTRB NOEBTR


This causes problems when I try to download the code to an ICD-U40 as in the 6622 the last 3 configuration words have only 4 bits in lower byte so the download fails as the actual configuration fuses dont match the fuses generated by the compiler.

Any ideas?
rwyoung



Joined: 12 Nov 2003
Posts: 563
Location: Lawrence, KS USA

View user's profile Send private message Send e-mail

PostPosted: Tue Feb 07, 2006 1:34 pm     Reply with quote

Are you sure
Quote:
Code:
#device *=16
is necessary for the PIC18F6622?
_________________
Rob Young
The Screw-Up Fairy may just visit you but he has crashed on my couch for the last month!
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Tue Feb 07, 2006 5:50 pm     Reply with quote

Quote:
the download fails as the actual configuration fuses dont match
the fuses generated by the compiler.


I compiled your program with PCH vs. 3.242, and I got this result:
Code:
Configuration Fuses:
   Word  1: 0F00   NOIESO NOFCMEN RESERVED
   Word  2: 1F1F   BROWNOUT WDT BORV25 NOPUT WDT32768
   Word  3: 81F3   CCP2C1 NOLPT1OSC MCLR RESERVED
   Word  4: 0085   STVREN NODEBUG LVP NOXINST BBSIZ1K RESERVED
   Word  5: C00F   NOPROTECT NOCPD NOCPB
   Word  6: E00F   NOWRT NOWRTD NOWRTC NOWRTB
   Word  7: 400F   NOEBTRB NOEBTR


Here is the Config Bits line from the HEX file. I added spaces
in between the words to make it easier to read. It looks OK.
Code:
:0E000000 000F 1F1F F381 8500 0FC0 0FE0 0F40 9F


So it's probably just a problem with your version.
ckielstra



Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands

View user's profile Send private message

PostPosted: Wed Feb 08, 2006 2:16 am     Reply with quote

You can fix this yourself by changing the chip configuration using chipedit.exe in the PICC directory.

I compared Chipedit.exe for the 18F6622 in v2.235 and v2.241 and noticed some differences. Change chipedit.exe to the settings below and you should be OK.
Code:

PROTECT   00FF 0000 5
NOPROTECT 00FF 000F 5
WRT       00FF 0000 6
NOWRT     00FF 000F 6
EBTR      00FF 0000 7
NOEBTR    00FF 000F 7
Sigma



Joined: 03 May 2004
Posts: 48
Location: Sg

View user's profile Send private message

PostPosted: Thu Mar 23, 2006 5:15 am     Reply with quote

Hi, ckielstra or any other friend with latest compiler,
Could you please kindly check for me the value for NOWRTC amd NOWRTD for device 18F6622?
I got some error for these two configurations also.
Thanks.
Sigma
Ttelmah
Guest







PostPosted: Thu Mar 23, 2006 6:09 am     Reply with quote

Is it perhaps probable that the problem is caused by putting numeric values after the fuses?...
The effect of this will be 'undefined', and is not legitimate CCS code.

Best Wishes
ckielstra



Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands

View user's profile Send private message

PostPosted: Thu Mar 23, 2006 6:46 am     Reply with quote

Quote:
Could you please kindly check for me the value for NOWRTC amd NOWRTD for device 18F6622?
From a post in another thread I understand you are using v3.236.
The settings for NOWRT and NOWRTD in v3.236 are equal to v3.245, when you compare these settings to the datasheet they seem correct.


Last edited by ckielstra on Thu Mar 23, 2006 7:45 am; edited 2 times in total
ckielstra



Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands

View user's profile Send private message

PostPosted: Thu Mar 23, 2006 7:44 am     Reply with quote

Ttelmah wrote:
Is it perhaps probable that the problem is caused by putting numeric values after the fuses?...
The effect of this will be 'undefined', and is not legitimate CCS code.
This is another example of new extensions to the compiler nowhere mentioned in the release notes.
Sigma



Joined: 03 May 2004
Posts: 48
Location: Sg

View user's profile Send private message

PostPosted: Thu Mar 23, 2006 8:09 am     Reply with quote

Thanks Ttelmah & ckielstra,

First of all, i did not place numeric values after the fuses in my test program. But i tried to do it also. The results are the same.
I did try just a very simple program like
Code:

#include "18f6622.h"
#device ICD=TRUE

#fuses HS, NOWDT
#use delay(clock=20000000)

void main()
{
while(1)
output_high(PIN_A1);
}

Initially there is problem of programming it into the chip. The problem is that after programming process, there is a window popping up, indicating some mismatch of the actual and expected configuration bits. But after using the chipedit technique as ckielstra mentioned, it can be programmed and working properly for this simple program. However, when I tried to use the debug mode, it prompts 'The detected target name:PIC18F6622 does not match the code's target: PIC16C622. Do you want to continue' as i also mentioned in the other link http://www.ccsinfo.com/forum/viewtopic.php?t=26463

So from what i tested today, i would say after the chipediting, it improve the programming process, but not for the debugging.
Why i said 'improve'? Because my colleague just found that it is still having problem of burning in the code while come to a more complex code. The process repeated, but the mismatch of the configuration bits are NOWRTC and NOWRTD. Sorry i could not paste the complete code here as it is too lengthy. Actually this is a code migration process from 18F452 to 18F6622. And we did not expect so many problems.

Dear friends, could we say that this is due to older compiler version? Do you foresee I will get into the same problem when i change the mcu to 18F6627? I think so. But not very sure.
Could we solve it by using the latest version. I do not know.

Please help!

Sigma
Ttelmah
Guest







PostPosted: Thu Mar 23, 2006 8:21 am     Reply with quote

ckielstra wrote:
Ttelmah wrote:
Is it perhaps probable that the problem is caused by putting numeric values after the fuses?...
The effect of this will be 'undefined', and is not legitimate CCS code.
This is another example of new extensions to the compiler nowhere mentioned in the release notes.

Sorry, but the ability to put a number for some things is mentioned, but I don't think the 6622, allows four bits for all three values. I don't know what the effect of setting a config bit that is not supported would be, but it looked like a likely thing to confuse the configuration bits...

Best Wishes
ckielstra



Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands

View user's profile Send private message

PostPosted: Fri Mar 24, 2006 4:01 am     Reply with quote

Ttelmah wrote:
Sorry, but the ability to put a number for some things is mentioned
You are right, I missed this addition to the October 2005 PICC manual. The version 3.226 I'm using doesn't support this feature, v3.236 does. What I don't like is that new features like this are nowhere mentioned. Not in the PICC release notes or readme.txt.

Ttelmah wrote:
but I don't think the 6622, allows four bits for all three values.
The 6622 supports 4 bits for PROTECT, EBTR and WRT, so setting these fuses to a value of 15 as Sigma does is valid.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group