Can a PIC be a bit faulty?

[bigal_scorpio]

Hi to all,

Just got a PIC circuit built and programmed the PIC but got an error!

The configuration says 3BF9 but when it writes that it comes up with an error saying the config is 3BFF!

The PIC is a 16f84 and I have successfully programmed it before with my first program which was just a simple LED flasher, and that worked OK. However that program was a lot smaller than the Rev Counter program that I'm trying to do now so I wondered if a small part of a PIC can be faulty, maybe unable to be written correctly?

The program I'm trying to use is the RevMaster Firmware Zip at http://www.jeffree.co.uk/pages/tachometer-pcbs.html

I'm using the Velleman Pic Programmer with the Velleman Kit 8048 VM111 rev: 2.6.0.

I have built the circuit from the site on PCB and checked it many times, though it's got so few components on it that its fairly easy to check, and I cannot find any fault, the LCD is new and is the 2 x 16 line one that is used on the site.

I have tested with and without the slotted sensor which is on a separate plug in board, in case there was a problem with that, but I get absolutely nothing on screen. I have +v and ground at the circuits input pins and also at the connector for the sensor.

Please take pity on a poor fool who was just getting used to conventional electronics when I decided to have a stab at PICs, and though the circuits are simpler to build they seem even harder to fault find on! DOH!

Thanks for looking.............Al

 

[ericgibbs]

hi Al,
Look at this link.

http://forum.velleman.be/viewtopic.php?t=1279&sid=ca82896c8f5540e25429c61e604c4d39

The last digit in the two Configs you have posted are the WDT and the OSC selection.

The link refers to jumpers on the programmer.

Regards

 

[Mickster]

Al,

are you sure you have a 16F84 and not an 84A? I am not very advanced with PIC's, but when I have had similar problems in the past, it has sometimes been down to a processor mis-match.

HTH.

 

[bigal_scorpio]

Concerning jumpers and numbers

Hi Eric and HTH,

Hello again Eric, hope you are well.

As to the jumpers, they are as the guy said on the thread, they won't go on wrong (too big a gap between them) but they are on the 18 pin setting, which is for the 16F84.

As to HTH's suggestion that I may have an "A" version, The Chip is marked "16F84-04/P" so I can only assume its an old pre A version.

Anyway keep up the suggestions guys, no suggestion however strange will go unchecked!

Regards.............Al

 

[Pommie]

I have had pics go a bit faulty in the past. I had a 16F886 and it's internal oscillator ran at 5.3MHz instead of 8. Have you a Maplin nearby where you could get a new one and at least eliminate the chip.

Mike.

 

[bigal_scorpio]

Maplins

I have had pics go a bit faulty in the past. I had a 16F886 and it's internal oscillator ran at 5.3MHz instead of 8. Have you a Maplin nearby where you could get a new one and at least eliminate the chip.

Mike.

Hi Mike,

Yeah there is a Maplins quite near but maybe they are different in the UK to OZ, here they simply say "sorry thats a web only item" BEFORE you actually tell them what you want! hehehe

Seriously Mike, UK Maplins sell more radios than parts for radios and have virtually no stock, so you have to use the web service which costs a minimun postage of about 5 pounds for even a single chip.

That said they are excellent at sending replacement parts out, I have had 5 elements die on me from my solder station so far, and they have sent them out really fast every time. So they aren't all bad I suppose!

Anyway keep the suggestions going! Maybe there is someone out there who could convert a 16F84 hex file to say a 16F627, its certainly beyond me!


Al

 

[ericgibbs]

hi Al,
Why dont you register with www.Farnell.com they have a wide range of products, any order over £20 is free post in the UK.

They also have datasheets online for most of their stock items.

Unless you must use the 16F84, have a look at the 16F628A version.

Regards

You have my home address, I could check out your 16F84 on my system.

 

[Gayan Soyza]

Hi Eric and HTH,

Just a remind HTH means Hope This Help & not the name of the replier

I also found many faulty pics with these problems.

*some PICs internal RC not working.
*some PICs doesn't support to XT OSC but can work with XT OSC.
*some PICs some of GP registers not working.
*some PICs the internal EEPROM not working.

See how faulty are they.

 

[bigal_scorpio]

Still struggling

Hi Eric and Gayan,

I have a few PICs laying around, but to me the problem of changing the code is insurmountable. I don't pretend to unerstand the Hex at all, I can just about understand the basic code if its not too complex.

The problem with changing the programming is stopping me from using a different PIC, but maybe you know what I should change, and maybe could help me out.

