_OSC_RCIO6_1H
Is not what you want
Try this
__CONFIG _CONFIG1H, _OSC_HS_1H & _FCMEN_OFF_1H & _IESO_OFF_1H
Then in your code
DEFINE OSC ??
?? being the speed of your external
_OSC_RCIO6_1H
Is not what you want
Try this
__CONFIG _CONFIG1H, _OSC_HS_1H & _FCMEN_OFF_1H & _IESO_OFF_1H
Then in your code
DEFINE OSC ??
?? being the speed of your external
Dave
Always wear safety glasses while programming.
The datasheet for the PIC18F2520 shows "ECIO" for "external clock with IO on RA6, and the P18F2520.INC file in MPASM sort of modified that to "_OSC_ECIO6_1H", so that's what I used. Using "_OSC_HS_1H", works, but gives me the same 25 second wait at power-up. I'm not using a crystal, I'm using an external oscillator/clock.
What exactly are you using for a clock? Is it running?
What is the speed?
Do you have DEFINE OSC xx in your code?
Dave
Always wear safety glasses while programming.
Once it finally starts does it run correctly?
Dave
Always wear safety glasses while programming.
Yes, it does. Regarding the EC settings, I tried using "_OSC_EC_1H", and did verify that I was getting 5 MHz (1/4 freq), out on A6. I'll be glad when this "CONFIG WIZARD" is working.![]()
I didn't see your other questions... I'm using an external 20 MHz oscillator., and "DEFINE OSC 20" is in my code. I didn't have any trouble setting EITHER HS or EC settings (wierd), but it's the power-up delay that's confusing. Don't see a reason for it.
HS should be it. OSC input on both OSC pins.
What about MCLR?
Is it pulled high?
Since the time-outs occur from the POR pulse, if MCLR
is kept low long enough, all time-outs will expire. Bringing
MCLR high will begin execution immediately
(Figure 4-5). This is useful for testing purposes or to
synchronize more than one PIC18FXXXX device
operating in parallel.
Dave
Always wear safety glasses while programming.
Bookmarks