PCD C Compiler v5.093 - Use invalid cpu clock & fuses?

[ArthurDavidov]

Hi all,
I am using pic24ep512gp806, CCS PCD C Compiler, Version 5.093.

1.
What is happening in case I set #use delay() with invalid value CPU clock (according to datasheet)?

#use delay(oscillator=25M, clock=130M)
Is this definition is safe and can handle with an invalid CPU value?


2.
What is happening in case I use with not supported by PIC24 #fuse?
Can it harm something or just ignored?


The compilation on both case is successful.

Thanks.

[Ttelmah]

Depends what the fuse is. It may be ignored, or it may result in setups
the chip cannot perform. It is possible to set the fuses in some cases to
values the data sheet marks as 'not supported'. What will happen here
is completely undocumented.
The clock may work. Chips can often go past their rated speeds, but will
possibly be unreliable and may well result in overheating.
At the end of the day, it is up to you to set these values correctly.
This is why we often suggest building your own set of default 'known good'
settings for a particular chip that you then use.

[temtronic]

I'd have to check but I 'thought' the top clock for a PIC24 was 120MHz, even then you have to be SURE the PIC doesn't overheat ( <85*C ?? )

In any event you should NOT 'overclock' a PIC. While the one you're testing might be 'fine', there's NO way it'll perform 100% in the 'real world'.

I don't know if the compiler is supersmart and NOT allow clocks over design specs, you'll have to code, compile and look at the HEX file to see.

[Ttelmah]

That is the point. He is asking what will happen if he specifies an overclocked
setting....

[temtronic]

If the compiler allows and sets it to 'overclock', it might run ok, until it overheats and either stops working or dies.....
Normally you have to super cool a CPU to get it to run reilably BUT 'other stuff' can happen...... all DIO on I/O pins runs faster, could be 'out of spec' for whatever they're attached to.That may cause corrupt data or damage to the peripheral. Internals such as I2C,SPI, UART may be OK,providing they can be set for the correct speed.

[Ttelmah]

Generally, the compiler will allow an overclock to be selected, but if it goes
beyond the 'possible' clocks for things like the intermediate stages in the
PLL, this won;t be allowed.
Some overclocking may be 'reasonable'. Years ago, I had a PIC, that for
certain frequency 'reasons', needed to be clocked from a frequency that
was about 4% outside the maximum specified. I contacted Microchip,
and they stated that this was completely OK, provided we stayed inside
the 'I' temperature rating range. However the margins on chips like the
DsPIC's are very much lower than they were then....
The compiler also has to recognise that sometimes Microchip launch
later variants with a higher maximum rated frequency. This has happened
in the past with a couple of the PIC18's. So if the compiler blocks the
selection of an 'above specification' frequency, it then results in a new
compiler version being needed for a variant with the same type number.
Hence in general some overclocking is often allowed.
As Jay says, heat and peripheral performance are the big problems,
especially when you start to get up to frequencies like 100MHz+.....
You get silly things like the I2C, SPI, UART, ADC etc., giving issues,
when you push the frequencies.

[ArthurDavidov]

Thanks for your response and time.

1.
The question about the invalid CPU clock is not only above MAX, it can be also lower than MAX but doesn't meet the limits and constraints in the PLL diagram (from datasheet).

For example, 49Mhz doesn't fit due to PLL questions but 50Mhz is matching all limits in diagram. How does the CCS compiler react in this case? How he calculate the prescalers? Is he round? ceil?
The compilation is successful without warnings.


2. about the fuses in case I declare:
#fuses NOJTAG, NOWDT, NOIOL1WAY, NOWRT, NOPROTECT

But supported fuses according to my '24ep512GP806.h' are:
JTAG, WDT, IOL1WAY, WRT, PROTECT

So in this case, declared fuses will be just ignored? Or can lead to something unstable?

Thanks a lot for your responses.

[PCM programmer]

[Ttelmah]

Understand that 'NOJTAG', simply means 'Turn off the JTAG fuse'. It is not
a new fuse.....

[ArthurDavidov]

