Freezing PIC !

Hi all,

I run into a very strange thing and I’m stuck. The following has happened 3 or 4 times before and again today and I cannot figure out the reason why: Suddenly the PIC freezes after I transferred to it a newly compiled program. It does not help to reset or cycle power, its frozen solid. There are no errors when compiling (MCS+/MPASM) and non from the programmer and its software (WISP648/xwisp2 ver 1.9.5)! Every time it has happened I have ended up having to re-installing MPLAB, PBP and MCS. After this tedious manoeuvre I re compile the program and the PIC come to life again. This is no different with another PIC, another circuit or a different program and it can strike at any time (at least I haven’t noticed any pattern yet). I have upgraded my XPP to service pack 3 but this made no difference.

So.. my dear friends, have anyone have experienced something similar or have got any clues?

Thanks!

We have no program to view!!!
We have no idea which PIC you are using!!!
We have no idea what this PIC is supposedly trying to accomplish!!!
Are you writing over the code space in the PIC (writecode, etc)?
Are you sure your power supply is solid?
Can you pull the PIC out, put it back in and have it work again?
Is this device attached to a PC most of the time?
So, while you included a lot of information, I don't think the bulk of it is of any help.

Hi skimask,

There’s no program to view since it can happen with any program from a simple blink a LED to slightly more advanced stuff.
As mentioned it’s not device related since it happened with different PIC’s 16F648, 16F88, 16F688 and 16F886 if they have something common. I have tried to remove pull-ups and pull downs to no avail. The program is verified 100% OK by the programmer everytime.
I am not exactly sure what you mean by “writing over the code space”, I am a rookie and I’m not challenging the boundaries in any way (as far as I know).
The power is good and solid according to my scope and hasn’t caused any glitches before.
I haven’t tried to pull and reinstall the PIC, it’s a proto board and the programmer is permanently connected (ICSP kind).
It is connected to my laptop while I am trying out different programs.

Thanks!

Does your programmer have a "erase before program" option?
And is it set to erase?

Hi PICante,
You know . . . I'm thinking. . . when you set all that stuff (programs) up in your PC it returns everything to default settings, and then you may or may not go in and rearrange things to your liking, Where am I going with this you say? Maybe your programmer is somehow getting changed from intel hex file output to something else. I think in MCS, under view, program options or whatever it says (I am using my wife's computer so I am telling you this from memory), anyway in there where you change assemblers, there are check boxes which set the assemblers output type, and maybe it is getting it's settings changed.<br>
Edit: on my own computer now. . . Open up MCS, click on the tab marked View, Scroll down the list to "Compile and Program Options" click on this and a window will open, Under the Blue bar labled Compile and Program Options are 3 tabs. Click on the tab marked Programmer. On the lower 1/2 of this tab, right side are 3 check circles, marked as follows INHX8M , INHX85, and finally INHX32. The first one marked INHX8M should be checked.<br> Check this as the source of your problem.

Hi Dave & Joe,

No matter which tab (Compiler, Assembler or Programmer) the setting is INHX8M. The alternatives in my version are INHX8M, INHX8S and INHX32. However this felt like closing in on it since I can program the PIC successfully with any file not compiled after this “disease” strikes.

The programmer performs a (target erase) before slamming the new stuff, the “DOS” window for the programmer looks like this:

Code:

---


Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corporation

C:\PIC>set XWISP2=port 3

C:\PIC>x 64
 xwisp2 version 1.9.5 for Windows (Jan 24 2008, Open Watcom C/C++ 1.70)
File 64.hex loaded and is Intel Hex format conforming
Detected programmer: Wisp648, firmware version 1.23
Target: 16F688 revision 06 (ID=1186)
Target erased
Transferring program to 16F688 via Wisp648
Transferring program memory...100%
Verifying program memory......100%
Transferring data memory......100%
Verifying data memory.........100%
Transferring ID memory........100%
Verifying ID memory...........100%
Transferring fuses memory.....100%
Verifying fuses memory........100%
Write-Verify operation terminated successfully in 3.58 seconds
Putting target in run mode
xwisp2 terminated successfully in 5.30 seconds

---

Thanks guys!

Hi, Picante

At First,You should try to read the device and compare its memory to the "original" HEX ...

with another programmer ...

CONFIG Word writing ( or loading ) problem ???

My easypic5 made it to me once or twice ... as the config word location depends on which IDE was used ...

Alain

Bonjour Alain,

So, what you suspect is that something changes in the HEX file while transferred to the device?

Thanks!

Hi,

Something like that ... I know some IDEs which place the config word in another file than the HEX , whose programmer often losts the "header file" ( where config is located ) location...

most of time when there has been compilation errors before ... and an errorless compilation (since the IDE opening ) is always followed by a good chip programming.


Ahhh ... reliable IDE's ... where are you ???

Alain

Thanks Alain,

I am not sure how you mean: “most of time when there has been compilation errors before ... and an errorless compilation (since the IDE opening ) is always followed by a good chip programming”… and where exactly do you suggest I look for the misplaced file in my environment?

Remember I am kind’ a green in this area! :-)

Quote:

---

it’s a proto board and the programmer is permanently connected (ICSP kind).

---

This would be my 1st suspect. If the device programmer isn't releasing /MCLR it would
cause it to hang. It may also be causing problems by leaving it connected to the PIC pgm
and data pins.

Have you tried disconnecting your programmer & resetting power to your proto board?

Hi Bruce,

Yes I have tried this even though this programmer is supposed to be internally disconnected as it puts the PIC in run mode. I also tried to removed pull-ups and pull-downs while programming.
However as mentioned before the PIC accepts and run any program not compiled after this “disease” strikes? And this includes programs running in the exact same hardware.

Thanks Bruce.

Strange problem for sure. I would create two copies of the same program. Something simple
like blink1.bas and blink2.bas. Compile blink1.bas and keep it in a separate directory outside
of my usual code files directory.

Compile blink2.bas and compare the two .hex files. The next time this happens, recompile
blink2.bas and compare the .hex files again.

If they're different you have it narrowed down to some part of the compile process. That
should make it easier to nail down.

I would also try reinstalling stuff one at a time. I.E. reinstall MCS, then test it before you
reinstall PBP or MPLAB. It may be only one of these getting screwed up.

I had some odd problems recently after installing XP service pack 3 where XP would not allow
me to save a ton of various file extensions. I had to do this;
http://www.winhelponline.com/blog/re...in-windows-xp/

I have experienced this when my programming cable is left plugged into the board.
It doesn't release the PIC from reset is my theory.

Also check to be sure your haven't left your PIC programmed for debug.
Not sure that causes anything your experiencing but I had done that once before and while running the PIC would occasionally lock up and have to be reset.

Good Luck

Good point on the debug thing. A while back someone here was having a similar problem
when using MCS to compile.

They were clicking on ICD Compile/Program VS compile/program. And of course the PIC
did nothing since it wasn't being controlled by the MCS ICD.

It’s now all re-installed and works just fine again! Tried different variations of hardware and software but I couldn’t provoke it to fail again. There are no problems leaving the programmer connected all the time, the PIC starts running as soon as the programmer is finished. Only difference now is a slightly newer version of MPLAB the 8.10. I have followed Bruce advice to create two copies of a simple program and store one of them in a safe place if (God forbid!) it ever happens again.

Wayne>
Once I made a mistake using an NC micro switch on one of the pins used by the programmer and the programming failed. I can imagine some programmers can when connected disturb the PIC in a similar way. When I discovered my mistake I just needed to push and hold the switch while the programmer was running and it worked fine. (I took me awhile to find it though!).

Thank you very much guys for being here!