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 CCS Technical Support

operative clock problem
Goto page 1, 2  Next
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
antosci



Joined: 29 Apr 2013
Posts: 13

View user's profile Send private message

operative clock problem
PostPosted: Mon Nov 03, 2014 5:42 pm     Reply with quote

hi, i'm trying to blink a led... a simply led blinking, cause i attempted to communicate trough rs232 (ftdi232rl chip) to pc. Messages should arrive to pc with one second delay, instead they arrive with 4 second delay. and the baud rate isn't 9600 as i setted in the firmware. it's 2400.
I understood there is someting wrong with clock.
I'm using led blinking example with delay_ms(1000);
but the led is on for 4 seconds and off for 4 seconds.
i don't understand...

Code:

#include <main.h>

void main()
{

   //Example blinking LED program
   while(true)
   {
      output_low(LED);
      delay_ms(DELAY);
      output_high(LED);
      delay_ms(DELAY);
   }

}


ans here is the.h
Code:

#include <18F2550.h>
#device ADC=16

#FUSES NOWDT                    //No Watch Dog Timer
#FUSES WDT128                   //Watch Dog Timer uses 1:128 Postscale
#FUSES NOBROWNOUT               //No brownout reset
#FUSES NOLVP                    //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#FUSES NOXINST                  //Extended set extension and Indexed Addressing mode disabled (Legacy mode)

#use delay(internal=8000000)

#define LED PIN_B5
#define DELAY 1000



i hope there's someone who can help me...
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Mon Nov 03, 2014 7:20 pm     Reply with quote

I was able to fix it by adding CPUDIV1 to the #fuses, but I'm not sure why
that works, because the oscillator diagram in the 18F2550 data sheet
does not show the internal oscillator going through the CPUDIV block.
temtronic



Joined: 01 Jul 2010
Posts: 9241
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Mon Nov 03, 2014 8:51 pm     Reply with quote

Could be a compiler version bug where the registers used to configure he clock are wrong? or the selection of internal vs. external is wrong ?
You should post your compiler version, others may know.
it is 'strange' to say the least !



Jay
antosci



Joined: 29 Apr 2013
Posts: 13

View user's profile Send private message

PostPosted: Tue Nov 04, 2014 7:11 am     Reply with quote

my version is pcwhd 5.025... and with #FUSES CPUDIV1 it all works.
but i don't understand why !
thank's a lot
Ttelmah



Joined: 11 Mar 2010
Posts: 19537

View user's profile Send private message

PostPosted: Tue Nov 04, 2014 10:20 am     Reply with quote

I agree you should not need CPUDIV1, but my guess would be that this 'accidentally' makes the compiler write to the OSCCON register.
Normally when using the internal RC, you have to manually force this with the line:

setup_oscillator(OSC_8MHZ);

at the start of your main code.

When using INT_RC mode, the oscillator speed is set in the code _after_ boot, not in the fuses. The chip defaults to waking at 1MHz (surprised it gives 4 seconds, not 8...).

I have to ask, why you are using a USB chip, with the internal oscillator?. Seems a waste of pins, since this chip cannot give USB like this.
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Tue Nov 04, 2014 10:29 pm     Reply with quote

When using the INTRC_IO fuse with the 18F4550, if you add this line to
main(), then CPUDIV1 is not needed:
Code:
setup_oscillator(OSC_8MHZ | OSC_INTRC);

With the line above, OSCCON is set to 0x72. Without that line, it's set to
0x70 in the startup code in main(). The only difference is in the SCS bits
which select between the internal and primary oscillator.

This makes me think that the oscillator circuit for 18F4550 is more like
the one for 18F45K50. In the 18F45K50 diagram, if you choose Primary
oscillator with the SCS bits, then the INTOSC signal is taken through the
CPUDIV circuit. If you choose Internal Oscillator, then INTOSC skips
the CPUDIV and is taken directly to the output mux. That explains what
we are seeing here.

I think the oscillator diagram of 18F4550 is incorrect. All these years.
Ttelmah



Joined: 11 Mar 2010
Posts: 19537

View user's profile Send private message

PostPosted: Wed Nov 05, 2014 4:22 am     Reply with quote

Yes.

This is doubly 'confirmed' by the speed being seen. The default for the INT_RC route, is 1MHz, but if the 8MHz INT_RC is being routed to the CPUDIV divider, the default for this divider, is /4. 8MHz/4, then gives the 2Mhz being seen.
I suspect nobody has noticed, since as you have to have a crystal to use USB, it is more common to only use the RC oscillator for things like sleep operation, where a lower speed is selected.
On chips where the USB can be locked to a PLL off the incoming USB bus, so an accurate oscillator is not needed, this route is instead often used.
An interesting 'missing line' on the published circuit diagram.....
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Wed Nov 05, 2014 3:05 pm     Reply with quote

Here is a modified oscillator diagram for the 18F4550:




-----
Edit: Re-uploaded to imgur for longer preservation.


Last edited by PCM programmer on Mon Nov 19, 2018 3:06 am; edited 1 time in total
Ttelmah



Joined: 11 Mar 2010
Posts: 19537

View user's profile Send private message

PostPosted: Thu Nov 06, 2014 1:28 am     Reply with quote

I suspect the route would be directly from the line joining the 8MHz between the INTOSC postscaler, and the MUX, , not from the output of the MUX. If you look at the other chips where this line is present, it is normally from this point.

Best Wishes
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Fri Nov 07, 2014 1:47 pm     Reply with quote

I disagree. If I test it with 1 MHz or 2 MHz, or 31000 Hz, it behaves in
the same way. This means the output of the internal RC divider (mux)
is applied to the CPUDIV block.
Ttelmah



Joined: 11 Mar 2010
Posts: 19537

View user's profile Send private message

PostPosted: Sun Nov 09, 2014 5:09 am     Reply with quote

If it 'behaves the same way', then it must come from before the Mux.

If it changes, then it'd come from after.

Best Wishes
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Sun Nov 09, 2014 10:35 am     Reply with quote

Quote:

I suspect the route would be directly from the line joining the 8MHz
between the INTOSC postscaler, and the MUX, not from the output of the
MUX. If you look at the other chips where this line is present, it is
normally from this point.

Can you post the name of a PIC that has this in the data sheet ?
Where only 8 MHz goes into CPUDIV ?
Ttelmah



Joined: 11 Mar 2010
Posts: 19537

View user's profile Send private message

PostPosted: Sun Nov 09, 2014 3:38 pm     Reply with quote

Look for instance at the 46J50. The internal 8MHz oscillator is taken before the MUX, and this or the primary oscillator can be selected to feed CPUDIV.
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Sun Nov 09, 2014 5:21 pm     Reply with quote

OK, I see what you mean now. I modeled my diagram off the 18F45K50.
Ttelmah



Joined: 11 Mar 2010
Posts: 19537

View user's profile Send private message

PostPosted: Mon Nov 10, 2014 1:14 am     Reply with quote

There seem to be three variants:

1) Takes one branch before the MUX (46J50)
2) Takes multiple branches before the MUX (4620)
3) Takes the output of the MUX (45K50)

Only a sequential test of the speeds achieved with all the combinations, would 'prove' which the chip has.

In my memory, I've seen far more chips doing '1' or '2', than '3'. May be wrong, but I think that is the case.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 
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