Farnell does seem to be useful and I will have a good look through their site, I usually order from Rapid or a little known one called Bits Box, which is excellent for prices on his stock but not as big as some ranges!

Also thanks for the info on faulty pics, at least I know I may not be alone in having a non working Pic project.

PS Eric, If you think you could help convert to another Pic, the ones I have are 16F872 - 16F874 - 16F627 - 16F630 (if the postman ever decides to bring them) and a good few 16F54 OTPs which I now believe have already been programmed! Doh! But since I was Given the 54s I can't really raise a ruckus over those. Can you program (or just read) the 54s with your programmer to test them I wonder as my new Velleman does not list them and my old Picstart 16 B1 thinks they are written, but I'm not certain its working 100% It would probable think a sheep was a big cotton bud!

Thanks again guys...........Al

 

[Mickster]

I have a few PICs laying around, but to me the problem of changing the code is insurmountable...
...The problem with changing the programming is stopping me from using a different PIC, but maybe you know what I should change, and maybe could help me out.
Thanks again guys...........Al

The problem you have, is that only a .hex file is provided by the author and not the source (i.e. the .asm file)

Providing a .hex file somewhat protects the author's program.

There are usually 3 basic forms of distribution of a program:

1) A code-protected chip is provided. (Highest - cannot be dis-assembled without specialist equipment, such as that which may be utilised by Microchip or Government agencies. *Speculation*)

2) A .hex file is provided, which anyone can program to the specified chip. (Medium - those with an intimate knowledge of Assembly could probably work out the program from a dis-assembly. Some of the Guru's on here may be able to do this. *again, Speculation*)

3) The source code is provided, which anyone can freely modify and/or utilise on other chips. (Lowest - no real protection to speak of - there are usually/sometimes terms specified, such as "You may freely modify this program, but please include credit to the original author." or "You may freely modify this program, but I take no responsibility for your toes turning black, your daughter getting pregnant or your dog getting sick." etc. etc.)

If you really want this project to work for you and the original author is still active, drop him a line explaining your problem...he may be only too happy to help.

HTH.

 

[Pommie]

The source code is available but is in Unicode. Here it is in plain text for anyone who fancies converting to another compiler.

//
// Rev counter
//

#include <P16f84.h>
#include <displays.h>

//
// Define software version strings

const unsigned char VersionString1[]="V1.02";
const unsigned char VersionString2[]="19/02/2006";

#include "RevCount-vars.h"

// FUNCTION PROFORMAS

void clearLCD();		//Clear LCD display
void LCDNum();			//Output 5-digit revCount number to LCD
void Interrupt();		//Interrupt handler


//Time delay
void waitTime(unsigned int time);


//MAIN
//

void main ()
{

//Initialise Port A

 TRISA=0x17;			//Set all bits of Port A to input
  
// Initialize the LCD with startup message

 waitTime(1000);		//Wait a bit
 LCD(-2);			//2-line display, 8-bit, 5x7 format
 clearLCD();			//Initialize & clear screen
 LCDPrintAt(0,0);		//2nd message
 LCDString("RevMaster");	//Hello to the world
 LCDPrintAt(0,1);		//2nd line
 LCDString (VersionString1);	//Display software version
 waitTime(32767);		//Wait some more
 LCDPrintAt(0,1);		//2nd line
 LCDString (VersionString2);	//Display software date
 waitTime(32767);		//Wait some more
 
 LCDPrintAt(0,1);		//2nd line
 zeros=5;			//assume 1ppr and therefore 1 trailing zero
 scale=6;			//...and scale result by 6
 if (PA.B0==0)
 {
  LCDString("06");		//6 marks per rev
  zeros=5;			//...therefore 1 trailing zero
  scale=1;			//...and scale by 1
 }
 else if (PA.B1==0)
 {
  LCDString("60");		//60 marks per rev
  zeros=6;			//...therefore 0 trailing zeros
  scale=1;			//...and scale by 1
 }
 else LCDString("00");		//60 marks per rev
 LCDString(" PPR    ");		//
 waitTime(32767);		//Wait a bit
 
 LCDPrintAt(0,1);		//2nd message
 LCDString("     0 RPM");	//assume 1 mark per rev
 LCD(0x104);			//Force reverse cursor for number printing
 
//Initialise Port B and Interrupt settings

 TRISB=0x01;			//Set bits 1 to 7 of Port B to output,
 				//bit 0 to input
 OPTION_REG=0x85;		//Pull ups on B, TMR0 internal, 64 prescale
 INTCON|=(1<<T0IE)|(1<<GIE)|(1<<INTE);
 				//Enable interrupts for TMR0 & INTE
 
// MAIN CONTROL LOOP - Select major mode & execute that mode's behaviour
 
 while(1)			//Loop forever
 {
  if (timeInt)			//If there has been a 1/10th second interrupt
  {
   timeInt=0;			//Clear the int flag
   actual=countHi;
   actual=(actual<<8)+countLo;
   				//Get the count value
   countLo=0;			//Clear the count value
   countHi=0;
   actual=actual*scale;		//Scale the value by 1 or 6
   LCDNum();			//Print the value
   LCDPrintAt(16,1);		//Lose the cursor
  }
 }
};




