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

24HJ256GP210 won't use external xtal

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



Joined: 07 Sep 2003
Posts: 755
Location: Florida

View user's profile Send private message AIM Address

24HJ256GP210 won't use external xtal
PostPosted: Mon Nov 12, 2012 11:10 am     Reply with quote

Info

CCS 4.137
There is an ETT motherboard with a 8Mhz xtal on the mother board.
There are carrier boards that do have individual chips on them. The chips have to be and are pin compatible.
Small variation

The 24FJ256GB210 has ICSP2 where the 24HJ256GP210 has ICSP1
but apart from that they are pin compatible plus the ISCP1 to ICSP2 swap is a compiler directive

Issue
If a 24FJ256GB210 carrier board is plugged in the code runs correctly at 32Mhz with the change to ICSP2 device ICD2 and the correct dev.h file in the code below.

With a 24HJ256GP210.h the internal osc at 7.47 Mhz is always used
and the #use delay(clock=32Mhz,xtal=8Mhz) seems to be ignored.

I know I can set things up by writing to the SFR's but I wonder if I am doing something wrong.
The code below compiles without error but incorrectly runs at 7.47 Mhz
( the internal osc of 7.37 plus some error).

Code:

#include <24HJ256GP210.h>
///// notes
//// Nov 11 2012 osc is showing 7.47 Mhz something with the fuses 24FJ is not working
///  HJ uses ICD1 device must be on second line
//// ETT board has a push switch make sure orange for debug is on ( near switch)
#device ICD=1

//#FUSES WPRES32                  //Watch Dog Timer PreScalar 1:32
//#FUSES WPOSTS1                  //Watch Dog Timer PostScalar 1:1
//#FUSES CKSFSM                   //Clock Switching is enabled, fail Safe clock monitor is enabled

#FUSES HS,ICSP1
#use delay(clock=32Mhz,xtal=8Mhz) //// compiler sets fuses and PLL values automatically


#use fixed_IO(E_outputs = PIN_E0,PIN_E0,PIN_E1,PIN_E1,PIN_E2,PIN_E2)

#use rs232(debugger)
void main()
{
int8 i=0;
///// use 3.3v ICDU64 programmer
//// ETT demo PIC32 KIt board doesn't have telco pin 6 blue wire connected
////          Aux is wired on back of board blue wire to pin 22 ..RB3


 
 printf("hello\n\r");

 while(1)
 {

 printf("i=%u\n\r",i++);
 delay_ms(200);
 output_toggle(PIN_A0);
 output_toggle(PIN_A1);
 output_toggle(PIN_A2);
 output_toggle(PIN_A3);
 }

}

Code:
.................... #use delay(clock=32Mhz,xtal=8Mhz) //// compiler sets fuses and PLL values automatically
002FE:  CP0     W0
00300:  BTSC.B  42.1
00302:  BRA     30C
00304:  REPEAT  #3E7B
00306:  NOP     
00308:  DEC     W0,W0
0030A:  BRA     NZ,304
0030C:  RETURN 
Ttelmah



Joined: 11 Mar 2010
Posts: 19365

View user's profile Send private message

PostPosted: Tue Nov 13, 2012 10:35 am     Reply with quote

First thing I'd suggest is avoiding the line:

The compiler is medium good at basic settings, but for things like the USB chips, and the PIC24 chips with huge numbers of combinations of prescalers, PLL, and postscalers, I have never found the 'automatic' settings to 100% work. I'd be a bit more explicit.
My guess is that it is selecting an invalid set of options for these settings, and then FSCM is triggering, so it falls back to the internal oscillator.
You are setting an oscillator rate that is not possible without the PLL, but are explicitly disabling the PLL (selecting HS).

Testing the code you post, compiling it, and looking at the fuses in the .LST file, has the compiler selecting FRC as the primary source.

No warranties, but selecting:
Code:

#FUSES XT,PR_PLL,NOOSCIO,ICSP1, NOCKSFSM,  NOJTAG
#use delay(clock=32Mhz,xtal=8Mhz)

//and

setup_oscillator(OSC_CRYSTAL);
//at the start of main, has the fuses saying that it is to start on FRC,
// then switch. Haven't looked at whether the PLL settings are right
//though.....

You probably need to use something like MPLAB, and walk the code through to the start of the main after this, and see how everything is set, then work out how to change what is wrong.

Best Wishes
Douglas Kennedy



Joined: 07 Sep 2003
Posts: 755
Location: Florida

View user's profile Send private message AIM Address

