Help a new guy out. Kind of long. 16c55 chip.

[mouser123]

First of all, I'm not very knowledgable with microcontrollers but have a couple of questions as to why something isnt working. If you respond, you'll need to talk to me like I"m in the first grade for microcontrollers.

I have whats called a service indicator board out of a mid 1980's BMW car. The SI board sits inside the cars instrument cluster and attaches to the speedo and the tach as well as the temp and fuel gauges. This board causes 6 LED's to illuminate on the dash of the car. As the car is driven, one by one these lights will go out and once all the lights are out, a red LED comes on and this is to tell you that the car needs to be serviced. Depending on how hard the car is driven, it might be 15,000 miles before the lights all go out.

At the heart of this board is a PIC16c55 and it tracks things such as rpm, miles driven, engine temp and uses all of this to determine when to start turning the little service LEDs off so the owner will know when to service the car. The original versions of these boards used a different chip that needed 2 NiCd batteries in order to maintain its memory. These batts leaked after awhile and would destroy the service indicators circuit board. Some one designed a service board with a 16c55 that doesnt need batts for memory so owners of these cars no longer had to worry about batt acid leaking inside their instrument clusters.

I wanted to make one of these myself so I took a 16c55 off of one of these circuit boards, copied its programming using a USB Programmer and then wrote the programming to a brand new, blank 16c55. I then soldered the newly programmed chip onto another, exact copy of the original service indicator board and installed it into the car. Problem is, the service indicator lights did not light up like they are supposed to. The board works just like it should except the LED lights that the 16c55 controls.

I checked all connections, and while I'm not used to doing SMD work, all conenctions are good with no shorts between the 28 pins. I noticed what appears to be a place for a resistor. It looks as though a resistor was added to the board then removed. This missing component goes directly to pin 28 which I think is MCLR/VPP. Master Clear and Programming ? I think.

I'm wondering if a resistor or something else, needs to be added to this empty footprint and then removed once a process has been done in order to get the 16c55 to start working progperly. I'm wondering if thats why my newly programmed chip didnt work. Does this sound right to anyone ?? Does anyone know what I'm trying to get at here ?? My knowledge is very limited on this stuff as you can tell.

Here's some pics of the SI board. If you'll notice just above the 16c55, there is a resistor mounted horizontally and directly under that is a footprint that has had something installed there then removed. As mentioned, the circuit with the missing component runs to pin 28 (MCLR/VPP ? ) and then also goes to the 8 pin component on the right side and also the 2 capacitors on the lower left side of the board.


Does anyone know if I might need to install a resistor or something else temporarily in that footprint before the 16C55 will start working ?? Or what else might be causing the chip to not work correctly. I copied a known working 16c55 and programmed its data onto a new, blank 16c55 but maybe its not that easy ??

If anyone can help me out here I'd appreciate it. Thanks

 

[betwixt]

I can see two problems straight away:

1. The original PIC is almost certainly code protected. It doesn't stop you reading it but the data you get is scrambled and will not work when copied to a new device.

2. The 16C55 has no EEPROM inside it, the 8-pin chip will be an external memory to hold data when the power is off (flat battery or when the voltage drops as the car starts). It looks to be a 24LC04 but the picture isn't clear. It almost certainly contains other information necessary for the board to work. The good news is this chip IS copyable so duplicate it's contents into the new board.

Vrian.

 

[mouser123]

I can see two problems straight away:

1. The original PIC is almost certainly code protected. It doesn't stop you reading it but the data you get is scrambled and will not work when copied to a new device.

2. The 16C55 has no EEPROM inside it, the 8-pin chip will be an external memory to hold data when the power is off (flat battery or when the voltage drops as the car starts). It looks to be a 24LC04 but the picture isn't clear. It almost certainly contains other information necessary for the board to work. The good news is this chip IS copyable so duplicate it's contents into the new board.

Vrian.

Ok Vrian, thanks for taking the time to answer. How can I tell if the data I read from the 16c55 is copy protected ?? Anyway to do that ?? I figured if it was gibberish, the new 16c55 wouldnt have accepted the program.

Actually its a 24LC01B. The board that I installed the newly programmed 16c55 onto already had a programmed 24LC01B on it so I thought it would just pick up and start working with the new 16c that I installed. But maybe thats more evidence that the 16C was fed gibberish ???

I'd like to verify that it is copy protected before I give up. If you know how to do that, I'd appreciate it.

 

[betwixt]

