dsPIC30F4011 Verify Fail

[dknguyen]

Hello. For our design project at the U, we keep running into the problem of getting the hardware to work. The problem is that everything else on the ICD2 and the dsPIC30F4011 seems to work, except that the verify will fail after programming- and it seems to be a completely random hit or miss thing to get it to work.

-I never ran into this problem when I was working on our first assignment with it
-Occasionally I will build a circuit (bare bones all the time) and it will work perfectly without fail but...
-if we do something like unplug the ICD2 and plug it into another PC beside us then it the problem will reappear and WON'T go away even if we plug it back into the first PC
-if we sit there for hours on end continuously programming it over and over again, occasionally, it will pass the verify
-we have gone through 6 different ICs
-we have used 2 different ICD2s
-we have used the socket universal programmer and it fails the verify too
-this does not happen when we use another PIC like the PIC18
-We are working from behind VMWare on a Linux system because that's what the lab has for MPLab, but we have also tried it on Windows Laptops in our group but my group members' laptops are funky in that the USB doesn't seem to behave consistently properly even with a flash drive and someone else has Windows Vista which is garbage because it does't even recognize the USB device. None of this explains why it fails on the universal programmer which it used to work just fine for on the first assignment.

It's almost like all the chips are damaged or something, except sometimes it will work and work flawlessly. Has anyone ever experienced anything like this? It's become a brick wall in our progress.

 

[Torben]

I was having trouble last year with some uCs which would only intermittently program correctly. It turned out that the programmer did not like the ordering of the hex file and its buffer couldn't hold enough data to allow the hex to be re-ordered for programming. I wrote a PHP script to reorder the hex files so that they didn't need reordering by the programmer and the problem went away completely.

I have absolutely no idea if this problem even applies to your situation but thought I'd mention it.


Torben

 

[blueroomelectronics]

I've got a dsPIC30F3013 that's fussy, it works if you power it on and off before you do anything. You also must have VDD, VSS, AVDD & AVSS connected before it'll program.

 

[dknguyen]

Yeah, we've always had the digital and analog power going to it. I think we've also powered it on and off (though not intentionally, it's just hitting the power supply button whenever we're inspecting the circuit). No dice. Yours is fussy too you say?

 

[blueroomelectronics]

Well I finally got it working reliably on a solderless breadboard nonetheless. Trick was a really really short programming cable 4".

 

[JFDuval]

Hello!

I had the same problem with a dsPIC30F2010.

I found: **broken link removed** and I modded my ICD2. Now it's working perfectly.

 

[blueroomelectronics]

Edit: the microchip resistor change solution might explain why my Junebug had no problem with the dsPIC (100ohm) and my Inchworm was intermittent (330) I'll have to mod an Inchworm and try 100ohm resistors on the PGC & PGD lines.

Here's a photo of a very short ICD cable with a dsPIC30F3013
**broken link removed**