18f4550 running slow?

[Giulio]

Hi,

I recently upgraded to the latest version of pbp3, and it came with mplab 8.85. I'm using these with an ICD2, and the latest versions at first seemed to be less 'buggy' [I used to get spurious errors regularly with previous software versions].

I dusted off some old test projects, and all was well with the 16f628A and 18f2550 stuff I wrote a while back.

However, when I swapped out the 18f2550 from my breadboard, and inserted a 18f4550, things weren't right. I went back to the most basic code, the tried and trusted flashing LED and, sure enough, it seems to be running over ten times slower than it should, at a guesstimate.

The code runs perfectly on a 18f2550, flashing the LED around once a second, but takes over ten seconds on a 18f4550. No problem, I thought, it's an oscillator setting, and so I started changing the config bits. After a whole day pulling my hair out, I cannot get it to work with what seems to be the right timing. I have tried every configuration possible [I'm sure], and no go.


I built a MIDI footpedal for a friend, a while ago, and had the project archived. I re-compiled it, and it doesn't work, that's without changing a line of code. What I now have is the most basic breadboard setup. Connections to Vdd, Vss, PGD, PGC, MCLR [tied with 10k resistor], 20mhz crsytal, and an LED from RB0.

As I said, unplug the perfectly working 18f2550, plug in the 18f4550, change the device and download the 18f4550 code within mplab, and the LED runs over ten times slower.

I Googled 18f4550 running slow, and found one applicable result, and the person on that forum put it down to a pcb issue, and it was never resolved satisfactorily.

I'm convinced it's a software issue, as I have had small 18f4550 projects, including a USB one, working ok.

Has anybody else run into this issue with this device? I need the extra pins on the 4550 for my next project, and it's *really* frustrating to be able to plug a 2550 back in and watch it work perfectly!


The simplest 'code' in the world is included below. I have manually tried changing the config bits, and re-programming again and again, to no avail.

Any pointers would be much appreciated.


G



DEFINE OSC 20

;---------------------------------------------------------------------------------------------
#config
__CONFIG _CONFIG1H, _FOSC_HS_1H
#endconfig
;---------------------------------------------------------------------------------------------

main:

TRISB = 0
lp1:
portb.0 = 1
pause 1000
portb.0 = 0
pause 1000

goto lp1

[J. Mark Wolf]

I experienced something similar to what you describe awhile back.

In my case, the OSCin and OSCout pins were not configured properly in the Config fuses, so the ceramic resonator was failing to run reliably, and it was defaulting to the internal oscillator, which was running at something much slower(possibly 32Khz). This is controlled by the IESO fuse, Int/Ext Oscillator Switch (at least on the 18F2620).

Check your fuses.

[Giulio]

Hi. Thanks for the reply.

I found your post in a search on here, after I posted mine. I've tried every combination of fuse settings you can imagine[!], to no avail. If IESO is 0 then the code fails to run totally. When it's set, the whole thing is much slower than expected.

I had old 4550 code projects that worked, and now do not, under the latest versions of pbp3 and mplab, and that's simply re-compiling them without changing a line of code. I probably need to borrow a 'scope and see what's actually happening, as that would be easier than the mucking about I'm doing.

pbp3 uses the DEFINE OSC [n] to make it's calculations for quite a few other commands, obviously including the pause command. It's as if pbp3 is taking no notice of the OSC directive. I'm now trying to figure out a routine I can write in pure assembler to do the same thing, and see if there's a difference, so I can put the 'blame' in the right place, my breadboard setup, pbp3 or mplab!

I have emailed MELabs, and am waiting for their reply. I hate asking for 'examples', as I'm capable of writing simple stuff, and that request is the usual resort of the lazy, but I'm so flabbergasted by not being able to get on, I'd like an authoritative "THIS WORKS! If it doesn't, it's your breadboard config..." example from MELabs, to put my mind at rest.

Thanks again, for the reply. I'm playing with it as I write, and pulling out what's left of my hair ;-)

G

[mackrackit]

The code for the 2550 will work for the 4550 with the led on RB0 without changing anything.

[Giulio]

No, the code runs much more slowly without changing anything at all, save swapping the connections to the 40-pin 4550, of course. Everything points to the DEFINE OSC directive.

I've written a machine code interrupt routine, which flashes the LED according to an interrupt onTMR0 and, without doing formal timings, it appears to be the same on both devices. This makes sense to my hobbyist brain, as there IS a 20mhz crystal running the chip, and I've set the config bits manually in mplab, as well as setting them in code between the #CONFIG and #ENDCONFIG tags.


However, the pause command is well out, and I'm assuming the problem is with pbp3, as it uses its own DEFINE OSC setting to calculate timings for its commands when compiling them. I've just attached my serial LCD and copied and pasted some lines from a working project, and nothing happened. I played around with some values, and garbage came up on screen. This is symptomatic of the pbp3 problem I've assumed above. Swapped out the 4550 back to the 2550, and voila! LCD messages working perfectly!

I found some threads on here, which say to set the DEFINE OSC to 48, regardless of the actual oscillator, but that does not work either.

I mix and match assembler and pbp3 code. Why re-invent the wheel? The serout and serout2 commands make writing to an LCD a piece of cake, for instance, and I don't have the expertise to write the equivalent routines in assembler. Anyway, that would obviate the need for pbp3 in the first place!

