Problems with Swordfish. PICkit2 and a PIC18K4550

[Aresby]

It's been a while since I did any PIC programming (2 years 3 months) but I've now rejoined the fold and intend to build something.

So I've got Swordfish (full version) installed, added the command line for the PICkit2 programmer and tried to program the usual LED Blink program (from the samples) just to prove it was all hanging together on a PIC18K4550 (40 pin, never used this one before).

It wasn't.

The program window shuts very quickly (despite me having entered /HK as per the Microchip instructions) so I can't tell what Swordfish thinks is happening. I tried /H9 too but same result. I seem to recall having this problem before but the grey cells have long relinquished that information.

From the PICkit2 programmer it says it can read the chip (really? all zeroes) but won't program the LED Blink.hex file as I get an error after a second or so saying "Programming failed at Program Memory address 0x000000".

Just in case a bootloader was already installed (I doubt it, on a blank, new chip) I reordered the code to start from 0x800 as I'll have to do that if I'm to use any USB functions on this chip, but it made no difference.

Any ideas, anyone? This is very frustrating considering that I seem to be starting from scratch again after 2 years of PIC absence

[bitfogav]

Are you sure its a pic 18K4550 and not a 18F4550?..

The command line I used was something like this

Code: Select all

/PPIC$target-device$ /F$long-hex-filename$ /M /R /T /Hk

[Aresby]

Geez, I can't even get the name of the device right

Yes, of course it's a 18F4550.

My command line is the same as yours. If the programming fails the window disappears instantly.

Without a PICkit 2 programmer attached for example it opens and shuts in about 0.1 seconds - it does not wait for a key press.

But why does the PICkit 2 programmer not write the hex file to the chip? I suspect Swordfish is having the same issue but I just can't get to read the error message.

[bitfogav]

I can't seem to reproduce the same issue has yourself

I am running SF version 2.2.2.2 on windows 8.1 (64bit) with PK2CMD version 1.12
and it is programming a 18F4550 that I have here with no issues..

Maybe try a different version of the pk2cmd?
link: http://www.microchip.com/search/searcha ... 2&q=pk2cmd

[Jerry Messina]

Do you know if there's any trick to keeping the cmd window open?

For me, it just flashes quickly and closes. The '-HK' option doesn't seem to do anything.

[bitfogav]

Using /Hk in the command line seems to work ok for me, it keeps the command window open..

I have had the command window open and close straight away when the pk2cmd.exe can't find the PK2DeviceFile.dat

The PK2CMD executable requires the "PK2DeviceFile.dat" file for execution.
This file should be kept in the same directory as the executable.

Maybe it is worth checking that you have the above..

I guess you could use "print screen" and see if you can catch the command window at the right time to see what error you are getting?

[Aresby]

I'll try all the suggestions.

PICkit2 reports occasionally that I should update the OS - but Microchip's website does not provide the update (neither manually nor via the inbuilt mechanism. I guess they want users to migrate to PICkit3)

But this still gets me no closer as to why PICkit2, by itself, will not program the 18F4550 with a valid hex file produced from Swordfish. Why do I get that message?

[Aresby]

I got the problems with the programmer sorted by writing a small, simple batch file:

Code: Select all

@echo off

REM /PPICtarget-device /Flong-hex-filename /M /R /T /Hk

ECHO Target Device: %1%
ECHO File Name %2%

pk2cmd.exe /PPIC%1 /F%2 /M /R /T /Hk

pause

This ran just as expected and gave me the following Swordfish / PICkit2 error:

Code: Select all

Target Device: 18F4550
File Name "C:\Users\Ralph\Documents\Swordfish\Samples\Blink\Blink - 1.hex"
PICkit 2 Program Report
26-Jul-2014, 16:21:38
Device Type: PIC18F4550

Program Memory Errors

Address   Good     Bad
000000    00FFFF   000000

Press any key to continue . . .

Anybody got any ideas?

[bitfogav]

One can only assume that the 18F4550 maybe faulty? have you got any other PIC's to test?..

[MattH]

Why don't you start PICit2 manually. Pick the right chip and load the .hex file.
Now you can do ERASE, BLANK check and WRITE to see what's going on.

[Aresby]

And that brings us back to my original question: when using the PICkit2 all by itself, and trying to program it using a hex file, I get an error after a second or so saying "Programming failed at Program Memory address 0x000000".

That's it, no explanation.

It's got to be something really, really simple. Surely?

[Jerry Messina]

Why don't you start PICit2 manually

That's a good suggestion.

I opened a command prompt and manually tried some things using PK2CMD from the command line.

Once I erased the device manually, everything seems to be working now for me from the IDE... window stays open, etc.
I did change some of the options, like removing the /R and /T parameters and that seemed to help (for me): /PPIC$target-device$ /F$long-hex-filename$ /I /M /HK

I don't know what it was really complaining about, or why it doesn't like what everybody else is using.

@Aresby-
Make sure you've got the right power selection mode (target/external), and try manually erasing it.

[Aresby]

Make sure you've got the right power selection mode (target/external), and try manually erasing it.

I left both options on the PICkit2 unticked and the demo board definitely lit the board's power LED when it attempted a programming run, so I am assuming that the PICkit2 correctly powered the demo board.

If I powered the board using an external supply then it made no difference (same error) anyway. Doh!

I'll try another PIC chip tomorrow, you never know, it may a funny chip as suggested in this thread.

I'm sure I tried erasing it and it did what it was supposed to do (according to PICkit2) but maybe it doesn't check its work afterwards? So it thought it had erase / written to the chip but in fact had not?

[Aresby]

I tried another PIC chip (another 18F4550) with the same result. On that basis I think we can rule out the chip itself.

As the prototype board I'm using is one I've never used before it cannot be assumed it is working. It does correctly have a 10k pull up resistor on pin 1 (although I notice that 33k seems to be suggested on this forum) and 5 of the 6 pins from the PICkit2 seem correctly attached (the 6th one is not connected to anything but that's OK, right, optional?).

I'm going to therefore try and program the chip using a plain old breadboard (there are only a couple of components and a few links required when programming using the PICkit2) and see what happens. I can then change components as I require. If I get it working (how can it not work!) I can then turn my attention to the prototype board I'm using and find out what's going on there.

Not sure when I'm going to have time to do this but over the next week or so. I'll post back the results when I've tried it.

[Aresby]

I could not wait a whole week so I knocked up the programmer on a breadboard real quickly this evening.

Result?

SUCCESSFUL ERASE!

SUCCESSFUL PROGRAMMING!

SUCCESSFUL VERIFICATION!

Apologies for the high spirited nature of this post but I'm quite pleased to have discovered that it is the prototype board that is the problem

Now I can relax and consider when I will have the time to fix that!

Thanks to everyone for their input, it got me thinking (eventually) along the right lines.

[Update: the prototyping board now also runs the BlinkLED program - so it's just programming a chip with which it has the problem. I suspect the 10k resistor to pin \MCLR...]