//
// Waittime function - waits for a specified delay period.
//

void waitTime(unsigned int time)
{
 while(time--)	;		//Repeat loop time times
};

//
// LCD Clear function
//

void clearLCD()
{
 LCD(0x108);			//Display off
 LCD(0x101);			//Clear display, cursor home
 LCD(0x10f);			//Display on, cursor on, flash cursor
 LCD(0x180);			//Print position 0,0
};

//
// LCDNum function - prints 4 digit revCount to LCD display (backwards)
// Includes decimal point if the point parameter is within range of digits
//

void LCDNum()
{
 char digits;
 LCD((int)zeros-1+0x180+0x40);	//Print position zeros,0
 for(digits=5; digits; digits--)
 {
  LCD((actual%10)+'0');		//Print Nth digit 
  actual/=10;			//lose Nth digit
 }
};

//
//Interrupt handler
//Interrupt generated every 1/50 secs by timer 0
//and every time a pulse is detected on Port B bit 0
//

const int QuickInt=1;		// Flag use of quick interrupts

void Interrupt()
{
 #asm
 btfss INTCON,INTF		; If tacho interrupt...
 goto noTach
 incfsz countLo			; Increment low count
 goto clearTach
 incf countHi			; Increment high count if necessary
clearTach:
 bcf INTCON,INTF		; Clear tacho interrupt...
noTach:
 btfss INTCON,T0IF		; If timer interrupt...
 goto noTimer
 decfsz sec			; Decrement seconds count
 goto clearTimer
 movlw 1
 movwf timeInt			; Signal a timer interrupt
 movlw 50
 movwf sec			; Re-prime the timer
clearTimer:
 bcf INTCON,T0IF		; Clear timer interrupt...
noTimer:
 #asmend
}

If a new chip doesn't work then I could have a go at converting it to a 628.

Mike.

 

[bigal_scorpio]

Problem solved!

Hi everyone,

Thanks for all the help, I've finally solved the problem.

I think it was due to the fuse settings which on ProgPic 2 seem to be different to all the other programmers. IE there are more of them and they do not say what they are for, anyway after fiddling with them and trying different ID numbers I got it working!

Don't know why ProgPic 2 has to be different to all the other programmers though, so if anyone does know please fill me in.

Thanks again all.................Al

 

[Mickster]

Al,

if you want to gain a better insight into the CONFIG settings and how they translate to a hex value, have a look at the datasheet for your 16F84, here: https://www.ortodoxism.ro/datasheets/microchip/30430c.pdf and refer to section 8 - "Special Features of the CPU." sub-section 8.2 - "Configuration bits."

Using VELLEMAN PIC PROGRAMMER (not PicProg2006) you can click the "View/Set" button within the Configuration area on the main screen, where you will be presented with a dialog box showing the 14 bits of the Config Word. A checked box represents a 1 and an unchecked box represents a 0.

e.g. Your 3BF9 & 3BFF translate to 11101111111001 and 11101111111111 respectively. From the datasheet, you will note that 3BF9 disables the WDT and selects XT (external crystal) oscillator, whereas 3BFF enables the WDT and selects RC (Resistor Capacitor) oscillator. The PCB layout in the linked PDF has an external crystal oscillator (XT) and the supplied hex file most likely contains 3BFF, but having the choice to select differing config options, within the main screen of PicProg2006, has probably led to the confusion.

Given the choice of the two Velleman programming softwares, when using a supplied hex file from a project, I would say probably the best option is to use VELLEMAN PIC PROGRAMMER and uncheck the "Write Config.Word" box.

HTH.

 

[mike50]

Al,

