CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

Moving from PIC16F1517 to PIC16F15275 - Oscillator Settings

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
dmilrtime



Joined: 17 Mar 2022
Posts: 6

View user's profile Send private message

Moving from PIC16F1517 to PIC16F15275 - Oscillator Settings
PostPosted: Thu Mar 31, 2022 4:46 pm     Reply with quote

Hello All,

I have some older code that has been in production and not touched since 2015ish. We have been using the PIC16F1517 for a years and now with supply chain issues that everyone is facing we need to port the project to a newer PIC.

The PIC16F15275 is a newer PIC that is pin compatible with the 1517 and for the most part register compatible. Where I am having an issue is with the #fuse directives.

The legacy 1517 project has the following:
#fuses INTRC_IO,NOWDT,NOPROTECT,MCLR,BROWNOUT,PUT, BORV25, PROTECT

The 15275 does not support PUT, BORV25 but I found the equivalents for them. My specific issue is around the INTRC_IO vs the various OSC Fuse flags for the 15275

Our original code uses the INTRC_IO flag and configured for the Internal RC OSC to be 16MHz. I am trying to figure out which of the fuse flags for the 15275 would configure the Internal OSC for 16MHz. I have tried
#fuses RSTOSC_HFINTRC_32MHZ,NOWDT,NOPROTECT,MCLR,BROWNOUT,PUT_64MS, BORV28, PROTECT

Then I have also tried:
setup_oscillator(OSC_HFINTRC_16MHZ | OSC_HFINTRC_ENABLED);

None of these or any combo of these have set the OSC to 16MHz. I know because some of the other code that is relying the 16MHz clock.

Anyone have any experience with setting the Internal OSC for the 15275? Any tips that might help me out?

Thanks
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Thu Mar 31, 2022 5:53 pm     Reply with quote

Try this:
Code:
#include <16F15275.h>
#use delay(internal=16M)

//====================================
void main()
{

while(TRUE);
}
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Fri Apr 01, 2022 1:37 am     Reply with quote

As another comment, get rid of the PROTECT fuse, until you have finished
the development and have the chip working.
PROTECT should only ever be set on the final 'running' version.
If you enable it during development, it significantly reduces the life of
the chip. With this disabled, the programmer can block erase only the
parts that need to change in the memory. With this set, the programmer
has to do a full bulk erase of the whole chip for every single change you try.
Currently you have both PROTECT and NOPROTECT selected. Don't know
which will actually be applied to the chip!....
Code:

#include <16F15275.h>
#fuses NOWDT,MCLR,BROWNOUT,PUT_64MS, BORV28,NOPROTECT
#use delay(internal=16M)


Remember also you can 'see' what is actually done by simply looking at
the fuses in the .lst generated by an attempt, rather than having to actually
waste an erase cycle each time.

In fact the reason you have problems is the way this chip's oscillator
is done. There is no fuse option to actually directly select 16MHz. Instead
the HFINTOSC is setup to run at 1MHz, and then the chip is told to run
at 16MHz with the OSCFRQ bits.
Table 11-1 in the sheet. The above compiler setting correctly sets all
these.
At the start of the main:
Code:

0014:  MOVLB  11
0015:  CLRF   OSCTUNE
0016:  CLRF   OSCEN
0017:  MOVLW  04
0018:  MOVWF  OSCFRQ //100 to OSCFRQ
0019:  MOVLB  3E
001A:  CLRF   38
001B:  CLRF   43
001C:  CLRF   4E
001D:  CLRF   59
001E:  CLRF   64
temtronic



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Fri Apr 01, 2022 5:42 am     Reply with quote

re:
Quote:
Currently you have both PROTECT and NOPROTECT selected. Don't know
which will actually be applied to the chip!....


#fuses INTRC_IO,NOWDT,NOPROTECT,MCLR,BROWNOUT,PUT, BORV25, PROTECT

My 'gut' thinks the last option would be the final one.
The compiler's 'parser' should decode the line from left to right

so. first it configures for 'noprotect' then later for 'protect'

well that's my guess...

Jay
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Fri Apr 01, 2022 7:48 am     Reply with quote

Just look at the end of the .LST file to see which one prevails.
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Fri Apr 01, 2022 11:40 am     Reply with quote

Why bother?.
The point is that he should not be using protect while experimenting.
Better to just put the NOPROTECT as the last value, and just change this to
PROTECT on the final version....
I didn't bother to check, since 'better to sort it out'.... Smile
dyeatman



Joined: 06 Sep 2003
Posts: 1910
Location: Norman, OK

View user's profile Send private message

PostPosted: Fri Apr 01, 2022 12:21 pm     Reply with quote

Why use either one? Isn't NOPROTECT the default?
If developing something for the "MARKET" can I see it, but
certainly not during development. I would avoid them totally till final.
_________________
Google and Forum Search are some of your best tools!!!!
temtronic



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Fri Apr 01, 2022 12:35 pm     Reply with quote

I can't recall ever using PROTECT, though in the good old days, alarm panel mfrs would sand the numbers off the DIPs, GM had DELCO numbers and Heathkit had their part numbers.

