|
|
View previous topic :: View next topic |
Author |
Message |
nurquhar
Joined: 05 Aug 2006 Posts: 149 Location: Redditch, UK
|
CCS, MPLAB & ICD2....Who's in charge of the fuses ??? |
Posted: Sat Oct 25, 2008 6:22 am |
|
|
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
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 !
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
The answer appears to be MPLAB
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.
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
|
|
Posted: Sat Oct 25, 2008 9:21 am |
|
|
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
|
|
Posted: Sat Oct 25, 2008 9:50 am |
|
|
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
|
|
Posted: Sun Oct 26, 2008 2:09 am |
|
|
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
|
|
Posted: Sun Oct 26, 2008 3:26 am |
|
|
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 |
|
|
|
|
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
|