As I said, I'm far from being an expert, but all the signs are that pbp3 and the 4550 are not getting along...

MELabs have not yet replied to me.

G

[Darrel Taylor]

melabs has replied (yesterday), maybe you didn't get the email.

And nothing you've reported "Points to" DEFINE OSC.
What it does suggest is a problem with your oscillator.

If IESO is 0 then the code fails to run totally. When it's set, the whole thing is much slower than expected.

IESO is the "Internal/External Oscillator Switchover bit".
Meaning that on power-up it starts running on the internal oscillator, then when the external oscillator is running and stable it switches over to that.
If the external oscillator is not running properly, it never switches over.

The default (power-on) frequency of the internal oscillator is 1 Mhz, so with DEFINE OSC 20 it will take 20 seconds to execute a PAUSE 1000. And everything else will run at 1/20th speed too.

You say that you are swapping between a 2550 and 4550.
The pins are different. Are you sure you have the crystal and caps on the correct pins after swapping.
On the 2550, it's pins 9 and 10. On the 4550 it's pins 13 and 14.

The 2550 only has one VDD pin and the 4550 has two. Are you connecting both VDD's.

[Demon]

Try this:

@   __CONFIG    _CONFIG1L, _PLLDIV_5_1L & _CPUDIV_OSC1_PLL2_1L & _USBDIV_2_1L
@   __CONFIG    _CONFIG1H, _FOSC_HSPLL_HS_1H & _FCMEN_OFF_1H & _IESO_OFF_1H
@   __CONFIG    _CONFIG2L, _PWRT_OFF_2L & _BOR_ON_2L & _BORV_1_2L & _VREGEN_ON_2L
@   __CONFIG    _CONFIG2H, _WDT_OFF_2H
@   __CONFIG    _CONFIG3H, _CCP2MX_OFF_3H & _PBADEN_OFF_3H & _LPT1OSC_OFF_3H & _MCLRE_ON_3H
@   __CONFIG    _CONFIG4L, _STVREN_ON_4L & _LVP_OFF_4L & _ICPRT_OFF_4L & _XINST_OFF_4L & _DEBUG_OFF_4L

DEFINE OSC 48

TRISA = %00000000
TRISB = %00000000
TRISC = %00000000
TRISD = %00000000
TRISE = %00000000

ADCON1 = %00001111

Led var PORTC.2

Loopthis:
  toggle Led
  pause 500
  goto LoopThis

END

It blinks at 1 second intervals on my 18F4550 using external 20 MHz oscillator.

Robert

[Giulio]

I stand corrected. MELabs did reply [thanks Darrel], and the mail somehow found its way into my spam folder?

By way of an apology, sorry if it sounded like I was complaining. I most certainly was not. Their support, when I've contacted them in the past, has been immediate, and first rate. I only mentioned it above in case anybody asked if I'd contacted them.

Darrel sent the following fuse settings, which worked! Thought I'd tried every combination, but obviously had not. Thank you Darrel !

G

p.s. Thanks too, to Demon, for your settings example, and everybody else that took time out to help a confused hobbyist!

#CONFIG
CONFIG PLLDIV = 5 ; Divide by 5 (20 MHz oscillator input)
CONFIG CPUDIV = OSC1_PLL2 ; [Primary Oscillator Src: /1][96 MHz PLL Src: /2]
CONFIG USBDIV = 2 ; USB clock source comes from the 96 MHz PLL divided by 2
CONFIG FOSC = HS ; HS oscillator, PLL enabled (HSPLL)
CONFIG FCMEN = OFF ; Fail-Safe Clock Monitor disabled
CONFIG IESO = OFF ; Oscillator Switchover mode disabled
CONFIG PWRT = OFF ; PWRT disabled
CONFIG BOR = ON ; Brown-out Reset enabled in hardware only (SBOREN is disabled)
CONFIG BORV = 3 ; Minimum setting
CONFIG VREGEN = ON ; USB voltage regulator enabled
CONFIG WDT = ON ; WDT enabled
CONFIG WDTPS = 512 ; 1:512
CONFIG CCP2MX = ON ; CCP2 input/output is multiplexed with RC1
CONFIG PBADEN = OFF ; PORTB<4:0> pins are configured as digital I/O on Reset
CONFIG LPT1OSC = OFF ; Timer1 configured for higher power operation
CONFIG MCLRE = ON ; MCLR pin enabled; RE3 input pin disabled
CONFIG STVREN = ON ; Stack full/underflow will cause Reset
CONFIG LVP = OFF ; Single-Supply ICSP disabled
CONFIG ICPRT = OFF ; ICPORT disabled
CONFIG XINST = OFF ; Instruction set extension and Indexed Addressing mode disabled (Legacy mode)
CONFIG DEBUG = OFF ; Background debugger disabled, RB6 and RB7 configured as general purpose I/O pins
#ENDCONFIG

[J. Mark Wolf]

Which fuse made the difference to your problem?

[Giulio]

Well, that's poor form on my behalf, as I'm not sure!

I was changing them in mplab, trying every combination [or so I though], but not keeping track, which is a 'random' approach to solving a problem, and nothing to be proud of.

My frustration got the better of me. I shall remove the settings that Darrel sent me, and have a look at the default, and see what happens, as I should be documenting this, for my own reference...

G