DelayMS stuck my program at specific XTAL value

[Mates]

Hi, I have 16F1459 @48Mhz (internal OSC at 16Mhz, PLLx3)
Program works fine, but stuck at DelayMS & DelayUS when XTAL is declared to 48Mhz.
When I set XTAL to 16Mhz(or 32Mhz) program runs without problem, but 3x faster (obviously).

When DelayMS is replaced by:
For cnt = 0 to 20000
   Asm
      Nop
   EndAsm
Next

Then the LED is flashing...


Am I missing something?

Code Select Expand

device 16f1459
declare xtal 48

'-------------------------------------------------------------------------------
'**** Added by Fuse Configurator ****
' Use the Fuses Tab to change these settings

Config1 FOSC_INTOSC, WDTE_OFF, PWRTE_ON, MCLRE_OFF, CP_OFF, BOREN_OFF, CLKOUTEN_OFF, IESO_OFF, FCMEN_OFF
Config2 WRT_OFF, CPUDIV_NOCLKDIV, USBLSCLK_48MHz, PLLMULT_3x, PLLEN_ENABLED, STVREN_OFF, BORV_LO, LPBOR_OFF, LVP_ON

'**** End of Fuse Configurator Settings ****
'-------------------------------------------------------------------------------
              '76543210
TRISA       = %00000000
TRISB       = %00000000
TRISC       = %00000000
OSCCON      = %11111100 ' Config oscillator to 48Mhz (PLL enabled, PLLx3, 16Mhz, Clock determined by FOSC)

MainLoop:
    toggle portc.5
    Delayms 1000
goto MainLoop


[trastikata]

I'm not sure I understand the problem correctly.

Declare Xtal serves for proper timing calculation but the actual timing depends on your code settings.

CPUDIV is set to 1, so regardless what you declare as Xtal, the actual clock will be 48MHz.

So if the actual clock is 48MHz, but your declare is 16MHz, the compiler will calculate delays for 16MHz and they will run, of course, 3 time faster.

[Mates]

I know. CPU is always running at 48Mhz with this confing, but if XTAL value is 48, then program is not working (due to DelayMS). I set XTAL=16 just for testing purposes to figure out what's wrong. It's wierd, but i think that there is something wrong with the commands like DelayMS/US, SerOut, etc.. Commands where delays is recalculated by compiler for each Freq. Never seen this issue. CPU is running at 48Mhz (checked with oscilloscope), but when XTAL is declared 48 those commands stuck program. Same program and same config with another XTAL value work, but with incorrect delays. When DelayMS is replaced by assembler NOPs then work like charm.

[rick.curl]

What happens if you change OSCCON to %11111110? From the OSCCON section of the spec sheet:
bit 1-0 SCS<1:0>: System Clock Select bits
1x = Internal oscillator block
01 = Secondary oscillator
00 = Clock determined by FOSC<2:0> in Configuration Words.

Changing bits 1-0 to 10 would cause it to ignore the oscillator setting in the config word and use OSCCON only.

-Rick

[Mates]

Hi Rick! Just checked. CPU freq will not be multiplied by PLL. With this OSCCON is CPU running at 16Mhz. Same thing anyway.. XTAL=16 works fine with 1 sec. delays. With XTAL=48 it should be 3 sec, but it stuck. Wierd wierd wierd

[Stephen Moss]

It seems there may have been an issue which could have been causing this as the post for the latest update (version 4.0.3.8-1.1.1.6) states...
"Corrected Xtal values 48 (MHz) and 64 (MHz) when running an enhanced 14-bit core device over spec. It was previously locking the program because of the Subwfb mnemonic not operating the same as an 18F device."

[top204]

The enhanced 14-bit core devices have a maximum of 32MHz operating spec, but they share some mnemonics with 18F devices, so I used three of the 18F DelayUs subroutines to give the enhanced 14-bit core devices a chance to be overclocked (40MHz, 48MHz and 64MHz), but I made the assumption that the mnemonics were exactly the same, and I should have known better with microchip. :-) So I did not test the subroutines on an enhanced 14-bit core running past 32MHz because they worked perfectly on an 18F device. However, it appears, the Carry flag is not being manipulated the same with some mnemonics on enhanced 14-bit device that are shared with 18F devices, and the loop of the delay never finished because it was looking for a Carry flag change. So I've created three new library subroutines for microsecond delays when the device is operating past its 32MHz (official) threshold in the compiler update of version 4.0.3.8.

Note. The DelayMs command uses the DelayUs library subroutine as well, so they both locked when the enhanced 14-bit core device was operating past its, official, 32MHz threshold.