You could read a PIC16C84 even if 'protected'...then Microchip got fancy...sigh...

I miss the old days !
dmilrtime



Joined: 17 Mar 2022
Posts: 6

View user's profile Send private message

PostPosted: Fri Apr 01, 2022 4:11 pm     Reply with quote

Thanks for the info and the tip on the PROTECT fuse. I am used to blowing these fuses at Production programing time not when I compile and load the code. I didn't realize what that meant until now.

While I was working on the OSC issues my last piece that doesn't want to port very well is the Serial Port.
Code:

#use rs232(baud=115200, xmit=PIN_C6,rcv=PIN_C7, stream=PC)
setup_uart (115200);


When I compile the setup_uart() function gives a "Missing a comma" error. The include file has 3 possible options for the setup_uart() function
Code:

///////////////////////////////////////////////////////////////// UART
// UART Prototypes:
_bif void setup_uart(int32 baud);
_bif void setup_uart(int32 baud, int8 stream);
_bif void setup_uart(int32 baud, int8 stream, int32 clock);


I tried all three options:
setup_uart (115200, PC); - Missing comma error
setup_uart (115200, PC, 16000000); - Function used but not defined error

Any tips on what I am missing to get the Serial Port to work as expected?

Thanks again for the help. This should be a simple port but for some reason it's not so straight forward.


Ttelmah wrote:
As another comment, get rid of the PROTECT fuse, until you have finished
the development and have the chip working.
PROTECT should only ever be set on the final 'running' version.
If you enable it during development, it significantly reduces the life of
the chip. With this disabled, the programmer can block erase only the
parts that need to change in the memory. With this set, the programmer
has to do a full bulk erase of the whole chip for every single change you try.
Currently you have both PROTECT and NOPROTECT selected. Don't know
which will actually be applied to the chip!....
Code:

#include <16F15275.h>
#fuses NOWDT,MCLR,BROWNOUT,PUT_64MS, BORV28,NOPROTECT
#use delay(internal=16M)


Remember also you can 'see' what is actually done by simply looking at
the fuses in the .lst generated by an attempt, rather than having to actually
waste an erase cycle each time.

In fact the reason you have problems is the way this chip's oscillator
is done. There is no fuse option to actually directly select 16MHz. Instead
the HFINTOSC is setup to run at 1MHz, and then the chip is told to run
at 16MHz with the OSCFRQ bits.
Table 11-1 in the sheet. The above compiler setting correctly sets all
these.
At the start of the main:
Code:

0014:  MOVLB  11
0015:  CLRF   OSCTUNE
0016:  CLRF   OSCEN
0017:  MOVLW  04
0018:  MOVWF  OSCFRQ //100 to OSCFRQ
0019:  MOVLB  3E
001A:  CLRF   38
001B:  CLRF   43
001C:  CLRF   4E
001D:  CLRF   59
001E:  CLRF   64
[/code][/quote]
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Fri Apr 01, 2022 4:37 pm     Reply with quote

Quote:
#use rs232(baud=115200, xmit=PIN_C6,rcv=PIN_C7, stream=PC)
setup_uart (115200);

Are you really writing code like this ? I mean, putting a function
outside of main() or some other routine ? I mean hanging a function
out in space.
dmilrtime



Joined: 17 Mar 2022
Posts: 6

View user's profile Send private message

PostPosted: Fri Apr 01, 2022 4:40 pm     Reply with quote

PCM programmer wrote:
Quote:
#use rs232(baud=115200, xmit=PIN_C6,rcv=PIN_C7, stream=PC)
setup_uart (115200);

Are you really writing code like this ? I mean, putting a function
outside of main() or some other routine ? I mean hanging a function
out in space.


No, setup_uart() is inside of main. I just showed the two lines that are of issue.
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Sat Apr 02, 2022 1:13 am     Reply with quote

The problem is he is not setting up a UART. Hence the setup_uart command
won't work... Sad

Key is the new chip is a PPS chip. Setting up serial using pin names, sets up
a software serial, not a hardware UART.

He needs to setup the serial with:
Code:

#include <16F15275.h>
#fuses NOWDT,MCLR,BROWNOUT,PUT_64MS, BORV28,NOPROTECT
#use delay(internal=16M)
#PIN_SELECT U1TX=PIN_C6
#PIN_SELECT U1RX=PIN_C7
//This tells the compiler what pins to use for UART1
#use rs232(baud=115200, UART1, stream=PC)
//Now sets up UART1 for your serial

void main(void)
{
   setup_uart(115200,PC);
   //this is then happy
   while (TRUE)
   {
      output_toggle(PIN_A0);
      delay_us(500);
   }
}


The error message is confusing. Because there is no physical UART actually
being setup, the setup_uart command gets confused. The error really should
be something like 'no UART enabled to setup'.

On some chips there is a default pin for both RX and TX, and on these
if these pins are used, the latest compilers will automatically use a
UART. However on this one (and a lot of the newer chips), the 'default'
POR value for the TX pin is an undefined pin. Hence the compiler cannot
assume a hardware UART is what is wanted.
In general with PPS chips always use PIN_SELECT before trying to setup
the device.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group