View previous topic :: View next topic |
Author |
Message |
Cogitum
Joined: 22 Mar 2012 Posts: 70 Location: France (Paris)
|
CCS version prob between CCS 4.132 and 5.064 TIMER1 18f66K22 |
Posted: Thu Dec 29, 2016 5:03 am |
|
|
Hello,
I used a program realized with version CCS 4.132 which always works on more than 100 devices.
Today I use the CCS version 5.064.
This same program is compiled (with V 5.064) but no longer works (it only works once).
In this program, I use 2 Crystals, XTAL 20 MHz and 32 KHz and always the same PIC 16F66K22.
No worries of simplification, I realized a test program.
I still see the same problem:
It works with CCS 4.132 but does not work with CCS 5.064 !!!
Note: CCS 4.132 is on a laptop.
CCS 5.064 is on another laptop.
The scope allows me to see the operation of the quartz 32 KHz and 20 MHz (CCS 4.132).
The scope allows me to see the operation of quartz 20 MHz (CCS 5.064) 32 KHz does not work.
Connected to one hyper, I can read the message and see the LED blinking on PIN_G0.
I would like see crystal 32 KHz working .....with CCS 5.064 ?
Code: |
#include <18F66K22.h>
#device adc=12
#FUSES NOWDT //No Watch Dog Timer
//#FUSES VREGSLEEP_SW // Ultra Low POWER regulator enable
#FUSES INTRC_HP // Low POWER mode during Sleep
#FUSES NOXINST // Extended set extension and Indexed Addressing mode disabled (Legacy mode)
#FUSES HSH //M // High speed Osc, medium power 4MHz-16MHz
#FUSES NOBROWNOUT // No brownout reset
#FUSES NOPLLEN //4X HW PLL disabled, 4X PLL enabled in software
#FUSES WDT_NOSLEEP //Watch Dog Timer, disabled during SLEEP
//#FUSES VREGSLEEP_SW //Ultra low-power regulator is enabled
#use delay(clock=20000000)
#use rs232(UART1,stream =gps,baud=9600, xmit=PIN_C6,rcv=PIN_C7)
#define LED_PIN PIN_G0
void main()
{
///////////////////////////////////////////////
// Timer 1
///////////////////////////////////////////////
//setup_oscillator(OSC_31KHZ|OSC_SOSC_ON|OSC_NORMAL );
//setup_timer_1(T1_EXTERNAL|T1_DIV_BY_8|0x8); //
//setup_oscillator( OSC_SOSC | OSC_MFINTRC_ON | OSC_IDLE_MODE );
//bit_set( *0xF64, 3 );
//!set_timer1(T1_FOSC);
setup_timer_1(T1_external|T1_ENABLE_SOSC);// OK >> 32 KHz displayed on the SCOPE !!! CCS Ver 4.132 NO with CCS 5.064
////////////////////////////////////
// interruptions //
///////////////////////////////////
//enable_interrupts(INT_TIMER0); // Timer 0 de clock
//disable_interrupts(INT_TIMER1); // Timer 1 de sleep
//enable_interrupts(INT_TIMER1);
//enable_interrupts(INT_RDA); // Interruption UART1 GPS
// enable_interrupts(global);
While(TRUE)
{
output_toggle(LED_PIN);// OK
fprintf(GPS,"CCS 5.064\n\r");// OK
delay_ms(500);
}
} |
|
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19368
|
|
Posted: Thu Dec 29, 2016 5:26 am |
|
|
You are not enabling the secondary oscillator in the fuses. It has to be.
With V4 compilers, CCS set some of the fuses to values they 'thought' were sensible.
With V5, they instead leave all unspecified fuses at their default settings.
The latter is better, since especially on the more complex chips it means you won't accidentally get unexpected settings, but it means you have to make sure all fuses are set how you want them. SOSC_LOW to enable it for a low power oscillator. |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9174 Location: Greensville,Ontario
|
|
Posted: Thu Dec 29, 2016 5:46 am |
|
|
As MR T says CCS sets the fuses to their idea of proper 'configuration' that's why when I went to the 46K22 I now have ALL the fuses listed one by one in a separate file that I 'include'. I have a 'base' fuses file that I use with the 1Hz LED program to confirm 'stuff works', then for specific projects, they get their own 'custom' fuse file depending on what fuses need to be set or cleared. One benefit of using the 'fusefile' method is that main is a LOT easier to read as 30-40 lines are not needed, just the one include fusefile.
The other benefit is in NO typo errors in the fuses section of code. That sure help when you 'know' it worked before and after an hour you finally see that a fuse is wrong......
Jay |
|
![](templates/subSilver/images/spacer.gif) |
Cogitum
Joined: 22 Mar 2012 Posts: 70 Location: France (Paris)
|
CCS 4.132 and 5.064 |
Posted: Thu Dec 29, 2016 6:38 am |
|
|
Thanks a lot Guy for your reactivity !!
With the fuse for #FUSES SOSC_HIGH the program it's running.
Have a good day
and HAPPY new Year 2017 to you !!
Cogitum |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19368
|
|
Posted: Thu Dec 29, 2016 8:53 am |
|
|
Yes. I much prefer the current approach, since the fuses are set by default to "all 1's", which is what they hold when erased, but it does occasionally bring troubles when older code did not explicitly set fuses. |
|
![](templates/subSilver/images/spacer.gif) |
|