1

I recently decided to get into learning how to develop embedded systems, using MPLAB X IDE and literature available on microcontrollers. The vast majority of which referenced the PIC16F84 and as such I decided to invest in the hardware to build and test out the programs, once I had gotten familiar with coding using the PIC16F84.

Unfortunately, the specific ICSP programmer used for this MCU is no longer available & a lot of the online commentary were suggesting that PICKit 4 was essentially the same, but much better & faster. Therefore, I bought the PICKit 4 assuming that it would be backwards compatible with the PIC16F84.

To cut a long story short, it is not backwards compatible without making a slight modification to the circuit, which I found after doing some research on the internet. It simply involves putting a 100ohm resisor in series between the PICKit progamming pin and the progarmming pin on the PIC16F84.

However, although the PICKit 4 is able to communicate with the PIC16F84, I keep on getting this error "Verify failed. [ Pgm ] at 0x0, expected 0x00002805, got 0x00002807".

PICKit Error

Despite my best efforts, I am unable to find a resolution to this problem, as of yet. However, any insight that anyone can provide will be very much appreciated.

Before, I forget I am using MPLAB X v5.05! :)

Another thing. I have also tried to slow down the program, using the device properties menu!

aLoHa
  • 587
  • 1
  • 6
  • 16
  • Some .memory above program stored device Id . pickit read that numbers and compare with data base. Check if you properly choose device type. Chip is old, microchip does not support it, visit some specialised forums. – user263983 Dec 18 '20 at 00:27
  • Thanks for your comment. However, the video that I saw in which the teacher was able to program a PIC16F84 using a PICKit 4 is about 12 months old. See link: https://www.youtube.com/watch?v=s4IgVmhHbAc – aLoHa Dec 18 '20 at 01:53
  • Device id is for PIC16F84A is 0x560. It is completely different. May be some glitch in MPLAB. – user263983 Dec 18 '20 at 02:39
  • 1
    Verificatio fails, but the code might be uploaded sucessfully. Flash a blinking led and check if it works or not. – fifi_22 Dec 22 '20 at 21:10
  • 1
    That is a single bit error. 2805 and 2807 differ by one single bit. So 2805 was programmed into location 0, but on readback, 2807 was read. So verify failed. I am not sure who is doing the reads and verifies, but sometimes an issue like this can be caused by poor signal integrity somewhere in the line. So if any cables are of low quality or suspect, it may be worthwhile to change them out. Also programming different data packages to see if that makes a difference. – user57037 Feb 11 '21 at 17:17
  • Thanks for the comment @mkeith. I'll give it a try once I return to trying to program the 16F84, in the near future! – aLoHa Feb 16 '21 at 13:06

3 Answers3

2

First byte of programs is GOTO[label], unconditional jump to addresss 005. But you have "1" in second bit instead of "0". May be it is a broken bit in program memory. You can upload program memory and compare it with origin. If it is only one bit, you can shift two cells the begining of main program. Just write two NOP before the label of main cycle. So it will start from 007.

Mike
  • 2,146
  • 1
  • 14
  • 29
user263983
  • 1,599
  • 1
  • 4
  • 9
  • Please elaborate on "you have '1' in second bit instead of '0'." I will be giving your suggestion a try in the next couple of days. Haven't gotten back to the p16f84, as I've been too busy developing on the p16f1829. – aLoHa Jan 10 '21 at 14:25
  • I mean the memory of you MCU is damaged. But it may be one bit of memory cell with address 005. Unprogrammed cell has FF value, but one bit is not changes when you write 0 . Try to stop that cell in PR?ogramm. Address 004 is interrupt vector, next cell may be top of main cycle. Change that to 006. – user263983 Jan 10 '21 at 17:16
  • Ok. Thanks for that. Will give it a try. – aLoHa Jan 11 '21 at 01:58
  • Any chance of a vote for my question? ;) – aLoHa Feb 13 '23 at 20:10
1

You could try slowing down the programming as a long shot....

I have MPLAB X IDE v5.35.

Right click on your project name in the projects pane

Select "set configuration" - customize

Click on Pickit 4 on left hand side of window.

Select drop down menu "memories to program"

Select "program options"

Set program speed to "low"

click "apply" - "ok"

  • Hi James, sorry but I forgot to mention that I had already tried that in my post. But, thanks for the suggestion anyhow. – aLoHa Dec 18 '20 at 00:07
0

Hopefully to help people later because I ran into this.

The first bytes/bits of your flash are configuration bytes/bits (sometimes called fuse bytes/bits) and sometimes the "erase" step avoid them. You either need to read these and make them sync to your project or write new ones.

The other option is sometimes changing your debugger settings so that it truly erases the full flash memory space.

How you do that depends on your IDE and programmer.

TravisT
  • 1