GM 16216588 - Hacking

American Delco GM ECUs and PCMs, ALDL, OBD 1.5.
User avatar
quadstar87
Posts: 86
Joined: Wed Dec 02, 2015 4:13 am

Re: GM 16216588 - Hacking

Post by quadstar87 »

Well, I've been able to perfectly flash the first 64k using the Intel flash utilities and verify the output off the chip. Still poking at modifying that EXE to see if I can get it to flash the full 128k without buying a new chip programmer.
ejukated wrote:Just curious, what temp is the plate and why is it required
I'll have to have him dig up the notes to see where it was set. Idea is to get the ambient temp of the board up so you don't have to turn the hot air up as much and risk frying the chip or other things in the vicinity.
User avatar
quadstar87
Posts: 86
Joined: Wed Dec 02, 2015 4:13 am

Re: GM 16216588 - Hacking

Post by quadstar87 »

I've been off track for awhile but my real chip programmer comes tomorrow. I got a Willem V6.0 board so should finally be able to restore some PCMs and work on the flash process more.

I'll update as it comes along!
User avatar
antus
Site Admin
Posts: 8238
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: GM 16216588 - Hacking

Post by antus »

Cool. Out of interested, what is a Willem V6.0?
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
User avatar
quadstar87
Posts: 86
Joined: Wed Dec 02, 2015 4:13 am

Re: GM 16216588 - Hacking

Post by quadstar87 »

antus wrote:Cool. Out of interested, what is a Willem V6.0?
This is the Willem USB/LPT flash board. It seems to be working flawlessly and was very easy to get setup. Should have bought this back when I got the Moates Burner instead...because it does almost any chip setup

However, even after successfully writing the 28F010's and verifying their content, the PCM's are NOT booting up. Getting late so i'll have to hack more tomorrow and see what's up. I wasn't expecting this to happen :wall:
IMAG3357_zpsllgurssc.jpg
IMAG3357_zpsllgurssc.jpg (268.82 KiB) Viewed 7369 times
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: GM 16216588 - Hacking

Post by Tazzi »

quadstar87 wrote: This is the Willem USB/LPT flash board. It seems to be working flawlessly and was very easy to get setup. Should have bought this back when I got the Moates Burner instead...because it does almost any chip setup

However, even after successfully writing the 28F010's and verifying their content, the PCM's are NOT booting up. Getting late so i'll have to hack more tomorrow and see what's up. I wasn't expecting this to happen :wall:
Not happy campers aye.

Are you trying to flash the original bins back in? There were verified to be complete and not corrupt? Checksum checks ect?
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
quadstar87
Posts: 86
Joined: Wed Dec 02, 2015 4:13 am

Re: GM 16216588 - Hacking

Post by quadstar87 »

Tazzi wrote:
quadstar87 wrote: This is the Willem USB/LPT flash board. It seems to be working flawlessly and was very easy to get setup. Should have bought this back when I got the Moates Burner instead...because it does almost any chip setup

However, even after successfully writing the 28F010's and verifying their content, the PCM's are NOT booting up. Getting late so i'll have to hack more tomorrow and see what's up. I wasn't expecting this to happen :wall:
Not happy campers aye.

Are you trying to flash the original bins back in? There were verified to be complete and not corrupt? Checksum checks ect?
I'm flashing the original bin's that are scrambled and pass our checksum verification, yes. I'll try one with the Mask ID set to $AA since I know what bits to change for that now. On the good PCM's that I haven't messed with yet, the CEL flashes off then back on quick during boot up to show it's working but the chipped one's wont respond like that. They are either stuck in some state that isn't trying to load the code or something is funky with the chips.
User avatar
quadstar87
Posts: 86
Joined: Wed Dec 02, 2015 4:13 am

Re: GM 16216588 - Hacking

Post by quadstar87 »

So it's looking like the EEPROM is hosed on the processor. I need to shimmy the correct data back so they know how to boot up. Embarking on some new territory again :?
User avatar
antus
Site Admin
Posts: 8238
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: GM 16216588 - Hacking

Post by antus »

Im not sure that would be your problem. There would be checksum tests and I would not expect invalid data there to stop it booting. Also the eeprom is on the processor so once the flashed chip is installed i would expect the original eeprom to map over the top of the flash and the original data to be present.

If you dont have data in the 10000 to 17fff range i would try copying 0-7fff in to that space. Although I think you have proven that is not how the chip was originally populated.

I would also install the chip and test continuity from the physical chip pins through to the cpu pins and power supply. Has this pcm been know to work with your socket installed with an original chip (hardware validation)?
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
User avatar
quadstar87
Posts: 86
Joined: Wed Dec 02, 2015 4:13 am

Re: GM 16216588 - Hacking

Post by quadstar87 »

antus wrote:Im not sure that would be your problem. There would be checksum tests and I would not expect invalid data there to stop it booting. Also the eeprom is on the processor so once the flashed chip is installed i would expect the original eeprom to map over the top of the flash and the original data to be present.

If you dont have data in the 10000 to 17fff range i would try copying 0-7fff in to that space. Although I think you have proven that is not how the chip was originally populated.

I would also install the chip and test continuity from the physical chip pins through to the cpu pins and power supply. Has this pcm been know to work with your socket installed with an original chip (hardware validation)?
I tried copying into 10000 to 17fff but no dice. I'll double check all the solder points tomorrow though. Unfortunately I didn't socket any of the working PCM's, only the ones I had issues with. I figured we'd ruin the chips with heat anyway but that was a mistake because they are fine. Worst case yea I'll have to pull one of the good ones and read it with the correct setup now that I have it.
User avatar
antus
Site Admin
Posts: 8238
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: GM 16216588 - Hacking

Post by antus »

I should also add not just the continuity, look for and test for shorts between neighbouring pins too. Some perhaps should be connected but without the chip installed certainly check for no shorts between data and address pins. Also check the power supply to the flash chip with the chip installed, make sure the 5v supply isnt being pulled down to 0 from a short. I reckon this sounds more like a hardware fault. From what we know and having read initial chips and being able to verify checksums I reckon the images check out.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
Post Reply