Colorado / H3 BCM hacking

[Gatecrasher]

Contemporary full size trucks used the same chip for BCM and climate control, so there may be benefits beyond Colorado and H3.

[kur4o]

The flash process could follow p12 sps writing. Some code is loaded with pointers, each pointer is used for different purpose[write/erase/and so on]. The communication part is contained in the bootblock that never gets erased with some special sequence that jumps to pointers at some specific conditions.

[bbmike]

Also, the data at 0x0 on the F16E looks like 16 bit vector addresses instead of 32-bit addresses or 32-bit jump instructions like the TMS470 has.

Code: Select all

0x00 44 03 
0x02 44 07 
0x04 44 09 
0x06 44 0d 
0x08 44 13 
0x0A 44 17 

It's really weird that they hit on odd-numbered addresses, and those addresses don't fall neatly into the range of the 'full' dump Coly posted, which makes me think there's some kind of memory mapping going on. This onion has a whole lot of layers. And some of them stink.

The 16bit tms370 multiplies jump addresses by 2 by using the stored value for address a1-a16.

[04colyZQ8]

*************************************************************
* FUNCTION
*************************************************************
undefined FUN_08000ed8 ()
assume LRset = 0x0
assume TMode = 0x1
undefined r0:1 <RETURN>
FUN_08000ed8 XREF[6]: 08000f90 (c) , 08001122 (c) ,
08001140 (c) , 08001162 (c) ,
FUN_08000e24:0800134c (c) ,
FUN_08000e24:0800138e (c)
08000ed8 4a 09 ldr r2,[DAT_08000f00 ] = FFFFFC00h
08000eda 78 d1 ldrb r1,[r2,#offset DAT_fffffc03 ]
08000edc 20 fd movs r0,#0xfd
08000ede 40 08 ands r0,r1
08000ee0 70 d0 strb r0,[r2,#offset DAT_fffffc03 ]
08000ee2 46 f7 mov pc,lr



I feel like the code above could be a watch dog or something?


This looks interesting has 6C 40 F1 76 in it..

*************************************************************
* FUNCTION
*************************************************************
undefined FUN_08000e3c ()
assume LRset = 0x0
assume TMode = 0x1
undefined r0:1 <RETURN>
undefined1 Stack[-0x3]:1 local_3 XREF[1]: 08000e56 (W)
undefined1 Stack[-0x4]:1 local_4 XREF[1]: 08000e52 (W)
undefined1 Stack[-0x5]:1 local_5 XREF[1]: 08000e4e (W)
undefined1 Stack[-0x6]:1 local_6 XREF[1]: 08000e4a (W)
undefined1 Stack[-0x7]:1 local_7 XREF[1]: 08000e46 (W)
undefined1 Stack[-0x8]:1 local_8 XREF[2]: 08000e42 (W) ,
08000e66 (*)
FUN_08000e3c XREF[1]: FUN_08000e74:08000e7e (c)
08000e3c b0 82 sub sp,#0x8
08000e42 70 01 strb r1,[r0,#0x0 ]=>local_8
08000e46 70 41 strb r1,[r0,#local_7 ]
08000e4a 70 81 strb r1,[r0,#local_6 ]
08000e4e 70 c1 strb r1,[r0,#local_5 ]
08000e52 71 01 strb r1,[r0,#local_4 ]
08000e56 71 41 strb r1,[r0,#local_3 ]
08000e5a 22 00 movs r2,#0x0
LAB_08000e5c XREF[1]: 08000e6e (j)
08000e5c 2a 00 cmp r2,#0x0
08000e5e d0 02 beq LAB_08000e66
LAB_08000e60 XREF[1]: 08000e64 (j)
08000e60 78 0b ldrb r3,[r1,#0x0 ]=>DAT_00000013
08000e62 09 9b lsrs r3,r3,#0x6
08000e64 d3 fc bcc LAB_08000e60
LAB_08000e66 XREF[1]: 08000e5e (j)
08000e66 5c 13 ldrb r3,[r2,r0]=>local_8
08000e68 75 0b strb r3,[r1,#0x14 ]=>DAT_00000027
08000e6a 32 01 adds r2,#0x1
08000e6e db f5 blt LAB_08000e5c
08000e72 46 f7 mov pc,lr

[04colyZQ8]

[quote="04colyZQ8"]*************************************************************
* FUNCTION
*************************************************************
undefined FUN_08000ed8 ()
/quote]

Nevermind

08000ed8 4a 09 ldr r2,[DAT_08000f00 ] = FFFFFC00h
08000eda 78 d1 ldrb r1,[r2,#offset DAT_fffffc03 ]

This a base for the RTI register FFFFFC00h, so no watch dog but still
Interesting

[04colyZQ8]

What I want to find is what calls this function?

FUNCTION
*************************************************************
undefined FUN_08000e3c ()
assume LRset = 0x0

Because it’s sending a message out via vpw. Or seems
Like it’s pushed to an array in a stack! But what pops it? And pops it into where?

[04colyZQ8]

I believe it’s an asic made for gm by ti. Using a tms370 and j1850 controller and eeprom all in one chip.

Could be and I do believe the dlc is handled internally by the 1850 chip on both Gen bcms! Nice find, but does it come with more pins? The one we have has quite a few?

[04colyZQ8]

The B0 in the utility file is a download to ram instruction that creates the mode 36 message. The 40 is the module ID the next byte is the routine to download from the end of the utility file. Next byte is unused. Then the next byte tells to download and execute or just download. 00 means to just download. The B4 is similar to B0 but is used to download calibrations. I think the AE command just before the first B0 command jumps the program code to the bootloader and waits for the ram downloads then the calibration downloads. The utility file never sends a download with an execute command. From reading the data sheet I would think the ram downloads are downloaded to 0x08000B82. The bootloader must add the 80 onto the address because the mode 36 only use 3 byte addresses.

Great job, and assume contribution! Thank you!!!

@ gatecrasher

matters. When that's done, go to 0x8000b82, and create four address pointers (P key). That'll give you the entry points for the four main functions in this thing.

This was sweet!! And how did you compile up the kernel? Was it how I suggested? Using the utility file
And the log file to pull out the segments and properly put it together?

Thanks for doing that saves me allot of time, not to mention I might screw it up!!

So how’s you discover the entry point? And the pointers? Do we need to do something similar
To correctly disassemble the flash as well?

[bbmike]

I believe it’s an asic made for gm by ti. Using a tms370 and j1850 controller and eeprom all in one chip.

Could be and I do believe the dlc is handled internally by the 1850 chip on both Gen bcms! Nice find, but does it come with more pins? The one we have has quite a few?

They were chips made for manufactures to meet there needs. So they could be made with as many pins as needed to add the extras like the dlc.

[Gatecrasher]

This was sweet!! And how did you compile up the kernel? Was it how I suggested? Using the utility file
And the log file to pull out the segments and properly put it together?

The utility file itself tells you where all the segments go. I had a log, but I only used it to double check my work.

So how’s you discover the entry point? And the pointers? Do we need to do something similar
To correctly disassemble the flash as well?

Educated guess. Four locations right at the top of the file that looked like address pointers turned out to be....address pointers.

The main flash is going to take a lot more work. I'll post my Ghidra archive later today. I've got a lot of the diagnostic stuff fleshed out, but not much else.