| View previous topic :: View next topic |
| Author |
Message |
starfire151
Joined: 01 Apr 2007
Posts: 195
|
| operation of new PIC16F15325 chip? |
 Posted: Thu Mar 02, 2017 12:30 pm |
 |
|
First, the fundamentals:
PCWHD V5.070
Windows 10
I am trying to create a testbed with the new PIC16F15325 chip using two hardware serial ports and an I2C interface to a 24LC16 EEPROM. This is a very nice chip because it has two hardware com ports (#INT_RDA and #INT_RDA2) which can operate reliably at higher rates, such as 38400, and the chip is in a small 14-pin DIP or SOIC format. Unfortunately the part does not have any internal EEPROM so I need to provide a small 2Kx8 EEPROM with a 24LC16 connected with the hardware I2C port.
I used a template program I had created for the PIC16LF1825 and made some modifications. In the template program, I use timer_0 as a heartbeat timer. I used the following setup command:
setup_timer_0(RTCC_INTERNAL | RTCC_DIV_256 | RTCC_8_BIT);
My oscillator is running at 16MHz so the timer setup value would be
16000000 / (4 / 256 / 256) or roughly 61. After enabling the TIMER_0 interrupt, this causes an interrupt every 1/61 second. I merely increment a counter in the #INT_TIMER0 routine to count 61 times and then toggle a heartbeat LED and increment a seconds counter. This works perfectly on the PIC16LF1825.
... but... when I used this same code on the PIC16F15325, it didn't operate correctly. I found out (through a LOT of trial and error) that to get the heartbeat to toggle every second, I had to use the following timer 0 setup:
setup_timer_0(RTCC_INTERNAL | RTCC_DIV_64 | RTCC_8_BIT);
This caused the #INT_TIMER0 interrupt to run every second. I didn't need to count 61 cycles anymore. It works but I don't know why...
I'm sure I missed something but I didn't see anything in the datasheet that jumped out at me. Has anyone else worked with this chip?
I also had to do a few gymnastics to get the I2C interface to work...
Thanks for any help or insight. |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Thu Mar 02, 2017 9:41 pm |
|
|
| Quote: |
setup_timer_0(RTCC_INTERNAL | RTCC_DIV_64 | RTCC_8_BIT);
This caused the #INT_TIMER0 interrupt to run every second. I didn't need
to count 61 cycles anymore. It works but I don't know why...
|
It's because the #define statement for RTCC_8_BIT is incorrect in the
16F15325.h file. It's putting Timer0 into 16-bit mode, not 8 bit.
This causes the equation to actually have a "divide by 65536" in it.
This gives:
16M / (4 * 64 * 65536) = 0.95 Hz
That's your 1 Hz interrupt rate.
If you want to fix the bug in the .h file, you can add the #undef and
#define lines above main() as shown below.
| Code: | #include<16F15325.h>
#fuses NOWDT
#use delay(internal=16M)
#undef RTCC_8_BIT
#define RTCC_8_BIT 0
//=========================================
void main()
{
setup_timer_0(RTCC_INTERNAL | RTCC_DIV_256 | RTCC_8_BIT);
while(TRUE);
}
|
CCS support should be informed of this bug. This is in vs. 5.070. |
|
|
starfire151
Joined: 01 Apr 2007
Posts: 195
|
|
| Posted: Fri Mar 03, 2017 10:55 am |
|
|
Thanks very much for the response.
I've forwarded your response to CCS support as a potential bug fix for the next version. |
|
|
starfire151
Joined: 01 Apr 2007
Posts: 195
|
|
| Posted: Sat Mar 04, 2017 9:24 am |
|
|
As a follow-up, I heard back from CCS Tech Support. Their response is as follows:
---------------
Use the defines starting with T0_ instead of the defines starting with RTCC_, for example:
setup_timer_0(T0_INTERNAL | T0_DIV_64 | T0_8_BIT);
For this device's family the defines that start with RTCC_ are only provided for backwards compatibility to be used with the setup_counters() function. If you use them in that function, Timer 0 will be setup correctly.
---------------
I went back to my program and changed the setup as described above. With a 16M oscillator, I used
setup_timer_0(T0_INTERNAL | T0_DIV_256 | T0_8_BIT)
My #INT_TIMER0 routine now counts 61 times before getting one second elapsed, similar to other PIC16 chips I've used. |
|
|
starfire151
Joined: 01 Apr 2007
Posts: 195
|
| new pic16f15325 circuit failure to start |
| Posted: Wed Sep 30, 2020 12:46 pm |
|
|
I'm trying to construct a new circuit with the PIC16F15325 chip. I'm having start-up issues.
I'm using PCWHD V5.071 on Windows 10
My simple program follows:
| Code: |
#include <16F15325.h>
#FUSES NOWDT // No Watch Dog Timer
#use delay(internal=16M)
void main(void)
{
set_tris_a(0b11001111);
set_tris_c(0b11101011);
output_a(0b11001111);
output_c(0b11111111);
setup_timer_0(T0_INTERNAL | T0_DIV_256 | T0_8_BIT); // 1/61 sec timer
setup_timer_1(T1_DISABLED);
setup_timer_2(T2_DISABLED, 0, 1);
while(TRUE) // wait for interrupts
{
output_high(PIN_A4);
delay_ms(500);
output_low(PIN_A4);
delay_ms(500);
}
}
|
I have the cathode of an LED connected to pin A4 (pin 3 of the chip). I have a series 1.5K resistor connected to the anode of the LED and then to +3.3VDC (the system voltage).
I see no activity from the PIC at all. I tried all the suggestions from previous posts on this thread but nothing's working. I tried multiple PIC chips. I've verified system connections and power. I even tried with a +5.0VDC supply. Everything fails. It's as though the chip is not starting at all.
Does anyone have any ideas or simple example I could try?
Thanks. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9225
Location: Greensville,Ontario
|
|
| Posted: Wed Sep 30, 2020 3:10 pm |
|
|
Does the LED actually light if you ground the cathode instead of connected to PIC ?
Some rough math here..
assume 1.65v for LED, red LED.
3.3-1.65 = 1.65v
1.65v / 1500 = 1ma
That's not a lot of current for an LED...
Jay |
|
|
starfire151
Joined: 01 Apr 2007
Posts: 195
|
|
| Posted: Wed Sep 30, 2020 3:16 pm |
|
|
| Yes. The LED lights up when the cathode is grounded. I'm using high efficiency LEDs, which light up with very low currents, typically 1mA or less. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9225
Location: Greensville,Ontario
|
|
| Posted: Wed Sep 30, 2020 3:29 pm |
|
|
Neat ! LEDS on with <1ma !!
OK
I'd
1) get rid of the set-tris() lines, let the compiler handle that....
2) get rid of the setup_timer() lines, yeah, I know, you know they work but..
3) disable any/all peripherals that could use PIN_A4. This could be analog inputs, comparators,etc. Sadly 'defaults' aren't 'digital I/O'....
4) if the PIC has PPS, you may have to do that first....
I'm thinking #3 is the culprit....
Jay |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Wed Sep 30, 2020 4:22 pm |
|
|
There are differences in the Config Bits in Word 1:
5.071
| Quote: | Configuration Fuses:
Word 1: 3F8C NOEXTOSC RSTOSC_HFINTRC NOCLKOUT CKS FCMEN
Word 2: 3FFD MCLR PUT NOLPBOR BROWNOUT BORV24 ZCDDIS PPS1WAY STVREN NODEBUG
Word 3: 3F9F WDTSW NOWDT WDTWIN_SW WDTCLK_SW
Word 4: 1FFF BBSIZ512 BOOTBLOCK NOSAF WRT NOWRTB NOWRTC NOWRTSAF NOLVP
Word 5: 3FFF NOPROTECT
|
5.095
| Quote: | Configuration Fuses:
Word 1: 3FEC NOEXTOSC RSTOSC_HFINTRC NOCLKOUT CKS FCMEN
Word 2: 3FFD MCLR PUT NOLPBOR BROWNOUT BORV24 ZCDDIS PPS1WAY STVREN NODEBUG
Word 3: 3F9F WDTSW NOWDT WDTWIN_SW WDTCLK_SW
Word 4: 1FFF BBSIZ512 NOBOOTBLOCK NOSAF NOWRT NOWRTB NOWRTC NOWRTSAF NOLVP
Word 5: 3FFF NOPROTECT |
Try it with the additional #fuses 1 line shown below. This will give it the
same Word 1 as with vs. 5.095
| Code: | #include <16F15325.h>
#FUSES NOWDT
#use delay(internal=16M)
#fuses 1=0x3FEC // *** Add this line ***
void main(void)
{ |
|
|
|
starfire151
Joined: 01 Apr 2007
Posts: 195
|
|
| Posted: Wed Sep 30, 2020 4:48 pm |
|
|
Follow-up... modified the program to the following:
| Code: |
#include <16F15325.h>
#FUSES NOWDT // No Watch Dog Timer
#FUSES NOEXTOSC // CRITICAL : allows pin 2 to be used for output
#use delay(internal=16M)
void main(void)
{
setup_adc(ADC_OFF);
setup_adc_ports(NO_ANALOGS);
setup_ccp1(CCP_OFF);
setup_vref(VREF_COMP_DAC_OFF);
setup_clc1(CLC_DISABLED);
output_a(0b11001111);
output_c(0b11111110);
while(TRUE) // wait for interrupts
{
output_high(PIN_C0);
delay_ms(500);
output_low(PIN_C0);
delay_ms(500);
}
}
|
It still does not work. I even changed the toggling output to C0, which was initially set to a 0 at power up. The pin is not going to 0. It's as if the program is not running at all. In looking at the output with a scope, it stays high.
By the way, Digikey part number 160-1665-ND is a T-1 LED which lights up brightly with 1.0 to 1.5mA current. A 1.5K series resistor with a 3.3VDC supply works well. Great for battery-operated applications... |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Wed Sep 30, 2020 10:14 pm |
|
|
The following program was compiled with vs. 5.071 and programmed into
a 16F15325 on the Microchip Low Pin Count board. It works. The LED
on pin C0 blinks at a 1 Hz rate. I'm running the board at 5v.
The LED is wired differently than on your board. It's got the cathode
going to ground, so a high level on pin C0 will turn it on. But that
shouldn't matter. Your board should still blink the LED.
Do you have a 10K pullup on the MCLR resistor ?
| Code: |
#include <16F15325.h>
#use delay(internal=16M)
void main(void)
{
while(TRUE)
{
output_high(PIN_C0);
delay_ms(500);
output_low(PIN_C0);
delay_ms(500);
}
} |
The .LST file shows that vs. 5.071 was used by MPLAB X to compile the file.
| Quote: | CCS PCM C Compiler, Version 5.071, xxxxx 30-Sep-20 21:03
Filename: C:\Users\Home\MPLABXProjects\PCM_test.X\build\default\production\PCM_test.lst
ROM used: 66 words (1%)
Largest free fragment is 2048
RAM used: 6 (1%) at main() level
18 (2%) worst case
Stack used: 0 locations
Stack size: 16 |
|
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19506
|
|
| Posted: Thu Oct 01, 2020 12:49 am |
|
|
As a comment, on the difference between the config bits between 5.071, and
5.095, noted by PCM_Programmer. The bits concerned are marked as
'unimplemented', and 'read as '1'. There is no actual memory at these
locations, so the change alters nothing, but CCS have obviously decided
not to program them to another value, because since nothing is there,
if you do, the programming code may fail when the bit doesn't change.
Suspect they have had problems with some programmers failing
when these weren't set as '1'....
Must admit I can't see any reason for this not to run, built with either
5.071, or 5.095. As PCM_programmer says, since the default is to enable MCLR
a pull up is needed on this pin or it won't work. |
|
|
starfire151
Joined: 01 Apr 2007
Posts: 195
|
|
| Posted: Thu Oct 01, 2020 7:40 am |
|
|
Thanks very much for your help in trying to solve this mystery...
I must have a cosmic vortex sucking out all life from this thing or something.
I tried another breadboard.
I verified a 10K pull-up on the MClr line.
The date on my 16F15325.h file is 3/28/2017, filesize is 57KB.
I tried the simple program from PCM programmer. It still does not work.
I tried loading the chip from the external ccsload.exe but it failed since it's version 4.053 and the device was not supported yet with that version. It failed during the chip detect.
I tried replacing the 16F15325 with a 16LF1825. I fired right up, flashing at 1 Hz. It's got to be the 16F15325 chip file somehow? |
|
|
starfire151
Joined: 01 Apr 2007
Posts: 195
|
|
| Posted: Thu Oct 01, 2020 8:03 am |
|
|
OK.... got it solved....
I downloaded and installed the latest version of ccsload (V5.063). When I tried to run it, it failed because it couldn't ID the chip. I updated the firmware to the most recent version (3.44). It correctly IDed the chip. I tried to program it through ccsload. IT RUNS!
I don't know why the built-in Build and Run function in the compiler showed it successfully loaded and started running.
All's well that ends well....
Thanks, again, for all the help.
Stay safe... |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19506
|
|
| Posted: Thu Oct 01, 2020 10:07 am |
|
|
The old 'not current' CCSLOAD/firmware problem... 
Had that only a few days ago with a PIC33. Sent it to another site, and had
"it won't work". Got them to upgrade to the latest programmer code and
firmware, and suddenly everything was OK....
The lack of 'diagnostics' here is sometimes quite annoying.  |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
