ravix

Hey everyone, I bought and assembled an inchworm a few months ago and I am going CRAZY trying to get it to debug or program.

It seems entirely unable to program a chip. When I am in programming mode, I don't get any errors, but the chip reads 0000 across the board, even after programming.

In debug mode, I get the following error:

ICD0161: Verify failed (MemType = Program, Address = 0x0, Expected Val = 0x2826, Val Read = 0x0)
ICD0275: Programming failed.

I think it probably has something to do with configuration (I am using a PIC16f88):

_CONFIG _CONFIG1, _CP_OFF & _CCP1_RB3 & _DEBUG_ON & _CPD_OFF & _LVP_OFF & _BODEN_OFF & _MCLR_ON & _PWRTE_ON & _WDT_OFF & _INTRC_IO

_CONFIG _CONFIG2, _EISO_OFF & _FCMEN_OFF



Any ideas? Please?

futz

For some reason I've never set my 16F88 up with a text config. Guess I copy/pasted one that worked and never bothered to research any further.

Anyway, it works on all my 16F88 programs so far. Here it is:
EDIT: Just looked it up and here's what $3f2a is:
Watchdog Timer - Off
Powerup Timer - Off
RA5/MCLR Pin Function Select - MCLR
Brownout Detect - Off
Low Voltage Program - Disabled
Data EE Read Protect - Off
Flash Program Write - Write Protect Off
CCP1 Mux - RB0
Code Protect - Off
Fail-Safe Clock Monitor Enable - Disabled
Internal External Switch Over Mode - Enabled

Pretty standard stuff.

__________________
=========================
Futz's Microcontrollers & Robotics
=========================

kchriste

I would remove _DEBUG_ON from the config. Or try Futz's config word.

__________________
--- The days of the digital watch are numbered. ---

ravix

Thank you both.

I tried as you suggested and now I am receiving a different error.

ICD0083: Debug: Unable to enter debug mode. Please double click this message for more info

By the way, I was actually able to program some information onto the device, but it seems.. sporadic? I think there may be something wrong with my inchworm. Is there a way to diagnose it?


Edit: I had these exact problems in March of this year, too. I actually took a break from trying to learn Pic programming completely.
http://www.electro-tech-online.com/m...orm-debug.html

I am a pretty patient guy and this is driving me crazy!!

blueroomelectronics

Target 0000 usually means the ICD cannot see the target chip. Take a look at the Inchworm Quick Project poster on my site for a simple test program and sample PIC hookups. Leave out the CONFIG2 directives for now as you must have a functioning oscillator for debug to work. (Programming mode doesn't matter if the oscillator is working on the target PIC)

PS sometimes the PWTE_ON can cause debug problems.

Check the Firefly schematic for the 16F88 to ICD pinout.

Edit: what does your target 16F88 schematic look like? Can you post an image?

__________________
Bill
Smart Kits build Smart People
http://www.blueroomelectronics.com

blueroomelectronics

Inchworm... One last thing make sure the caps near the crystal are 18pf to 22pf (not 33pf as shipped with some kits)

MPLAB has a programmer status window, can you post the voltages it sees?

__________________
Bill
Smart Kits build Smart People
http://www.blueroomelectronics.com

ravix

They are both 33's, but I have some 18's and 22's laying around. Could that explain the sketchy behavior I've been seeing? Sometimes it programs perfectly, and other times its spews all kinds of random errors. Does it matter if I use 22pf or 18pf?

I just tried to "Erase Part" and it told me the memory was locked. One minute later it erased it perfectly. !!

I have the 16f88 setup exactly as it is in the firefly schematic.

And the voltages are okay, I think:
Target Vdd: 5.00
Target Vpp: 12.46
MPLAB ICD 2 Vpp: 12.78

blueroomelectronics

Try the 18pf, the 33pf could be the problem, it was for some crystals. The voltages look spot on.

__________________
Bill
Smart Kits build Smart People
http://www.blueroomelectronics.com

ravix

Changing the Cap's didn't seem to help.

Any more way to debug the inchworm?


Edit: Now I am getting a new warning:

ICDWarn0020: Invalid target device id (expected 0x4D, read 0x1FF)

Or (If I change to 16f88 in "devices")

ICDWarn0020: Invalid target device id (expected 0x3B, read 0x1FF)


It does occasionally program the chip though... but usually I get the following error:


ICD0161: Verify failed (MemType = Program, Address = 0x0, Expected Val = 0x1683, Val Read = 0x3FFF)
ICD0275: Programming Failed.

dipmicro

I remember seing similar problem with real 'puck' ICD2 before. As far as I remember the problem turned out to be bad ICSP connection. Your Inchworm sees 0x1FF instead of 0x4D, so 0s are read as 1s - seems that ICSP data pull-down is not strong enough, which may point out to some kind of bad connection joint (or a design issue on the target side).

Just a few weeks ago I had an interesting discussion with Eric Chan of Polyview Electronics regarding IDC connectors Inchworm uses. Apparently, the female counterparts of IDC tend to wear out after few reinsertions.

I am not saying the above is a problem, just a hint where to look. At this point I would try to solder the wires directly between Inchworm and target to eliminate connector issues. Also isolate B5,B6 completely, if you are using some kind of isolation circuitry (e.g. resistors), take them off.

__________________
www.dipmicro.com

jankop

How long is your cable from Inchworm to target? For 16F88 debugging must it be shorter then 6".

3v0

If you do not use an ICSP connector with a hood on the target it is possible to connect the cable 180 degrees off from what it should be, you will get a device id of 0x1FF.

As long as you can not get a correct device ID 100% of the time any effort to program the chip are hit and miss.

I would try making a new ICSP cable.

What dipmicro said about B5 and B6 is important. If are using them to drive LEDs or have any other resistors on them it will cause problems also. When I use all 8 bits of PORTB to drive LEDs I setup the circuit so that I can pull a single wire or jumper to disconnect the ground to all 8 LEDs. This allows it to program. Once the chip is programed I reconnect the ground and release from reset.

Be sure to use bypass cap(s) on the target.

EDIT: Some people have a difficult time with IDC connectors. The best way I have found is to use a small bench vice (2 to 4 inch jaws) to press the connector together.

ravix

I finally got it working! After all these hours, I just needed to replace the cable connecting the inchworm to the breadboard.

I just programmed, read, released (watched my LED blink) then erased and programmed again without a single error or warning.

Seriously, thank you all so much. I am so excited to get to work!!

-Eric


Edit: I am debugging now without any problems at all. Thanks again! You guys are so helpful!

blueroomelectronics

Glad you got it solved, happy programming.

__________________
Bill
Smart Kits build Smart People
http://www.blueroomelectronics.com