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

CCS, MPLAB & ICD2....Who's in charge of the fuses ???

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



Joined: 05 Aug 2006
Posts: 149
Location: Redditch, UK

View user's profile Send private message Visit poster's website

CCS, MPLAB & ICD2....Who's in charge of the fuses ???
PostPosted: Sat Oct 25, 2008 6:22 am     Reply with quote

I have had a problem with getting the correct fuses program in an 18F24J10.

My development setup is as follows :

IDE - MPLAB 8.10 & ccs plugin
Compiler - CCS PCH 3.249
Programmer - ICD2

Now the fuse statement in my code is :
Code:
#include <18F24J10.h>

#use delay(clock=40000000)
#fuses PRIMARY,H4_SW,NOIESO,NOXINST,NOWDT,NOPROTECT,NOFCMEN,CCP2C1

#use rs232(BAUD=9600, PARITY=N, BITS=8, XMIT=PIN_C6,RCV=PIN_C7,ENABLE=PIN_C0, ERRORS)

#byte OSCTUNE = 0xF9B
#bit PLLEN = OSCTUNE.6

#define   LED_RED      PIN_B3
#define   LED_GREEN   PIN_B4

void main()
{
   PLLEN = 1;    // Enable PLL

   port_b_pullups(FALSE) ;
   set_tris_b(0b11100111) ;

   while(1) {
      putc('A') ;
      output_bit(LED_RED, 0) ;
      output_bit(LED_GREEN, 1) ;
      delay_ms(500) ;
      putc('B') ;
      output_bit(LED_RED, 1) ;
      output_bit(LED_GREEN, 0) ;
      delay_ms(500) ;
   }
}


and when compiled it produces the following in the Lst and Hex Files:
Code:
THE LST FILE
=============
Configuration Fuses:
   Word  1: 04A0   NODEBUG NOXINST STVREN NOWDT NOPROTECT
   Word  2: 0F05   H4_SW WDT32768 NOFCMEN NOIESO PRIMARY
   Word  3: 03F8   CCP2C1

ie [ 04A0 0F05 03F8 ]


The Hex File
============
:0600B000FBD7E3D70300BB
:020000040030CA
:06000000A004050FF80347
:00000001FF
;PIC18F24J10

ie [ 04A0 0F05 03F8 ]


Which all looks correct to me Very Happy

If I program the chip using my ICD2 from MPLAB then board behaves as if the oscillator mode is HS and not H4_PLL. ie it runs at 10Mhz instead of 40Mhz.

To verify this I read the chips fuses back using my Mach-X programmer and got a different set of fuses ! Shocked

Code:
Read Back With Mach-X
=====================
F4A1 FF04 F000

NODEBUG
NOXINST
STVREN
WDT
NOPROTECT
RESERVED
HS
WDT32768
NOFCMEN
NOIESO
PRIMARY
RESERVED
CCP2B3
RESERVED


So who's in control Question

The answer appears to be MPLAB Exclamation Shocked

Having looked at the setting of configuration bits set in my MPLAB it appears that the Osc Mode is set to HS and not H4_PLL. ie it had the following settings
Code:
MPLAB Config Bits (Configuration Bits Set In Code - Ticked)
============================================================
F4A1 FF04 F000


So my question is why does the ICD2 use the fuses set in MPLAB and not the hex file even though I have the "use bits set in code" box ticked. Question

I can fix the probelm by un-ticking "use bits from code" and setting the Osc mode to H4_PLL and then re-applying the tick.
Ttelmah
Guest







PostPosted: Sat Oct 25, 2008 9:21 am     Reply with quote

At the end of the day, the device that actually programs the chip, is always 'in charge'. CCS, can 'ask' for the fuses it wants, but it is the device doing the programming, that actually determines whether the request is sent to the chip. So, is is common (for example), for fuses for things like code protection, to always be overridden, if you are using an ICD.
It is worth commenting, that fuse for things like the PLL, won't update inside the ICD, till the system is restarted. So, if you make a change to the PLL, then check inside the ICD, the fuse will still be shown in it's 'old' state, till you shutdown the chip, and reboot. The setting for this is only read by the hardware at initial wakeup. The same is true if you program a chip using a bootloader.

Best Wishes
nurquhar



Joined: 05 Aug 2006
Posts: 149
Location: Redditch, UK

View user's profile Send private message Visit poster's website

PostPosted: Sat Oct 25, 2008 9:50 am     Reply with quote

My observations were that when I change the HS/H4_PLL fuse setting in source code and then did compile/ICD2 program/release from reset there was no effect.

When I changed the HS/H4_PLL fuse in the MPLAB configurations bits (Rember that "use config bits from code" is on!) then did compile/ICD2 program/release from reset then the fuse change was evident.

I confirmed the actual fuse settings by reading back the device using a different programmer.

All I can conclude is this that "use config bits from code" flag in MPLAB does not do what it says. Unless you know otherwise ? I take your point about there being certain exceptions to program control like the Debug fuse but I don't see why the OSC clock mode should be one of them.

Indeed MPLAB is also contolling the CCP2 C1/B3 fuse against the source codes will.
FvM



Joined: 27 Aug 2008
Posts: 2337
Location: Germany

View user's profile Send private message

PostPosted: Sun Oct 26, 2008 2:09 am     Reply with quote

You can see, that MPLAB (I checked with V8.10) is expecting PIC18F24J10 configuration data at address 3FF8 while your hex file is using address 30000. This can't work, MPLAB is simply ignoring the fuse data. Most recent PCH V4.081 has an entry of 3FF8 in device database, 3.249 may have a wrong entry. I seems to me, that also the coding of some fuse bits may be wrong, but I didn't check in detail.
Ttelmah
Guest







PostPosted: Sun Oct 26, 2008 3:26 am     Reply with quote

Yes. This was covered years ago, when 3.249, was 'current'. Indeed I complained about it to CCS within a few weeks of 3.249 coming out.
I didn't spot the poster was using 3.249.

Basically, these chips, have their 'fuses' at 30000, but stored in a special area of _RAM_ at this location. This RAM is only writable immediately after boot. The chip automatically copies the bytes stored in the top few locations of the code memory, into this RAM, on bootup.

3.249, still puts the fuse bytes into the programming information at 30000, which will never work.

You can include your own fuse patterns, into your code, by adding a #ROM statement, with the required values. I posted about this at the time.

Best Wishes
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