Clock will not start

[echase]

I have switched my code/hardware from a 16F690 to a 18F14K22. No real changes apart from config file. Can not get the clock to start no matter that oscillator configuration I use: internal, HS, clock out or not, 1 or 16MHz, PLL on or off, Primary Clock Enable on or off, 2 different PIC samples, with and without a RC reset circuit on MCLR pin. What am I doing wrong? Are you sure PPP for the PIC is fully tested as it is quite a new chip? Am using same PCB as before as it is a pin compatible chip. Checked can still programme the 690 on this PCB with V5.

I did get it running briefly but 'scope showed the frequency on clock out pin to be not quite correct. Difficult to be sure.

Attached is the config file. Tried lots of variants on it apart from on the bottom half as do not understand what many of those selections do.

[medelec35]

Hi echase,
The only thing I can see that can cause an issue is Low voltage programming is enabled.
You can try disabling it.

Ben posted a good point:

For my two pence worth if LVP is enabled and you do not have a pull down resistor connected to that pin then there is a chance of the pin floating high and putting the device into program mode while the program should be running. In all instances I would recommend to disable LVP, it just muddies the water and can cause problems like this that are very hard to troubleshoot unless you know about the complications with LVP. It seems Microchip agree with this as the LVP seems to have been dropped altogether from newer devices with VPP of 9V.

Could be a programming rather than a configuration issue?
Do you know if target device has been programmed and verified ok?
You could try reading the code from the chip, and comparing hex files with the one you programmed with.

How are you programming device, with PPP?
As far as I know, PPP can't program these devices, so you will need to use programmer like PICkit.

[echase]

You could be right, will try it later. I have an LCD connected to the LVP pin so it’s not actually floating but the LCD could be forcing it high. The time I had it vaguely working may have been before the LCD was plugged in.

I am using PPP and a PICKit 2 to programme.

What Flowcode generated file are the config words and clock speed stored in? I could read it and compare it against the datasheet to see if PPP is getting it right.

Love the addition of PPP into the V5 interface as I was forever having trouble getting the right config words in V3. But any chance of improving Flowcode’s user interface for clock speed entry? When a PLL multiplier is used it is not clear if one is supposed to enter the oscillator speed or the internal clock speed, i.e. the speed before or after the PLL? I interpreted “clock speed” as the latter but now believe it should be the former. It would be better to use the words “oscillator speed” rather than “clock speed” on the selection menu.

Is there a tutorial somewhere on the more esoteric features of the config like boot block size, extended instruction set, stack overflow reset? Reading the datasheet only gives me marginally more idea what to set these at.

[Benj]

Hello,

The clock speed in Flowcode refers to the clock being presented to the microcontroller after any PLL action has taken place but before any pre-scaler action is performed.

For example a standard USB PIC will have a clock speed defined as 48000000 in the project options which translates into 12MIPs because of the divide by 4 prescaler. The actual crystal oscillator used for one of these can be as low as 4MHz.

The newer 18F devices and the 16-bit range get a bit complicated as you have to enable the PLL in the config and then execute a bit of C code at the start of your program to fire up the PLL.

[echase]

I need 64Mhz i.e. 16Mhz internal or external oscillator and PLL set by PPP.

Do I enter 64Mhz or 16Mhz in the menu and do I have to write this bit of C code for the PLL or has Flowcode done it for me? If I need to, what is the Code?

[saschech@gmx.de]

Hello Echase

Must do in c-code and config.for me it work well.
For test i build a 10msec flasher and schow the output on a portpin with a scope .

Regards Wolfgang

[Benj]

Hello,

I need 64Mhz i.e. 16Mhz internal or external oscillator and PLL set by PPP.

Do I enter 64Mhz or 16Mhz in the menu and do I have to write this bit of C code for the PLL or has Flowcode done it for me? If I need to, what is the Code?

Firstly PLL is not always multiply by 4 on all devices so be careful.

In this case you would place 64000000 into the Flowcode project options as that is the clock frequency you are using after the PLL stage.

Again the C code would depend on which device you are using. The device datasheet should detail all the things you need to do to enable the PLL.

Looking at it on the 14K22 device you do not need any C code and you can simply enable the 4x PLL in the configuration settings. If you set the oscillator type to HS then you can use an external 16MHz crystal to drive the PLL which will give you the end clock speed of 64MHz to match the setting in the Flowcode project options.

I would recommend playing around with the fail safe and switchover mode config settings as I know these can cause the PLL to not function correctly on startup.

[saschech@gmx.de]

Hello Benj

At new i have a error for ch4 and ch5 ;never bevore I show these.

Regards Wolfgang

[Benj]

Hello,

If you go into the properties for your PWM channel 4 and 5 then you will see the the use alternate pin setting is ticked. Untick this setting and the components should compile correctly.

[echase]