PostPosted: Tue Nov 13, 2012 11:41 am     Reply with quote

Thanks for the above idea. With the suggested code 24HJ still won't use the external xtal. It maybe a CCS free feature ( aka a bug). There is a very small difference ( Microchip data sheet) in the pin naming between the 24FJ and the 24HJ for the OSC pins 63,64.
The 24HJ labels them OSC1 OSC2 but the 24FJ uses OSC0 OSC1.
Anyway I can complete the immediate project with the 24FJ and come back to the 24HJ issue later.
newguy



Joined: 24 Jun 2004
Posts: 1903

View user's profile Send private message

PostPosted: Tue Nov 13, 2012 11:52 am     Reply with quote

Might be related, might not....

I'm neck deep in dsPIC33 development and to begin I started with a CCS development kit (actually the DSP Analog dev kit).

Didn't take long for me to discover that the CCS supplied board had serious stability issues - wouldn't always oscillate. They have a 12MHz crystal on the PCB and the dsPIC's internal PLL would then bump this up to 80MHz internal.

Part of the fault lay with the CCS built-in functions. The 12MHz crystal was responsible for the rest. Turns out, deep in the data sheets for this family, that a dsPIC can't startup with the PLL enabled from an external crystal higher than some frequency (can't remember the specifics), and the 12MHz crystal was too high.

What I had to do was startup the processor with the internal oscillator, then do a clock switch over to the external crystal with the PLL. I actually had to do this in assembly. Microchip has some app notes with the procedure/code - the switchover is "protected" by some register "hoops" you have to jump through to get the job done and timing is critical.

Code:
#word CLKDIV = getenv("sfr:CLKDIV")
#bit PLLPOST0 = CLKDIV.6
#bit PLLPOST1 = CLKDIV.7
#word PLLFBD = getenv("sfr:PLLFBD")
struct struct_OSCCON {
   int1 oswen;    //0      // oscillator switch enable
   int1 lposcen;  //1      // secondary (LP) oscillator enable
   int1 unused1;  //2
   int1 cf;       //3      // clock fail detect bit
   int1 unused2;  //4
   int1 lock;     //5      // PLL lock status
   int1 unused3;  //6
   int1 clklock;  //7      // clock lock enable
   int nosc:3;    //8-10   // new oscillator selection
   int1 unused4;  //11
   int cosc:3;    //12-14  // current oscillator selection
   int1 unused5;  //15
};
struct struct_OSCCON OSCCON;
#word OSCCON = getenv("sfr:OSCCON")
#byte OSCCONL = 0x0742
#byte OSCCONH = 0x0743

void setup_pll(void) {
   // This function is required because the dsPIC cannot startup with a 12MHz xtal
   // from powerup (not reliably, anyway). Must start the PIC using the internal
   // RC oscillator, then switch over to the external xtal with PLL. This also
   // requires a very time sensitive unlock sequence to directly access the
   // necessary registers to perform this task. #asm taken directly from
   // a microchip app note.
   
   // 12MHz xtal -> PLLPRE divider (N1) -> multiplier -> VCO -> PLLPOST divider (N2) -> Fosc
   //                                          ^         |
   //                                          |------PLLDIV (M)
   
   // 12MHz / 3 = 4MHz x 40 = 160MHz / 2 = 80MHz
   //         N1         M             N2
   
   // M = 38 (40 - 2), N1 = 1 (3 - 2), N2 = 0 (2)
   // N1
   CLKDIV = 1; // PLLPRE
   // N2
   PLLPOST0 = 0;
   PLLPOST1 = 0;
   // M
   PLLFBD = 38;
   
   output_c(0x8000);
   set_tris_c(0x1000); // initially set CLKO high to kickstart xtal - shouldn't be necessary
   // but it works very reliably, so I'm leaving it in
   delay_us(1);
   
   #asm
   MOV #0x03, w0
   MOV OSCCONH, w1
   MOV #0x78, w2
   MOV #0x9A, w3
   MOV.B w2, [w1]
   MOV.B w3, [w1]
   MOV.B w0, [w1]
   
   MOV #0x01, w0
   MOV OSCCONL, w1
   MOV #0x46, w2
   MOV #0x57, w3
   MOV.B w2, [w1]
   MOV.B w3, [w1]
   MOV.B w0, [w1]
   #endasm
   
   while(OSCCON.cosc != 3); // wait for switchover to occur
   
   while (!OSCCON.lock); // wait for PLL to lock
   
   #use delay(clock=80000000,RESTART_WDT) // have to let the compiler know we're running at 80MHz now
   OSCCON.clklock = 1;
}
Douglas Kennedy



