16f877a nothing happening

[ericgibbs]

really? thats interesting.. im afraid i dont know what a laser ranger is though

Its for Surveying work, measures distances up to 5000mtrs

 

[be80be]

Post your code would help I use 22pf for 4 to 20 mhz works fine. If you read the fine print it tells you to try from 15 to 30pf

change XT to HS

__CONFIG(LVPDIS & HS & WDTDIS & PWRTDIS & BORDIS & DUNPROT & WRTEN & DEBUGDIS & UNPROTECT);

 

[Wilksey]

be80be, the code is posted on #16, it seems to be Ok and it is simulated in Proteus.
I have used 22pf for 25 and 27MHz also and they work fine. The Ethernet chip uses 25MHz and i have used 22pf caps with that with success.

I'm guessing a fried PIC or an unusually broken crystal.

Wilksey

 

[be80be]

Simulated in Proteus. That don't mean any thing when it comes to real hardware.

In proteus you didn't hook the first wire to the chip. And code that runs in Proteus don't always run in the real world

In XT, LP or HS modes, a crystal or ceramic resonator
is connected to the OSC1/CLKI and OSC2/CLKO pins
to establish oscillation (Figure 14-1). The PIC16F87XA
oscillator design requires the use of a parallel cut crys-
tal. Use of a series cut crystal may give a frequency out
of the crystal manufacturer’s specifications. When in
XT, LP or HS modes, the device can have an external
clock source to drive the OSC1/CLKI pin (Figure 14-2).

 

[Wilksey]

be80be,

While I agree that it doesn't always work as the real hardware, I must say have personally had a 99% success with Proteus simulating basic connections such as servo drivers and USB systems with PIC chips.

And of course, it is only as good as the person designing the circuit in the first place.

Maybe it would help if the poster uploaded a image of the schematic?

Wilksey

 

[normad]

hey guys.. well it still doesnt work.. but i couldnt find a replacement pic.. my local dealer is out of stock i can upload the schematic but its pretty simple.. im using a few 2n3053s to drive some relays.. im biasing it with 1k5 resistors and i have a few inputs.. ive externally pulled up all my inputs with 10k resistors.. i checked the wiring and the board over and over again a couple of times..
i forgot to mention this.. from the first time i started programming this pic i got an error message fail to verify 0x0000 written 0x12*a(or something like that) read 0x3fff.. but then once i keep trying a few times it succesfully programs.. and when i verify it afterwards it says its fine.. i didnt have any such problem with my 16f628a so i dont think its the programmer.. im using a grabador todo pic.. i didnt give it much thought cause in the end it programmed fine.. but could it be an indication that the pic is bust?

 

[blueroomelectronics]

Which programmer do you have?

 

[normad]

grabador todo pic lite..

 

[blueroomelectronics]

Not familiar with that one. But it's really really hard to damage a PIC.

 

[Wilksey]

Does the PIC verify it's code? Sometime I have seen it where 3rd party progammers have actually failed to program the PIC in the first place, and I have also had it where MPLab with the ICD2 has said it has programmed and verified when in fact the code hasn't changed on the PIC itself!

Do you have access to another type of PIC programmer? Even if it's just to borrow to program that one.

If the PIC is damaged I would have thought that it wouldn't return the revision information for the chip, you may have developed a short inside with one of the ports, did you try a different port?

Wilksey

 

[normad]

ok i didnt know how i failed to see this at first but the pic isnt programming (sigh).. from the first time i tried to program it gave the error that i mentioned above. when i thought it worked after a few times what actually happened was i did a 'read' before the "successful" programming. so in the 'read' the software read all 0x3ffs from the pic and when programming since its the same as whats on the pic it didnt have to program anything! so it said successfully programmed. whenever i tried to program an actual program it gave the error. and when i use the 'detect ic' function it gives 'unknown'
so that means either the pic is bust or the programmer is bust. the software mentions that the programmer is fine.. and i succesfully programmed a 16f628a now just to make sure. so i guess it has to be the pic.. unless the programmer has enough voltage to program the 628 but not the 877... is that possible? do they have different architectures when it comes to programming? would turning on LVP change anything?
since its very unlikely that a pic came spoilt brand new (i didnt plug it anywhere before i programmed it and it gave the error first time) if it is actually the pic thats causing the problem would that mean that the dealer sold me an already spoilt pic?

 

[be80be]

Bill here a homemade one

It's a GTP USB Lite PIC Programmer

Here a better looking one **broken link removed**

It uses winpic800 software

And this is what is wrong with it

However, my programmer does not seem to work with it, till I try using the older version of 3.55b. I had uploaded the older version HERE. If anyone is able to let this programmer work with the latest winpic800, please update me too.

 

[normad]

yes gtp usb lite is what i have and yes it doesnt work with the latest version of winpic800. but i have the old version 3.55b and it works fine with my 628.. like i said the software says the hardware is fine.. im afraid its something else

 

[be80be]

It only works with version of 3.55b if you want the latest version it cost $60.00 for the firmware is what there saying

 

[normad]

i know thats the version im using

 

[Wilksey]

Microchip has defined the ICSP standard on all PIC's, so any voltage levels etc should all be the same and to the programmer, as long as the PIC is supported you shouldn't have any problems.
When you say it "reads" all 0x3ff's, are you sure you dont have "CODE PROTECT" fuse on? That causes the PIC to be unreadable and stops people form copying your firmware, when I say unreadable I mean it will return a default value for all codeblocks.

Can your programmer "read" the PIC revision? I am only experienced with PICKIT and ICD, so I dont know what the software can read from the PIC.