Clearing the LVP cures it thanks. Only problem is that CLKOUT frequency is only 250KHz measured on 'scope when it should be Internal Oscillator/4 = 4MHz, or 16MHz if PLL is in the CLKOUT circuit, but I assume it is not.

What is going on there? Maybe oscillator is not really 16MHz as intended, plus 4x PLL but the default 1MHz. Programme does seem very slow.

C Code says

//Functions
#define MX_CLK_SPEED 64000000
#ifdef _BOOSTC
#include <system.h>
#endif
#ifdef HI_TECH_C
#include <pic18.h>
#endif

Buried deep in my memory is the thought that the user still has to enter C Code to set the oscillator frequency using OSCCON despite the #define MX_CLK_SPEED 64000000 line. Is that right?

[echase]

Setting OSCON gets the frequency right for 16Mhz and below. But there are still a number of clock problems.

1. If I increase the clock speed above 16MHz using the PLL the LCD will not display characters at all even if I delete all other code and just have a print Hello command and a delay loop. It’s not just due to using the PLL as it displays OK at 4MHz internal clock times 4 for PLL.

2. When the PLL is inserted it alters the delay timings. A delay icon will run about 4 times too slowly e.g. 20 secs instead of 5.

I have tried unsuccessfully to correct to it by:

1. Using external crystal instead of internal RC

2. Entering in Project Options the frequency before the PLL rather than after it.

3. Turning CLKOUT on and off.

Don’t get the impression that Flowcode is correctly setting the PLL and /or not accounting for it’s presence when used. Is there a C Code workaround?

[medelec35]

Hi echase,
Looking at the data sheet, if there is no C code for setting osccon then Default speed for internal osc will be 1MHz and it does not look like 1MHz can be used in conjunction with PLL

Since you want 64MHz then osccon should be set so internal osc is running at 16MHz. To do this osccon = 0x78;
Then PLL is enabled so final frequency = 16MHz x 4 = 64MHz

Clock speed in the General options is set at 64000000Hz

At this speed it has reported that LCD can sometimes stop working properly so best to be aware of that.
See:
http://www.matrixmultimedia.com/mmforum ... 58&p=32636

I have attached a flowchart to try. It just flashes an LED connected to A0 at 1HZ

Since I have not got a 18F14K22 to try, I can't guarantee I have got it right, But if it was me:
1st step would be to check that LCD is working at a lower speed e.g internal osc at 16MHz, So just have osccon=0x78; and disable PLL and set Clock speed in the General options tot 8000000Hz

If all is well then 2nd step: Change Clock speed to 64000000Hz and and enable PPLL. Check if LED is flashing at the correct rate.

Finally check LCD works.

Martin

[echase]

I added a LED as well as LCD as you suggest. Now

1) At 4Mhz (set wth OSCCON) x4 for PLL(set wth PPP) = 16MHz: LCD works even if I slow down the delays as in http://www.matrixmultimedia.com/mmforum ... 58&p=32636 . CLKOUT is 1MHz. But LED flash rate is 4 times too slow.

2) At 8Mhz x 4 for PLL = 32MHz: LCD does not work even if I slow down the delays as far as 20. CLKOUT is 8MHz. But LED flash rate is correct.

3) At 16Mhz x 4 for PLL = 64MHz: LCD does not work even if I slow down the delays. CLKOUT is 16MHz. But LED flash rate is correct.

4) At 16Mhz, no PLL = 16MHz: LCD works even if I slow down the delays. CLKOUT is 4MHz. LED flash rate is OK.

So aside from the LCD problem something really weird is going on here. In 1) all is well apart from LED rate. In 2) and 3) CLKOUT is 4 times too high as if it has derived the CLKOUT post PLL even though not done in 1). In 4) everything is OK.

I am using 2 oscilloscopes to check flash rate and CLKOUT so am confident my measurements are correct.

[medelec35]

Re 1)
Odd that LCD worked since clockout is = osc/4 it appears that PLL was not increasing fosc to 16MHz. That would also explain why LED was flashing at the wrong rate.
If it did then clockout would have been 4MHz.
Maybe LCD is more tolerant at the lower frequencies?

All other tests show PLL is increasing fosc to correct frequency.

I have not got 18F14K22 otherwise I would use matrix USB Test pot to compare the waveform out of the port connected to LCD with Fosc at 16 and 64MHz as there does seem to be a timing issue as stated in a different thread.

[echase]

Re 1)
Odd that LCD worked since clockout is = osc/4 it appears that PLL was not increasing fosc to 16MHz.

My understanding is that CLKOUT comes from before the PLL thus 1MHz is correct for 1).

[medelec35]

My understanding is that CLKOUT comes from before the PLL thus 1MHz is correct for 1).

Ahh Yes, I do agree with that.
sorry my mistake.

Martin

[kersing]

My understanding is that CLKOUT comes from before the PLL thus 1MHz is correct for 1).