Unfortunately, a code protected PIC of that type will still read what looks like valid data back but is in fact garbage. It's made by XORing the high and low halves of data in each address which gives a consistent but irreversible version of the correct data so it can still be verified by the programmer. If you read the garbage and program it in another PIC it will look the same but not function.

Some programming hardware can read the protection bit in the CONFIG register to tell you if it's protected. Unfortunately, the code protection is a one way process, you can't un-set the protection without erasing the whole IC. There are companies that claim they can recover protected code but use them at your own risk, they are expensive and probably unreliable.

If all else fails, send me a copy of the code from the PIC and I'll reverse enginerer some of it to see if it looks like realistic program. There are some characteristic features of PIC code that would tell me if it would do something sensible when powered up. You can get hold of me via my web site which you will find by clicking on my user name on the left of this window. I've disabled private messaging because of misuse.

Brian.

 

[mouser123]

Unfortunately, a code protected PIC of that type will still read what looks like valid data back but is in fact garbage. It's made by XORing the high and low halves of data in each address which gives a consistent but irreversible version of the correct data so it can still be verified by the programmer. If you read the garbage and program it in another PIC it will look the same but not function.

Some programming hardware can read the protection bit in the CONFIG register to tell you if it's protected. Unfortunately, the code protection is a one way process, you can't un-set the protection without erasing the whole IC. There are companies that claim they can recover protected code but use them at your own risk, they are expensive and probably unreliable.

If all else fails, send me a copy of the code from the PIC and I'll reverse enginerer some of it to see if it looks like realistic program. There are some characteristic features of PIC code that would tell me if it would do something sensible when powered up. You can get hold of me via my web site which you will find by clicking on my user name on the left of this window. I've disabled private messaging because of misuse.

Brian.

Brian, I just sent you an email thru Edaboard. I was wanting to know how to attach a copy of the BIN file i saved from the 16c55 I have. However I see how you do it now. Funny thing is, I can't attach it because the upload manager says its an Invalid File.

I read the chip again and saved the data to my hard drive but when I try to attach it, it just says invalid file and it wont attach so I'm not sure what to do. Maybe that's why the new chip wont work because I really didnt copy anything to it from the master chip. The USB Programmer says I read, copied and saved Data but maybe data thats not worth a flip. I can send you the chip if you have a quick, easy way to read it.

Thanks again for the help.
DAVID

 

[allenf]

I would say that from the pic the short between pins 4(gnd) and 5???? is not a good start the missing resistori IMHO would be a 10k job (lookslike the other one is a 470r) now depending onwhere that missing pad goes to depends whether that chipis going to wake up. If mclr has 0 on it thenif the chip is cofigured thus then it wont run . Try soldering a 10k in there and test it

You have nothing to lose everythig to gain.
Failing that a beemer scrappy would probably have one in for a drink

 

[poorchava]

Code protection is one thing, not to mention that this particular pic is OTP. Worse tthan that - most of semiconductor companies offer Mask-ROM versions of products. This means that program is embedded directly into silicon die. This is of course very expensive, but nevertheless cost-effective at very high quantity and some companies (not only automotive, but other industries too) use them. Mask-ROM is also much more robust against various mishaps than any of otp/flash/eprom/eeprom memories

 

[mouser123]

I would say that from the pic the short between pins 4(gnd) and 5???? is not a good start the missing resistori IMHO would be a 10k job (lookslike the other one is a 470r) now depending onwhere that missing pad goes to depends whether that chipis going to wake up. If mclr has 0 on it thenif the chip is cofigured thus then it wont run . Try soldering a 10k in there and test it

You have nothing to lose everythig to gain.
Failing that a beemer scrappy would probably have one in for a drink

Thanks for the response Allen. I checked continuity across the pins to make sure I didnt short any together and they all checked OK. My soldering gun tip was a little wider than I would have liked so I was afraid of shorting them but I havent. Pins 4 and 5 are very close together though.

I'll try a 10K in the empty spot and see what happens. I've got nothing to lose you know.

---------- Post added at 17:09 ---------- Previous post was at 16:57 ----------

Code protection is one thing, not to mention that this particular pic is OTP. Worse tthan that - most of semiconductor companies offer Mask-ROM versions of products. This means that program is embedded directly into silicon die. This is of course very expensive, but nevertheless cost-effective at very high quantity and some companies (not only automotive, but other industries too) use them. Mask-ROM is also much more robust against various mishaps than any of otp/flash/eprom/eeprom memories

Ok, I didnt know the program could be directly embedded. This is getting to be more trouble than I thought it would be. Thanks for the response.