Joined: 07 Sep 2003
Posts: 755
Location: Florida

View user's profile Send private message AIM Address

PostPosted: Tue Nov 13, 2012 3:41 pm     Reply with quote

newguy
The 24H and the ds33 are very similar as to the PLL set up. No smoking gun but it sure looks like my external xtal isn't getting to oscillate.
I'm trying your code (BTW thanks for the code) but it is hanging at the
OSCCON.cosc test should be 3=Primary oscillator (XT, HS, EC) with PLL after the changeover from FRC but I'm still seeing 0 =FRC
here are my fuses
Code:

#fuses FRC,NOOSCIO,ICSP1, CKSNOFSM,  NOJTAG
newguy



Joined: 24 Jun 2004
Posts: 1903

View user's profile Send private message

PostPosted: Tue Nov 13, 2012 5:19 pm     Reply with quote

Here are my fuses. setup_pll() is the first thing called in main().

Code:
#include <33FJ256GP710A.h>

#FUSES WPRES128                 //Watch Dog Timer PreScalar 1:128
#FUSES WPOSTS12                 //Watch Dog Timer PostScalar 1:12
#FUSES PR_PLL                   //Primary Oscillator with PLL
#FUSES HS                       //High speed Osc (> 4mhz for PCM/PCH) (>10mhz for PCD)
#FUSES CKSNOFSM                 //Clock Switching is enabled, fail Safe clock monitor is disabled
#FUSES NOJTAG                   //JTAG disabled
#FUSES PUT128                   //128ms PowerUp Timer
#FUSES ICSP1                    //ICD uses PGC1/PGD1 Pins
#FUSES NODEBUG                  //No Debug Mode for ICD
#FUSES IESO                     //Internal External Switchover Mode Enabled

#use delay(internal=7370000,RESTART_WDT) // use internal RC oscillator initially, see setup_pll() as to why

#use rs232(UART1,baud=57600,parity=N,bits=8,stream=UPSTREAM_PORT,errors)
#use rs232(UART2,baud=57600,parity=N,bits=8,stream=DOWNSTREAM_PORT,errors)

#BUILD (stack=0x300)
Douglas Kennedy



Joined: 07 Sep 2003
Posts: 755
Location: Florida

View user's profile Send private message AIM Address

PostPosted: Wed Nov 14, 2012 3:18 am     Reply with quote

newguy
Your switch code from internal RC osc to Extenal osc with PLL plus
#fuses XT,PR_PLL,ICSP1,PUT128,IESO, NOJTAG
got the osc to come up at 80MHZ ( small mod in your PLL set up
CLKDIV = 0;( to account for my 8mhx xtal)
I suspect the CCS #use delay(clock=80Mhz,osc=8Mhz) is broken for this chip. Not fully proven it may just be hard to get my ext xtal to start and oscillate. When I get some time I'll swap out my xtal and 20pf caps for an oscillator and see what happens.

I'm using an ICD-U64 for testing ..it also has an issue. It is measuring the freq as 48.76 Mhz instead of 80Mhz ......probably it just can't measure much above 40 Mhz.
Again thanks for the assistance
newguy



Joined: 24 Jun 2004
Posts: 1903

View user's profile Send private message

PostPosted: Wed Nov 14, 2012 9:36 am     Reply with quote

Glad you got it working. In general I really like the dsPICs I've been playing with, but the learning curve is really steep. The compiler just doesn't support them to the same extent as with the 16 and 18 series PICs I'm used to.

Might I suggest you place something in the code library for anyone else facing this issue in future?
Douglas Kennedy



Joined: 07 Sep 2003
Posts: 755
Location: Florida

View user's profile Send private message AIM Address

PostPosted: Wed Nov 14, 2012 3:40 pm     Reply with quote

I was able to overclock the 24HJ256GP210 to 100mHz or 50 mips.
It can do 1million 64 bit floating pt divisions in approx 25 seconds.
This is going into a math project that needs a good many flops.
I'm pretty sure
#use delay(clock=80Mhz,osc=8Mhz) messes things up. Yet it could be that CCS expects OSCCON to be unlocked. I'll do some more testing before raising it as a bug.
As to posting in the code library..I just got this chip to work today ...It is not tested by me to the point it merits me promoting it to the code library. So far today it has started every time it was asked to. It is a necessary workaround for the moment. Again thanks newguy for the ideas.
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