Looking at the data sheet (2.6) I do understand where you are coming from. However, it does not explicitly state this. And looking at figure 3-3 it seems to be the clock divided by 4.

Have you noticed the PLL is only available for the internal 8/16 MHz frequencies (table 2-4 and figure 2-1)? I think that would explain what you are seeing in 1).

Best regards,

Jac

[echase]

Have you noticed the PLL is only available for the internal 8/16 MHz frequencies (table 2-4 and figure 2-1)? I think that would explain what you are seeing in 1).

Best regards,

Jac

Thanks, I see you are right. I had been confused by “If using a low-frequency external oscillator and want to multiple it by 4 via PLL, the ideal input frequency is from 4 MHz to 16 MHz.” from datasheet but now see it’s only true for eternal clocks.

However it does not solve my real problem as I’d only been running 1) and 4) as test cases. It is 64MHz that I really want.

If I now assume that CLKOUT really does come from after the PLL it would explain all the anomalies, leaving me with just one problem – how do I get the darn LCD to work at >16Mhz as the workaround Ben gives in viewtopic.php?f=29&t=10258&p=32636 does to work for me.

[medelec35]

I have ordered a couple of 18F14K22 (should be here tomorrow) as I like the idea of running and internal oscillator at a whopping 64MHz
So hopefully a fix can be found.

I admit I'm no where near up to Ben's standards as he is the master of components.
I will use the test pod and compare timings of LCD on 16 and 64MHz as I would also like to see this one solved if possible?

My guess is with internal osc at 64MHz either a small tolerance in the osc is having a wider timing issue than it would if osc is at 16MHz
Or the number off loops required is so high there is rollover causing a much shorter delay.
I could be wildly out of course.

I wonder if there is any issue with GLCD?
At 64MHz if they do work then refreshing display should be nice a fast.
I will check that out also.

Not enough minutes in day

[kersing]

Looking at the LCD component code I noticed there are two types of delays used. The %a_DELAY mentioned in the other thread, but also Wdt_Delay_Ms. This last delay is used a lot in the display functions like Start and Clear. Could it be the timing is off for these delays, resulting in the display not being initialized correctly? (It is based on the BoostC delay_ms function that [according to the BoostC documentation] gets generated every time a project is linked based on the defined clock speed)

(Martin, I can not imagine your days are only minutes short. Mine could usually benefit from a couple of additional hours )

[medelec35]

(Martin, I can not imagine your days are only minutes short. Mine could usually benefit from a couple of additional hours )

You notice I did not say how many minutes
Looks like we are both going down the same road of delay issue.
I agree with you about the display not initialized correctly.
Determined to find out tomorrow.

[echase]

I wonder if there is any issue with GLCD?
At 64MHz if they do work then refreshing display should be nice a fast.
I will check that out also.
:

Based on previous input from Ben I believe the LCD has to be written to quite slowly to work. That is probably true for GLCD as well as my text LCD.

So there is limited room for speed it up. See http://www.matrixmultimedia.com/mmforum ... 46&t=10706 where I hoped to get the LCD to work despite frequent interrupts during write/clear commands.

[Benj]

Hello,

The alphanumeric style LCDs are generally quite slow devices because they don't really have that much to do. The gLCDs can display animations etc so they are usually fairly high speed devices. The limitation here is usually how fast the micro can waggle it's pins to clock out the pixel data.

[echase]

I wonder if one possible fix may be to change the OSCON to slower speed just before the LCD write and back up again at end. But:

1) Will the clock speed seamlessly change?
2) All the delays and other maybe vital timing info in the LCD code will be too slow as presumably can’t also reissue the line #define MX_CLK_SPEED 64000000 to a new speed.
3) Can’t get any slower than reducing 64 to 32 MHz due to 4MHz x 4 for PLL being illegal.(I assume can’t turn the PLL off instead of changing OSCON). That illegal combination does cause the PLL to turn off, as I found above, but no sure whether it would behave the same for an on the fly change.
4) It messes up my interrupt as it changes its speed.

So not recommended solution but might try it temporarily till you guys work out how to change the LCD component to make it work at 64MHz. Still hoping!

Are there likely to be any other components in Flowcode that effectively are inoperable as is at these high clock speeds? Far as I can tell my full code as ported from 16F690 is working roughly OK but until I can get the LCD to work I can’t be sure.

[Benj]

Hello,

For the LCD can you customise the component code to force it to work at 64MHz.

Select the LCD component on the panel, right click and select custom code.

Next select the Defines function and click edit.

Find the following section of code.

Code: Select all

	#ifdef _BOOSTC
	  #define %a_DELAY   delay_10us(10)
	#endif

And try changing the length of the delay.

Code: Select all

	#ifdef _BOOSTC
	  #define %a_DELAY   delay_10us(20)
	#endif

This should hopefully be enough to get the display working.

Let me know how you get on.