Verification problem with ICD-S 20MHz

[M.W.]

Hallo guys,

i have a verification problem with the ICD-S mentioned above.

I designed my own target board and want to program it with the ICD-S.
In the ICD Control Program (V2.12) I checked the target, the ICD and the Comm-Port. Everything is ok. Even in the advanced dialog the ICD control programm detects the device (PIC16F628).

And now the problem:

When i download the Hex-File to the target, it looks like the Control software is doing it. There are no errors. But when the verification results appear, the expected and the actual values are different. The actual values are all `0000'.

I think the PIC isn`t programed correct or even NOT programed because the target software is not running.

Can someone help me out of this.

Thanks M.W.

[mcafzap]

So what voltage is the PIC using? If less than 5, then check elsewhere in this forum for the difficulties of debugging at this voltage, you may not be able to burn the fuses. This could stop the oscillator from running or fail to clear the memory if it has been protected.

HTH

Steve

[M.W.]

Hello Steve,

thanks for the reply.

The PIC uses 5V. So I think this is not the problem.

Other reasons?

Best regards
Markus

[mcafzap]

Have you successfully done this before? In my experience it is crucial that the length of the cables (between the ICD and the target board) is minimised

The only other thing that springs to mind is to try another chip - though I daresay you've already done this.

Failing that, another programmer instead of the ICD.

Sorry, all negatives I'm afraid.

Steve

[Guest]

"Have you successfully done this before? In my experience it is crucial that the length of the cables (between the ICD and the target board) is minimised"

I programmed other chips in other hardware (PIC16F678) and there was no problem.
The length is also not the problem. It is 10cm.

"The only other thing that springs to mind is to try another chip - though I daresay you've already done this."

I havent't done this but I tried another programmer (Warp13a) with this chip and it works fine.

"Failing that, another programmer instead of the ICD."

Thanks you Steve.

Any other reasons?

Markus

[M.W.]

Hello,

are there really no other suggestions from you? Is there nobody else who can help me? I can't believe it.

Please help me with this problem. I'm very confused.

Best regards
Markus

[rwyoung]

Was your 16F628 programed prior to your use? If so, try a bulk erase first with the ICD software. Then try programming.

Double check your voltage rails to confirm they are 5V, +/- 10%. Don't assume they are, measure it. Measure it before the programmer is connected, after the programmer is connected and idle and again during a programming attempt.

If you have access to an oscilloscope (digital would be best), look at the VPP signal during programming and confirm its level and timing (consult the Microchip programming docs for the 16F628).

Double check the quality of the electrical connection from your ICD-S20 to the target. Make sure that the signals are 100% connected and not some kind of half-[spam] connection. That has caused more than its share of programming problems.

Make sure your programming cable is no longer than 6". The "stock" cable that came with my ICD-S20 was 8" but because it had a bad crimp on one of the RJ connectors I replaced it and made it shorter too.

If you have a different family of 16F chip to test, try programming it. If you have another 16F628, especially in a different board, try it too. Try another programmer on your "problem" board. You might have to borrow one for that test.

Rob Young
rwyoung@ieee.org
_________________
Rob Young
The Screw-Up Fairy may just visit you but he has crashed on my couch for the last month!

[M.W.]

Hi Rob,

thank you very much for your ideas. The "bulk erase" solved a little bit of that problem. When I now try to program the PIC wit the Hex-File than the verification is bad.

I found something strange in the Hex-File of the generated code (Compiler Version CCS PCM 3.178).

These are the first lines of the compiled code with CCS:
:1000000000308A00082900000A108A100A118207AD
:1000100049346E3469347434693461346C3469340D
:100020007334693465347234653420344D346F343C

When I program the file to the PIC 16F628A with ICD-S an read it back in a file with the advanced dialog then the following shows up:
:1000000000008A00082900000A108A100A1182077F
:1000100049346E3469347434693461346C3469340D
:100020007334693465347234653420344D346F343C

The two files are all the same but only the bold byte and the checksum is different.

Is there a problem with the compiler version I use?

Best regards
Markus

[kypec]

I think the difference you see: "0030" from compiled source
vs "0000" read from target device is due to ENABLED IN-CIRCUIT
DEBUG FEATURE in the chip -> this feature requires NOP be programmed
at the very first location of ROM memory which is coded as 0x0000
instruction opcode instead of originally compiled instruction which is
something like GOTO or BRA (not sure about it)

hope this little info helps you at least a bit
kypec

[M.W.]

Hi kypec,

thank you for the answer.

How can I DISABLE the "enabled in-circuit debug feature" or is it impossible?
I think it is unsuitable to have a programer (ICD-S) with verification when it is impossible to verify the PIC.

I dont't want to in-circuit debug the sotware. I only want to program with the ICD-S and than verify.

Hopefully
Markus

[kypec]

just make sure your C source doesn't contain something like

[M.W.]

I don't have something like #device ICD=TRUE in my code.

And the code contains NODEBUG.

There must be something else wrong.

No luck for me!!!

[M.W.]

Hallo all,

is there anybody else who can help me with my problem?

Best regards
M.W.

[Haplo]

One obvious thing that no one has brought-up yet: What is the version of the firmware you are running in your ICD? I clearly remember some earlier ICD firmwares had big verification problems, where they reported 0000 for all the memory locations.

[M.W.]

The Version of the firmware is CCS ICDS-20 v01.13. I only get one line in the verification results. The line is

Adress Actual Expected
0000 0000 3000

Thats all. But in the Hex-File there is much more code.

What can that be??

Hopefully
M.W.