07-2013 GM BCM

[ironduke]

Not sure if anyone is interested, but I was down a rabbit hole looking for something to read the mb91f011 chip in the bcm and found a couple reads.. Haven't read mine, but it looks like I could patch one together for ghidra?

I'm not sure if the reads are complete, I need to add 0x500000 in front of the data in the read to match the bins we've been working with, but there is some extra data starting at 0xf4000 that is not included in the OS segment listings. Think this could be the boot segment.

25826125 TN23240-0220 - OPEL ANTARA 2007 .rar

(495.49 KiB) Downloaded 101 times

eeprom read of the bcm is below also.. This isn't as a big deal..

15948439 TN232400-0114 - OPEL ANTARA 2007.rar

(569 Bytes) Downloaded 102 times

[ironduke]

Well with all the talk about mode 23 with other ecu's I went back to my bench BCM and gave it a try.. Below is an actual read of the BCM using mode 23.. Matches byte for byte with the bin I made up from all the sps cache segments except for some code 0xF4000-0xF8000. I'm assuming this is boot??
Checksum is found at 0x80(2 bytes) and is rest of that segment.

BCM.Bench.read.bin

(1023.99 KiB) Downloaded 103 times

Some notes.. I had trouble getting ISO15765 to work correctly with padding an extra byte in a 6 byte message.. I've done it in the past but that might have been because the messages were at least 7 bytes of data..
This message 00 00 02 41 23 80 00 00 00 2C I had hoped would be sent as 00 00 02 41 06 23 80 00 00 00 2C AA with the length byte added for me and the message padded at the end with the AA or 00 but it didn't. It includes the length but didn't pad the end.

I couldn't get patcher to do it for me either. if I add an extra byte at the end then mode 23 fails due ti incorrect formatting.
I thought that ISO15765_PAD_VALUE = 1 would do the trick but it doesn't seem to be working.. Anyone seen this problem or know what I am doing wrong?

I did get it to work but only with straight CAN and doing all the work/filtering/sending continue message with multiline responses,etc.. I can do it, I do it a lot but thought I would try to use ISO15765 since mode 23 in itself seems real damn slow, lol..

[kur4o]

YOu need to use ISO15765_FRAME_PAD set on txflags, when message is sent.

Here is some examples.
in script

set:txflags:ISO15765_FRAME_PAD
00 00 02 41 23 80 00 00 00 2C
clear:txflags:ISO15765_FRAME_PAD

It migth be possible to make it global by setting the tx flag on flow control filters, but didn`t test it much.

Did you manage to find the max length for mode23 on the bcm, Some are maxxed at $10, some at $80, maybe increase till it is found.

We got some parse log to bin in action menu, but not sure if mode23 CAN is covered. If not working send me a full log dump.

[gmtech825]

If I remember correctly the max read size was $2f for my 2012 bcm

[ironduke]

For me 0x2c was max read size, errored out with anything higher. Some sections of the read failed to return 0x2c size though and made my code error out, so I manually reread those pieces and pasted them in from a log.. will need some work to get this automated. They were in the OS section near the end.
Kurdo, thanks for the into on frame pad and to flag info. I swore I’ve done it before but I’m real bad at notes. Figure I’ll remember things but I never do..

Edited.. I got ISO15765 working with logger.. With that I am getting replies back to ox30 in length.. I do think it depends on where you are reading..

[kur4o]

There is some locations that crash the cpu when read. They are 8-16 bytes here and there. Some testing will be needed to map them and skip the reading with changing request size. A simple fill of FFs for skipped ranges will bring up a valid bin.

[ironduke]

There is some locations that crash the cpu when read. They are 8-16 bytes here and there. Some testing will be needed to map them and skip the reading with changing request size. A simple fill of FFs for skipped ranges will bring up a valid bin.

Where I was reading there was data there in the OS segment, not sure if it would be a valid bin filling with ff's?? In any case I was able to get the data with varying lengths of reads and starting location of reads.. I will make notes as I try again and if it's repeatable with other BCM's then we'll be good to go.. I was more after the boot segment since others had expressed an interest in it.. Now being able to read/write the eeprom via obd2 would be super fantastic, lol.. baby steps..

Edited.. I just read the entire BCM again, it takes about an hour so it's not a quick read. I found out when a particular more 23 request fails if I simply tried a second time it went thru fine. I also adjusted the last read so it didn't overshoot the flash size. Read the whole thing without erroring out and having to manually fix any pieces of it.. Nice..

Now what do I do with it? lmao... I always thought mode 23 would be more locked down.. would it be worthwhile to try different address ranges other than the 0x80000-0x100000?? Any chance I could trigger it to read the eeprom??

[kur4o]

You can test different location, ram, eeprom, as long it can be requested, there is a chance bcm will send it. If you increase timings maybe the errors will disappear. Sometimes eeprom can be found copied in Ram.

[Tazzi]

Now what do I do with it?

Cloning these BCMs has been something Im sure many workshops wish existed!

[ironduke]

I had a 15 Silverado dropped off for some other things, checked out mode 23 with that BCM. Flash is laid out differently but I had some cal files to check out the OS and figure it out.. Below is what I believe is complete flash for a 2015 Silverado. 0x000000-0x200000. I built the file by hand with cal files and then compared after the read and it looks good..

2015.Silverado BCM_2023.04.30_06-39.PM.7z

(491.79 KiB) Downloaded 116 times

Tazzi, I am making very small baby steps, lol.. But I will definitely keep the idea of cloning these BCM's in my head..