Ttelmah
Thanks, I know the meaning, so I can use with this even if not appear in the list of supported fusses from <24ep512GP806.h>:

#nolist
//////// Program memory: 175104x24 Data RAM: 53248 Stack: 31
//////// I/O: 53 Analog Pins: 24
//////// Fuses: WRT,PROTECT,NOGSSK,GSSK,FRC,FRC_PLL,PR,PR_PLL,SOSC,LPRC
//////// Fuses: FRC_DIV_BY_16,FRC_PS,IESO,EC,XT,HS,NOPR,OSCIO,IOL1WAY,CKSFSM
//////// Fuses: CKSNOFSM,NOCKSNOFSM,WPOSTS1,WPOSTS2,WPOSTS3,WPOSTS4,WPOSTS5
//////// Fuses: WPOSTS6,WPOSTS7,WPOSTS8,WPOSTS9,WPOSTS10,WPOSTS11,WPOSTS12
//////// Fuses: WPOSTS13,WPOSTS14,WPOSTS15,WPOSTS16,WPRES32,WPRES128,PLLWAIT
//////// Fuses: WINDIS,WDT,NOPUT,PUT2,PUT4,PUT8,PUT16,PUT32,PUT64,PUT128
//////// Fuses: BROWNOUT,ALTI2C1,ICSP3,ICSP2,ICSP1,RESET_AUX,RESET_PRIMARY
//////// Fuses: JTAG,DEBUG,AWRT,APROTECT,NOAPLK,APLK
////////


What about using invalid values of CPU clock (doesn't meet the PLL requirements due to datasheet calculations)?

[Ttelmah]

Yes. The list is only done for convenience. Unfortunately things are
sometimes missed. The place to actually look is the device editor (assuming
you have the IDE), and in the top right of the window there is a list of
the fuses, with [NO]JTAG shown. For the 'JTAG' fuse with a supported
'NO' option.
I've moaned before to CCS, that they really ought to create a program that
builds the list from the device database, so that the two can't differ, but
it looks as if they are still 'hand creating' this....
The .LST file from a compile is also much more informative:

[ArthurDavidov]

Thanks for the very informative explanation.

Could you also help with CPU clock issue?
Can I see the disassembly of #use delay() to detect the prescalers values?

[Ttelmah]

Yes.

Open the device include file.
Rem out the line #nolist, so it becomes
//#nolist
Edit it in the IDE, and when you go to save it, tell the compiler to save it
as a copy with your project.
Then in your project, change the line:

#include <Processor.h>

to:

#include "Processor.h"

Where 'Processor' is the processor number you are using. Using the inverted
commas makes the compiler load the version with your project instead of
the 'master' copy.

Then re-compile.

You will find at the start of the main all the compiler code for this is now
shown. It'll be a section like:

[ArthurDavidov]

Thank you for your guide. I did it and the difference is only in line 268:

.................... #use delay(oscillator=25M, clock=100M)
*
00262: CP0 W0
00264: BTSC.B 42.1
00266: BRA 27C
00268: REPEAT #34B
0026A: NOP
0026C: REPEAT #3FFE
0026E: NOP
00270: REPEAT #3FFE
00272: NOP
00274: REPEAT #3FFE
00276: NOP
00278: DEC W0,W0
0027A: BRA NZ,268
0027C: RETURN

I tried with invalid CPU clock (according to PLL diagram):
.................... #use delay(oscillator=25M, clock=130M)
*
00262: CP0 W0
00264: BTSC.B 42.1
00266: BRA 27C
00268: REPEAT #3DE3
0026A: NOP
0026C: REPEAT #3FFE
0026E: NOP
00270: REPEAT #3FFE
00272: NOP
00274: REPEAT #3FFE
00276: NOP
00278: DEC W0,W0
0027A: BRA NZ,268
0027C: RETURN

Is there any way to find the PLL prescaler, PLL postscaler, PLL divisor to understand the result of using with invalid CPU CLock?

[Ttelmah]

What you are posting is not the clock setup. That is a delay, which changes
because the clock rate changes. The code for delays is before the clock
settings. The clock setup code is at the start of the main.