View previous topic :: View next topic |
Author |
Message |
Charlie U
Joined: 09 Sep 2003 Posts: 183 Location: Somewhere under water in the Great Lakes
|
16F819 Programming Problem |
Posted: Sun Oct 29, 2006 11:35 am |
|
|
I have a new circuit that is designed to use a PIC16F819. I tried a simple program that looked at a couple of inputs and turned on outputs based on the input state. This worked fine. I modified to body of the program to start working on my application. I reprogrammed the parts with this new version, and it doesn't work. The problem is that the f819 has become "invisible". No matter what I do, the part cannot be read back, including the device type. I have tried my ICDU40 both in-circuit and in standalone mode and I have tried an Melabs serial programmer and their new USB programmer. I now have 2 fully populated boards and 1 populated with only the processor that all exhibit this problem. I have also lifted all of the pins on the processor that are not used for programming and still no help. The programmers can read a new part, but not the ones with this code. Here's the fuse settings that I am using:
Code: |
#FUSES NOWDT //No Watch Dog Timer
#FUSES INTRC_IO //Internal RC Osc, no CLKOUT
#FUSES NOPUT //No Power Up Timer
#FUSES MCLR //Master Clear pin enabled
#FUSES NOBROWNOUT //No brownout reset
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#FUSES NOCPD //No EE protection
#FUSES NOWRT //Program memory not write protected
#FUSES NODEBUG //No Debug mode for ICD
#FUSES NOPROTECT //Code not protected from reading
|
Here's the fuse line in the hex file which appears to match:
:02400E00383F39
I have contacted Melabs and they were stumped and Microchip "resolved" my support request by saying that they could not support non-Microchip programmers. I am still working with CCS on this.
Anybody have any hints, suggestions, or old war stories to share on this??
Thanks, Charlie |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Sun Oct 29, 2006 12:24 pm |
|
|
1. What's the Vdd voltage on your board ?
2. What external circuit do you have on the MCLR pin ?
3. What external circuits do you have on pins B6 and B7 ?
4. What bypass capacitor(s) do you have on the Vdd pin ?
5. What kind of bulk capacitor(s) do you have on the Vdd voltage ?
6. What kind of power supply are you using ?
(i.e., 7805 voltage regulator with 12v wall-wart, etc.)
7. Did you ever enable the PROTECT fuse at any time ?
8. Are the fuses in the original program (that was working) any
different than the fuses that you posted above ?
9. Can you guarantee that there is common ground connection
between the programmer cable and the board ?
10. What is your compiler version ? |
|
|
Charlie U
Joined: 09 Sep 2003 Posts: 183 Location: Somewhere under water in the Great Lakes
|
|
Posted: Sun Oct 29, 2006 1:02 pm |
|
|
PCM, thanks for the response. Here's the answers:
1) 5V
2) There is a direct connection from the programming header to MCLR. There is a series 47k from MCLR to the pulldown pin of a reset chip which has a 4.7k pull up to Vdd. I have used this design on many other projects successfully in the past. The unpopulated board does not have any of the above components installed.
3) These pins are connected to the control inputs of a CD4066 analog switch. I have lifted these pins on my populated test board with no change. On the unpopulated board the analog switches are not installed.
4) On the populated boards there is a 0.1uf cap from the Vdd pin to the ground plane. On the unpopulated board there are no caps at all.
5) There is a 0.47uf cap on the output of the regulator. Maybe I should add a 10uf or so to test this??
6) 12 V switching wall wart (used successfully on many projects) and a TPS71550 5V at 50ma linear regulator. There is a 33uf and a 0.1uf on the input of the regulator. Vdd looks very stable on a scope. This is the first time that I have used this regulator.
7) None of the PROTECT fuses have ever been enabled.
8) The fuses were the same on both versions.
9) I have checked the ground from the programmer to the board and it is 0.2 Ohms on a 200 Ohm scale.
10) I am using version 3.246 of the compiler.
I am using the unpopulated board as a "socket" connected directly to the programmer. I can read the fresh parts fine.
Thanks again, Charlie |
|
|
Kenny
Joined: 07 Sep 2003 Posts: 173 Location: Australia
|
|
Posted: Sun Oct 29, 2006 6:34 pm |
|
|
I tried the config with a 18F818 which is similar to the 18F819 with a
melabs U2 USB programmer and was able to read back the code
created using both versions 3.249 and 3.242 (I don't have 3.246).
There was a 10k pullup on master clear.
The relevant line of the hex file is the same as yours
:02400E00383F39
ie config 0x3F38 at address 2007 which looks good to me for the #fuses.
And it is the same in the config window of the programmer after a read.
Here is the test code - led blinks at expected rate.
Code: |
#include <16F818.h>
#use delay(clock=8000000)
#FUSES NOWDT //No Watch Dog Timer
#FUSES INTRC_IO //Internal RC Osc, no CLKOUT
#FUSES NOPUT //No Power Up Timer
#FUSES MCLR //Master Clear pin enabled
#FUSES NOBROWNOUT //No brownout reset
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#FUSES NOCPD //No EE protection
#FUSES NOWRT //Program memory not write protected
#FUSES NODEBUG //No Debug mode for ICD
#FUSES NOPROTECT //Code not protected from reading
#define LED PIN_A2
void main(void)
{
setup_oscillator(OSC_8MHZ);
while(1)
{
output_toggle(LED);
delay_ms(500);
}
}
|
|
|
|
Charlie U
Joined: 09 Sep 2003 Posts: 183 Location: Somewhere under water in the Great Lakes
|
|
Posted: Sun Oct 29, 2006 7:13 pm |
|
|
Thanks Kenny for the information. That type of program was the first one that I tried, and it worked fine, also. It's just when I added some real stuff to the program that it made the pic disappear. I think I'll go back to the simple program and try it again. Then add bits and pieces and see how it works out. I'll also order some DIP parts and try them in a socket attached more directly to the programmer.
Please keep the suggestions coming. This is driving me crazy.
Thanks
Charlie |
|
|
|