GMC Envoy BCM EEPROM

[Yovne]

I'm new to the forum- thought you might be able to help. (hope this is in the right forum).
I want to edit the EEPROM in my BCM (2007 GMC Envoy) but cannot identify the EEPROM type.
It uses a GM/Delphi internal part number 8007829.

eeprom.jpg

Some internet searches suggested it could be an ST M95080 EEPROM, so I tried that selection on my AsProgrammer software, using a CH341 USB programmer.
( I used this software & programmer combination successfully on my instrument cluster to read, edit and write back to the cluster before installing it in my Envoy. That was my first foray into this 'module EEPROM editing' and I made sure the CH341 was set to 5V as recommended by some YouTube posters on editing cluster EEPROMS (including FixedUntilBroken.)

Using the ST M95080 selection, the AsProgrammer seemed to read the BCM EEPROM successfully and gave hex representing the part number of the BCM in ASCII view, in some sort of coding/swapped around groups, and further down, the original VIN number of the donor car. Then the entire set of data was repeated (for redundancy, I supposed).

Now, the problem: When I try to write back to the EEPROM it keeps failing verification. After many attempts and trying options like unlock, erase etc. it still fails and now, when I tried to read it again, the first lines have changed, with some data 'semi-repeated' although only partially, on the following line.
That change is then repeated further down, in the second set of data. I can post an image of that data if it will help identify what is going on.

So my first thing to check is "Am I selecting the correct EEPROM type in the AsProgrammer settings?" Does anyone know the actual EEPROM type used in these GMC Envoy BCM?

[ironduke]

Not much experience myself but what size are you trying to read? Last time I was reading too small a size and it wouldn't write back..

[darkman5001]

Can you upload your original dump? Try reading it as a 95160 or 95040 and see if that works.

[Yovne]

Well, the M95080 I selected showed size 1024 page 32.
I have attached the original dump from AsProgrammer (using the M95080 selection).

I just tried reading as a 95160 and then 95040. Attached also.
Bear in mind that I had already been trying to write as the M95080 and when I read it again after that, the first lines were changed, so the new reads/dumps as 95160 and 95040 are done with the first lines of data already corrupted. I' not sure how to go back t the correct data now unless I know how that first read/dump actually read the EEPROM.

I have never seen a good EEPROM dump from a 2006 Envoy BCM, so I can't compare.

I also attached an image of all three dumps side by side.

allThree.png

You will see that in the original dump as M95080, the first row in ASCII read:
;1876220M 809..
then the repeat began at 0x200

in the latest reads as in 95160 the first row in ASCII stands out like a sore thumb:
.CNBM...!..B.78. so that first line has been corrupted, but the rest seems to me to be OK.

In my original dump, the data seems to end at 0x1FF with a D8 and then the whole thing is identically repeated down to the last byte at 0x3FF which is, again D8.
It sort of seems like this validates the idea that the data is correct in this original but just repeated (maybe deliberately for redundancy).

The recent dump as a 2048 buffer shows the same data (albeit with that first row corrupted) except the last byte at 0x3FF is changed to 30 (likely due to the change of the first row?) and then of course repeated 3 times.

The dump in the 512 buffer is different in that the value 30 ,that was right at the end of the original dump's data, is now in first address and the last addresses are all FF.
If we ignore the corrupted first row, the fact is that 30 is now at the first address and it shifted the subsequent bytes to the right.

I wonder if my original EEPROM data was supposed to be duplicated as I assumed, or if the 512 byte buffer should have been the correct size and that D8 should be at the first address.
In which case it would have read D8 3B 31 38 37 36 32 32 30 etc. and the last rows would be all FF.


So, does this make sense and should I try editing the 512 buffer dump for the original data (D8 etc) then try writing this?

( oh, and does anybody have an original, correct dump of a 2007 Envoy BCM EEPROM for me to compare?)

[antus]

I think the smaller one is correct. GM often use some combination of A5 5A or bytes like that (where the nibbles are 1010 or 0101 in about that position *toward the end* of the *segment*. So I think you have a real chip at 000-1FF and real data at 000-11F or 11E, and the rest is unused space, hence the FFs. I would expect 11F to be more likely, an odd number size would be quite ab-normal.

Try a chip from the same series of flash memory, but with a smaller size, eg 0x200 aka 512bytes. If you are writing off the end of it you may be hitting an error as you run off the end of the chip and that could be your corruption. See if you can write the original file back as 512.

[Yovne]

Yay! Thanks antus. Yes, I took a read as a 95040 (512 size), moved the D8 to the first address and corrected the top row back to the original values, but shifted right of course, due to the D8 being reinserted. So all else was then already shifted right and left the FFs at the bottom. Wrote it successfully like this and read it back as the identical values.

As an interesting test,I set the chip type to the M95080 once more and read it. Same result as my original dump: Started with 3B and put the D8 at the bottom.
So that seems to prove the bad original read, with chip set to a larger size, skipped the first byte D8 then at the end of the real addresses it went back to the start and read the D8 then continued.

Surely that together with the fact that my write and read-back produced the identical values now shows the D8 should have been at 0x00 after all.

I can now edit my VIN into it and write that, and once the weather finally warms up here I can try it in my Envoy to see if I get the added features of the Denali it came from. ( I realise I'll have to do a security relearn and SDM match on the BCM but i have the Tech2Win and VX FD interface, so that should be possible.

I had got a DIC instrument cluster and this matching BCM from a 2007 Denali, back in 2022, but the DIC display died after I tried editing that EEPROM. It took me a few years of intermittent investigating and learning to realise the dead DIC was NOT an electronic fault but a corrupt EEPROM due..... wait for it....to a bad read which put the first byte at the end.
I later figured that the MCU in the cluster must read the EEPROM at boot-up to configure the display type and output and more, so it had not configured it for a DIC display.

It was interesting that while I had that DIC cluster and its matching BCM on my bench harness, the DIC options included "Curb View Assist". But then I put the cluster into my Envoy and recently added a steering wheel with switches and I see that option is not there now. So clearly the BCM's RPO options need to be there to send that data to the IPC.
Anyway, off topic, so thanks again for the guidance I needed. I'm enjoying reading that thread about BCM disassembly - well done and keep it up.

[Yovne]

More info for anyone interested:
I just got brave enough to remove my running Envoy's BCM and de-solder it's EEPROM and dump its contents.
Attached (2007 Envoy SLE; basic, no fancy options).

My2007SLEbcmEEPROMdump.bin

I am now trying to compare the two EEPROM files and figure out if just writing this one into my spare Denali BCM EEPROM will work, or if there is something extra in the Denali BCM EEPROM data that is required so that the Denali BCM will give me all the feature options of the Denali.

At least when I re-soldered the EEPROM into my BCM and refitted it, my car started fine. (Phew).

[antus]

sometimes you can read or write chips like these with a tsop8 clip over the top of them. you usually need to power the bcm but because its an i2c bus device you can usually sit on the bus and access it. especially for write though you might need to lift a pin or something. You can read the data sheet to understand what may or may not be a problem if you have no luck. Might save you the de-solder, next time. For the BCM I'd just try it. Chances are it will work.

[Yovne]

Ah - thanks, antus. I'll try that next time.
I see what you mean about the write. If I even cut the trace near the chip I could then write and then bridge the trace again with solder.
Good hint.

[Yovne]

More I've learned.
I swapped in the Denali BCM to my SLE Envoy and did the 30 minute theft deterrent relearn then the SDM program into the BCM.
Car starts ok. Options though:
I now see new options in the DIC: Easy Exit Seat, Seat Recall and Alarm Warning. No Curb View Assist/Tilt Mirror! All of those options were in the DIC when it was powered up on the bench alone, before I installed it into my Envoy.
So Curb View/Tilt Mirror must require the Driver Door Module (DDM) or Passenger Door Module (PDM) programmed for mirror memory before the option shows up.

The IPC must communicate with the BCM and Door modules to see what is available then configure the software in the DIC (& probably the BCM); perhaps by setting variables that are then checked when a request is made for a feature.
I'm going to try and get the DDM and PDM from a higher spec Envoy in the junk yard and see what happens when they are plugged in.

Maybe this might help someone to figure out how these options are programmed and enabled.