Device ID not matching ID that CCSLOAD is reading

[SvenBraun]

I was trying to find a solution to this by searching, but couldn't find the resources I needed, so I made an account to ask this question.

Main question: What can impact the reading of the Device ID in the Diagnostics of CCSLOAD?

Lead-up story:
I'm working with an evaluation board from Microchip, and I was attempting to load a new program, compiled using CCS.

During download, my ICD [ICD-U64] would change from red to green, signifying that it was ready to download. When it was starting the download process, it would abruptly stop, giving me 'Error: Download failed'.

I made modifications, double-checking pin connections, syntax, and fuses, but each time I would get the same message. I asked a group mate, who had loaded a program onto that chip before, if I could use his computer to attempt it. Even his computer would not download to the chip, even after he had done so previously.

I opened up CCSLOAD, and attempted loading it via the standalone CCSLOAD. No dice, but it led me to discover that the Device ID the diagnostics was reading did not match up to the chip I was using.

I can't remember what the exact value was (I don't have the chip with me right now), but it was something to the effect of:

Read: [...]001XXXX
Expected: [...]011XXXX

This device ID, while still in the same family, does not match up to the PIC chip I'm using.

My working theories are:
* My group mate somehow messed up during programming
* I somehow messed up during programming
* CCS is messing up
* The chip is somehow defective

After talking to my group mate, he swears he wouldn't have done anything that could mess up the device ID. I don't believe I have done anything to mess up the device ID. So I'm turning to CCS to see if there might be an issue with the compiler.

Is there a possibility that there could be a transmit delay with CCSLOAD? Has this issue happened to anyone else?


Compiler version: 4.135
CCSLOAD software version: 4.035
Hardware: Rev 0

[asmboy]

[SvenBraun]

My test program is written for PIC18F87J72.

I'm attempting to program it as a PIC18F87J72.

My PIC evaluation board is listed, in both the order and physical markings on the uC, as a PIC18F87J72.

The Device ID that is coming up during Diagnostics is PIC18F67J90. From what I've read in the datasheets, they appear to be related, at least through basic architecture (the datasheet lumps the 87J72 with about 15 other PIC models, including the 67J90).

[asmboy]

this board? or some other ?

http://www.microchip.com/DevelopmentTools/ProductDetails.aspx?PartNO=adm00333

and when you READ the top Of the chip
what does IT say ??

if it really is the 87j72 -then you need to contact CCS support and get them on the case.
--------------------------------
but fundamentally they are NOT the same family - and come on - one is 80 pin the other is 64 pin and have they many differences in supported hardware features too.
NOT the same family in terms of sharing a data sheet at all !!
You need to better read the data sheets.

[Ttelmah]

Seriously, the first thing to do is update CCSLOAD. 4.035!....
Current version is 5.022.

This may well be the whole problem, with the 87J92, actually postdating, or being 'brand new' in your software.

Then the device ID, is 'hard programmed'. Actually built into the silicon, so cannot be changed by any normal process. You are missing one 'x' in the value you type in your post, the correct ID is:

011x xxxx

If you are getting
001x xxxx

You are seeing a 67J90, 87J11, 87J50, 64J11, 64J90, or 65J10.

You can get ID problems, if the connection cable is too long.

I really would suspect the whole problem is that your software is too old.

[SvenBraun]

[PCM programmer]

[Ttelmah]

I'd also add, that later processors seem more and more critical of longer cables. Old chips will program with cables that will not work on newer chips. 6' sounds much too long.

[SvenBraun]

[newguy]

[SvenBraun]

I was able to find our technician and cut down an RJ11 cable to about 100mm (about half the size of the last wire). New connectors attached, and all pins were verified with a DVM.

I closed out of CCSLOAD, unplugged the board. Plugged the board in, relaunched CCSLOAD. I am still getting the following:

R: 0101 0000 001X XXXX
E: 0101 0000 011X XXXX

I'm not sure what to do beyond this point, outside of contacting CCS Support and/or Microchip.

[Ttelmah]

I think you need to contact MicroChip.

1010, is quite early for these chips. Seems unlikely that any genuine supplier would be holding chips 6 years old. Worrying.
They should be able to identify from the D1K code what this.

502X, would be correct for an 86J72, rather than an 87J72.

There do seem to be a suspicious number of Chinese companies listing that board.

[SvenBraun]

I have went ahead and filed a case with Microchip about the issue.

Further information, if it's relevant:

The box it came in is from Microchip, with a label saying it was inspected 7/25/13.

The board was made in China, with a barcode with the letters CN underneath (I'm guessing to signify the country of origin in their system).

The pack list correctly lists the products, but the Check-off column is unmarked.

I will post back as this issue (hopefully) concludes.

[temtronic]

Seems there's 3 areas that could be a problem..
1) the programmer is not genuine
2) CCSLOAD has a bug
3) the PIC you're using isn't genuine.

If the PIC was bought from say Digikey, odds are is really is genuine, but from a small 3rd party place, who really knows ?
I'd ask Microchip nicely to supply a couple of samples of that PIC. They have always been accomodating to me in the past.

Jay
BTW ther's a 3rd party place selling PICKit3 'knockoffs' here for 1/2 of uCs price !

[asmboy]

Anecdote: I have a local client with a product that uses 18f26k22 in DIP package. I produced an updated version of the firmware for them and said client asked me to program a few chips THEY had purchased -- with the new code. my programmer rejected every one as being wrong device type. \

the type being reported ? 0xFFFF

on close inspection the dip tops were NOT laser etched - but rather printed with a grey paint instead. ( i could scrape it off with the edge of a razor blade )

purest JUNK - -- client says their purchasing agent found these on Alibaba and had 100 pieces air shipped from China for $1 each........

until this experience i could not believe that such a fraud was even possible - but I am smarter now - and so is the client.