To quote Kid Rock, it was 1989, my thoughts were short, my hair was long. Perhaps the guys that engineered this thing weren't exactly the top of the class.Originally Posted by steveo
Can any of the uveprom based ECMs be dumped thusly?
To quote Kid Rock, it was 1989, my thoughts were short, my hair was long. Perhaps the guys that engineered this thing weren't exactly the top of the class.
Can any of the uveprom based ECMs be dumped thusly?
Yeah, I had to re-read what he typed a few times before I realized my mistake. I was reading it in the context of our current discussion, which was regarding ALDL comms via the CCM. But he wasn't talking about that at all, he was talking about the PCM independent of the CCM, a completely different unrelated topic.
My bad. Anyway, the local electronics shop didn't have the components I needed......so I ended up buying a huge kit that had them plus a bunch of other random shit I can keep in my lab for a rainy day. Sucks paying $16 more than intended, but at least I'm good to go. Should have a new interface ready by tomorrow.
EDIT: As to the memory dump, there are only two address spaces that are rejected by the memory dump routines (both Mode 2 and Mode 3). These are:
$1000~$103F: CPU registers. These are restricted because attempting to access them via ALDL could lead to the CPU crashing.
VATS: All VATS memory locations are restricted and will return 00 unless the correct key for the vehicle is inserted and the ignition is set to run. My dumps were all done with the key in and the ignition in run, so these locations should be populated. My datasheet doesn't specify the memory locations, but it should be fairly trivial to find them by just taking a dump with the key in and ignition on, then immediately taking another with the VATS connector disconnected. I can do that later.
Last edited by NomakeWan; 09-25-2021 at 06:20 AM.
1990 Corvette (Manual)
1994 Corvette (Automatic)
1995 Corvette (Manual)
kur4o you were right on the money dude!Code:TX+F15605B4 RX+F1570500B3 TX+F15605B4 RX+F15705AA09
Time to void a warranty.
That`s pretty awesome.
Now it is time to wipe out some eeproms.
ohhhhh snapF1 57 05 AA
1990 Corvette (Manual)
1994 Corvette (Automatic)
1995 Corvette (Manual)
We'll see (erasing eeproms). Before I get too far along I wanted to share a picture of the reman pin. But my lawyer (who also happens to be my wife) has advised me to proceed with caution. So you're not going to get lead right to the pot o' gold.
Spoiler alert, it's a deceptive aspect you won't be able to find with passive forensics.
reman-pin.jpg
I'll give one more hint - it is floating, but it's not floating at 12 volts.
Here's what I've learned. While mode 5 is active 02 requests stop working, and mode 5 seems to timeout after about 1 second. Mode 6 requests inside that timeframe (and outside it) give no reply. I've tried uploading nop commands as well as plain ascii to the $00 scratchpad area and to the last few digits of the (ram) VIN with no apparent success.
I feel like I've only conquered 5% of the problem and it was completely non-trivial. I'm open to any suggestions, especially protocol focused interrogation. I have no interest in profiting from this endeavor, but I will stop at nothing until I can minimally change a few bytes of ram.
Last edited by spfautsch; 09-26-2021 at 02:19 AM.
Finally cracked the m5 loop.
It is some loop that expire if there is no activity on the bus. When that happen the pcm is crasher and reset.
Before that happen memory from 6000-600b3 is cleared. I suppose that is the target ram for uploading code.
When in mode5 only mode5 and mode6 messages can be sent.
Mode 5 will just reply with AA and keep the bus alive.
Mode6 is to upload and execute some code.
It needs to be in a format like this
06 XX XX [YYYYYYYYYYYYYY] chks
xxxx= data where the upload will be stored and executed.
YYYY= upload code. No need to specify length, it is taken automatically, also there is no checksum verification, so if the message is corrupt the pcm will likely crash.
For now a snigle upload can be worked fairly easy. A multi message upload will need some tweaking as the execute needs to return to m5 loop.{i think EE upload apporach will work without issue- just some tweaking of the addresses].
Now someone needs to write some code to program the eerpom with custom data. i am sure gm have something on t1 but where to get is beyond me.
great work, everyone.
dumb question, do we know for sure what processor this thing has ?
and just to confirm this is the processor's onboard eeprom we're talking about, right?
I tried a short routine earlier and it seems like ending the mode 6 message with a RTS instruction (0x39) gets back to the mode 5 loop. At least it was still replying to the mode 5 request. The problem I see is that there doesn't appear to be a way to gracefully exit mode 5 to see if my routine did what it was supposed to (write 0x30 to the last digit of the vin in ram).
Maybe the last instruction to upload should be a jump to the eeprom compare / store routine?Code:TX+F15605B4 RX+F15705AA09 TX+F15605B4 RX+F15705AA09 TX+F15E0660008630B771FF3935 RX+NO REPLY TX+F15605B4 RX+F15705AA09 TX+F15605B4 RX+F15705AA09 TX+F15605B4 RX+F15705AA09 TX+F1570500B3 RX+NO REPLY
I believe it is. Looking at the 68hc11e datasheet, the smaller eeprom versions had 512 bytes starting at $b600 which aligns with where the odometer triplet starts.
Let me correct this one. It appears that mode 5 will stay active without keeping the bus active.
What I've found is that if I upload a routine that doesn't end with an RTS instruction, the processor resets. Also sending anything other than 05 and 06 commands while in mode 5 resets the processor as kur4o noted.
I'm pretty sure what I'm sending is working, but have no way to know other than the fact that mode 5 stays active as long as I don't send anything other than 05 or 06. I know this because the reman pin only needs to be shorted momentarily and responses to 05 remain AA until it resets whether the pin is shorted or not. I'd try turning on an output like the courtesy lamp pin, but I think the processor has to send commands over spi to handle this and that's way outside of my machine language skillset.
I'm tempted to try my hand at disassembly, but thus far that's never ended well. Otherwise I'm at your mercy guys - any ideas on the entry point for the eeprom routine?
Last edited by spfautsch; 09-30-2021 at 07:29 PM.
Found 3 subroutine that write data to eeprom, first one is in the main code[I guess it updates eeprom on some regular basis, OCI1 triggered].
The other 2 are very intersting. They should be triggered when mode 2 and mode 3 is sent to ccm.
However when mode 2 and mode3 is requested it is handled by totally different procedure and the code will never run with these 2 eeprom write subroutines. They are really F_d up, and hard to guess what they do. I wonder if you enable mode 5 and make a jump to this piece of code what will happen. Maybe some reseting of the eeprom area[blank out].
I will keep digging.
Edit: the pin needs to be shorted only when you enter mode5. After that there is no need to be kept. In the loop aa response comes from different place.
It just indicates OK[ccm unlocked]
Last edited by kur4o; 09-26-2021 at 08:05 PM.
In the mean time I've been reading the 6811 datasheet and I'm contemplating writing directly to the eeprom. They give examples in assembler, I just need to translate to the right instructions / params.
Edit: You can abandon your disassembly efforts as it relates to the eeprom routines, we can write to eeprom.
Note - I stupidly used 02 reads instead of 03. I edited the responses for brevity so the checksums are wrong.
Nevertheless, the last digit of the vin is now $30 (0) instead of $39 (9) even after removing power for several minutes. On to bigger and better things.Code:TX+F15802B7FFFF RX+F19602393D TX+F15605B4 RX+F15705AA09 TX+F15605B4 RX+F15705AA09 TX+F1670660008630C602F7103BB7B7FFC603F7103B0A RX+NO REPLY TX+F15B0660007F103B84 RX+NO REPLY TX+F15802B7FFFF RX+F196023046
Last edited by spfautsch; 09-26-2021 at 10:24 PM.
It is not that straightforward as writing to ram than it looks. There are some registers that`s need to be set, and the timing is critical.
We can borrow some code form ee, where it updates the vin.
See my edit to the previous post. When I'm done celebrating I'll show my work in detail.
Edit: So I basically just copied the example from page 60 of the datasheet. I found it on some some electronics reseller's site here: 68hc11e datasheet but I'm sure there are other / better / different copies floating around.
Bear in mind that I was changing a #$39 byte to #$30. If any 0 bits needed to change to 1s I would have had to first erase the byte before writing.
Obviously working on multiple bytes more logic will need to be involved - i.e. waiting 10ms after enabling programming voltage, etc.Code:0660008630c602f7103bb7b7ffc603f7103b mode 6 payload breakdown: 8630 ldaa #$30 load $30 into register a c602 ldab #$02 load $02 into register b f7103b stab $103b store register b contents to address $103b - set EELAT bit - enables write mode to eeprom b7b7ff staa $b7ff store register a contents to address $b7ff (last byte of eeprom) c603 ldab #$03 load $03 into register b f7103b stab $103b store register b contents to address $103b - set EPGM bit - enables programming voltage # note - example jumps to a delay 10 ms routine, I simply sent the next command as quickly as possible after the previous 06 payload 0660007f103b mode 6 payload breakdown: 7f103b clr $103b clear EELAT and EPGM bits and return to read mode
Last edited by spfautsch; 09-26-2021 at 11:45 PM.
Posting Permissions
Reply With Quote
Bookmarks