e.g. Your 3BF9 & 3BFF translate to 11101111111001 and 11101111111111 respectively. From the datasheet, you will note that 3BF9 disables the WDT and selects XT (external crystal) oscillator, whereas 3BFF enables the WDT and selects RC (Resistor Capacitor) oscillator. The PCB layout in the linked PDF has an external crystal oscillator (XT) and the supplied hex file most likely contains 3BFF, but having the choice to select differing config options, within the main screen of PicProg2006, has probably led to the confusion.

The hex file doesn't contain config data.

Clearly WDT needs to be disabled, as the source shown never clears the WDT.

So the 3BF9 makes more sense than 3BFF.

Mike

 

[BaCaRdi]

Nice one! Tell tale sign that WDT needs to be disabled, or the pic would keep resetting on WD

-BaC

The hex file doesn't contain config data.

Clearly WDT needs to be disabled, as the source shown never clears the WDT.

So the 3BF9 makes more sense than 3BFF.

Mike

 

[Mickster]

The hex file doesn't contain config data.

Firstly, I'll get this bit out of the way...I'm still a noob, but hope to gradually change this status. I'm not here to pick an argument, but the quote above differs from what I had initially thought, along with what I have just pulled up on 'the net'.

For instance, the datasheet for this PIC lists the Config bits in address 2007h and a disassembly (Using IC-Prog) of the .HEX file shows:

ORG    0x2007
DATA   0x1F

toward the end of the file.

Also, in this link:
https://books.google.co.uk/books?id...aqeAfWy&sig=x4NkrWuUFv03EKV8Q1Td2pxw54U&hl=en

the first paragraph mentions Config fuses in the .HEX file.

Please can you expand on your statement?

 

[Nigel Goodwin]

Firstly, I'll get this bit out of the way...I'm still a noob, but hope to gradually change this status. I'm not here to pick an argument, but the quote above differs from what I had initially thought, along with what I have just pulled up on 'the net'.

For instance, the datasheet for this PIC lists the Config bits in address 2007h and a disassembly (Using IC-Prog) of the .HEX file shows:

ORG    0x2007
DATA   0x1F

toward the end of the file.

Also, in this link:
https://books.google.co.uk/books?id...aqeAfWy&sig=x4NkrWuUFv03EKV8Q1Td2pxw54U&hl=en

the first paragraph mentions Config fuses in the .HEX file.

Please can you expand on your statement?

He didn't say ALL HEX files don't contain the config data, they can, and they should - but some people create HEX files without any config data in it. Presumably the particular file under discussion didn't contain config data, and the programmer should warn you when you load it (WinPicProg does).

 

[Mickster]

He didn't say ALL HEX files don't contain the config data, they can, and they should...

Ah, thanks for clearing that up, I took "The Hex file..." literally.

... Presumably the particular file under discussion didn't contain config data, and the programmer should warn you when you load it (WinPicProg does).

Would the section:

         ORG     0x2000
            DATA    0x0F
            DATA    0x0F
            DATA    0x0F
            DATA    0x0F
 
            ORG     0x2007
            DATA    0x1F
 
            ORG     0x2100
            DATA    0xFF
            DATA    0xFF
            DATA    0xFF
            DATA    0xFF....

from the IC-Prog disassembly of the file under discussion indicate whether Config data is present within the HEX file?

The datasheet mentions "Address 2007h is beyond the user program memory space and it belongs to the special test/configuration memory space (2000h - 3FFFh). This space can only be accessed during programming."

Am I mis-interpretting the disassembly to contain something that is not there?

Thanks.

 

[mike50]

Firstly, I'll get this bit out of the way...I'm still a noob, but hope to gradually change this status. I'm not here to pick an argument, but the quote above differs from what I had initially thought, along with what I have just pulled up on 'the net'.

For instance, the datasheet for this PIC lists the Config bits in address 2007h and a disassembly (Using IC-Prog) of the .HEX file shows:

ORG    0x2007
DATA   0x1F

toward the end of the file.

Also, in this link:
http://books.google.co.uk/books?id=...aqeAfWy&sig=x4NkrWuUFv03EKV8Q1Td2pxw54U&hl=en

the first paragraph mentions Config fuses in the .HEX file.

Please can you expand on your statement?

The hex file in question from the site identified in the original post

The program I'm trying to use is the RevMaster Firmware Zip at http://www.jeffree.co.uk/pages/tachometer-pcbs.html

contained no CONFIG data.

Mike

 

[Nigel Goodwin]

from the IC-Prog disassembly of the file under discussion indicate whether Config data is present within the HEX file?

No, it's disassembling what's in memory, and as IC-Prog originally used my old 16 bit dis-assembler (even with my name on the resultant files) I presume it still works the same way, using the default config fuses or the value it's been set to.