You can clear the vin by sending this to can id 252 on HSCAN
0x07, 0xAE, 0x2a, 0x80 = this is the VIN Clear Command
and
0x07, 0xAE, 0xFE, 0x80 = this is clear DTCs
1 Like
Why do you use 0x07 here when it seems it should be 0x03? In your examples you have exactly three payload bytes: 0xAE (which is GMLAN Device Control) followed by two bytes that specify the device control parameters. So, I’d think 0x03 is more appropriate for the first byte but maybe I’m wrong?
Just to break down the message fully in order to help people learning about this stuff:
The message is an ISO-TP formatted UDS message.
0x07 is the # of data bytes following this byte in the message. So, 7 means we’re sending 8 bytes in this CAN frame
0xAE is GMLAN device control. This is the UDS service number
0x2A or 0xFE is the device control CPID which basically sets what type of thing we’re trying to control.
All bytes thereafter are parameters to that CPID. So, 0x80 is the parameter in either case which is bit 7 set.
Now, oddly enough, CPID 0xFE with a payload of 0x80 actually should mean “Theft deterrent relearn” not DTC clear but maybe they aren’t quite following the GMLAN standard.
Great info, im still awaiting my M2. How do I send those commands? Also what are the commands to write the new vin? Thanks guys
The VIN in the tuner unit can be easily reprogrammed by editing the EEPROM, but in the HMI it’s stored in the Flash, i tried editing it but got errors so probably there is a checkcsum that needs to be modified too. I did this out of frustration since the SPS will let you only program the calibration files available for that VIN so if you want to add a feature not available for that vehicle it won’t allow you to. I never tried to do bench programming on the HMI but one thing to remember is that the MOST loop must be closed or it won’t start. Another thing i observed is that if you reprogram it via the SPS it will clear the VIN and relearn it on the next ignition cycle so if you reprogram in one vehicle and remove it while powered and connect it to another, it would learn the VIN from the second.
I still need to hook the M2 back up and test your theories… but something interesting to note. I took the HMI out of the 1LT car and put it in the ZL1. Obviously that tripped theft lock. Then I attempted to program the HMI via SPS to the ZL1 so that it could be used in the ZL1. This was a no-go. I thought the VIN would be erased and reloaded when it turned back on. Unfortunately, this didn’t happen. However, by doing it this way, when I installed it back into the 1LT, the OTA stuff started working again. What I would like to do is get the VIN to match the ZL1 so that I can swap it out…and update the maps. Finding that this would be an easier solution than re-hashing the VIN for the Maps update on the USB drive.
You might want to talk to someone like MVI or Global Auto to look at that stuff. And I believe Global Auto does the reflashing for MVI. They do a bunch of stuff with the navigation units and might be able to help you out with that. Although I am sure they won’t share how they do it.
A group has made a PCM reflasher that can be redone and used to write that stuff to the HMI and such but it is older GM stuff right now. I have a Tech 2 and when I get a little further along I will be looking into reverse engineering loading binaries onto modules but that is not today…
Rodney
Interesting. What’s the easiest way to do this flash of the eeprom? I have the HMI 2.5
Ahh ok. I’m working with my 2.5 HMI module for nav and such.
I’ve got a 2.5 module with me right now, I’ve looked across the board and there’s no eeprom on it, I suspect the vin is in flash somewhere, or on a part of the processor
So I’ve read before. I was hoping there was something new. Still want to erase the VIN. SPS doesn’t seam to do it anymore. Unless I need to somehow trigger power off when it’s at the end of programming before it cycles the boot?
I hate to resurrect an old thread, but there is very little info on this online. Has anyone had any luck with anything discussed here? There seemed to be many approaches to getting this to work. It is my understanding @th3magpi3 has started offering flashing for these on another forum, but I’m unsure if he would be willing to share any information. @tjshadyluver have you tried these commands yourself? If so, was this done on a bench or in the vehicle? If done on a bench, what commands did you use to ‘wake’ the HMI up that it would normally see from a BCM? If in the vehicle, what was your process for that? There seemed to be quite a few people with knowledge on this in the thread, but have let it go aside to focus on other projects. Thanks.
I haven’t seen anything. It would be nice to know.
1 Like
I have been busy with school to be able to track this but you are supposedly able to do a block read of any module and then be able to do a block write as well. It is my understanding that reading is simple as it is just reading the firmware out with the block read commands. But writing requires a 2 step process with a “kernel” involved. The idea is that the older process pre canbus still works with canbus stuff but just uses a different communications protocol. This is what I understand to be true but I have not had time to work with it to know for sure. I personally will be working on this for older pre-canbus modules using the same codebase that is used to build out the pcm writing software since it should work the same way. I also suspect you will find that the VIN is stored within the CPU and you will need a schematic of that CPU. You will likely find a JTAG interface somewhere on the board or a serial interface that may allow you access to the firmware as well.
1 Like
So by that, do you mean writing you have to reflash the entire kernel every time you want to write a new block? That seems to be almost too much, we would have to read the existing kernel, make our changes in the computer, then reflash as a whole? Wouldn’t mode 27 or some type of security access be required to do an entire reflash? I plan on grabbing a M2 and a 2.0HMI just to play around with. It think my first step is going to be actually flashing a new HMI through SPS to my truck and then sniffing the traffic to see if maybe there are some commands to clear VINYL, similar to what @tjshadyluver suggested. I wish @th3magpi3 would be willing to share some info on this. I know he was able to get it working.
Not sure the best way to explain it…
I was somewhat inaccurate in my last message.
To read or write to the PCM requires a kernel. My understanding is that you write the kernel code to some place in the ram, reboot the pcm and then it is running the kernel. This kernel is then used to read and write from the flash memory using the block read and write commands. When the kernel is done you reboot the pcm and it returns to running the program in the flash.
I am unsure of the mechanism that allows the kernel to be placed into ram while the original program is still running. I don’t know if there is a special ram location that it gets loaded into or what. I understand that to be the same mechanism for all of the modules so if you figure out the PCM flash technique you can do it for any of the modules as well. I hope to get more involved in this process but that is likely a long ways off with what I have on my plate today.
I can tell you what doesn’t work-
HMI is not security locked.
(Seed request) 252 0x02 0x27 0x01 & 252 0x02 0x27 0x03 both return 652 0x03 0x7F 0x27 0x12
(Device control EEPROM access, and theft relearn) 252 0x03 0xAE 0xFE 0x40 & 252 0x03 0xAE 0xFE 0x80 both return 652 0x03 0x7F 0xAE 0x12
Trying to write to the VIN DID doesn’t work either:
252 0x10 0x13 0x3B 0x2F 0x00 0x00 0x00 0x00
252 0x21 0x00 0x00 0x00 0x00 0x00 0x00 0x00
252 0x22 0x00 0x00 0x00 0x00 0x00 0x00 0x00
OR
252 0x10 0x13 0x3B 0x2F 0xFF 0xFF 0xFF 0xFF
252 0x21 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
252 0x22 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
It replies with 652 0x03 0x7F 0x3B 0x31 (request out of range, see below)
RequestOutOfRange
This response code shall be sent if:
The dataIdentifier in the request message is not supported in the node or
the dataIdentifier is supported for read only purposes (via service $1A).
The dataIdentifier, which references a specific address, is secured and the
ECU is not in an unlocked state.
Any data transmitted in the dataRecord of the request message is invalid (if
applicable to the node).
I feel like i’m 95% there and there’s one small detail i’m overlooking. I’ve tried to message magpie some days ago, but it looks like he’s just another CW. 
It keeps telling you that the ECU doesn’t support that sub-function but that might be a bit deceptive. Have you tried asking the ECU to go into a different session mode?
252 2 0x10 1 0 0 0 0 0 (default session type. wont be a lot of use)
or
252 2 0x10 2 0 0 0 0 0 (programming session)
or
252 2 0x10 3 0 0 0 0 0 (extended diagnostics session)
It’s a possibility it could require something else as well but I’ll bet it wants you to be in programming session mode.
Collin, no joy there. I tried both and didnt even get a response back.
I wondering if my commands need to be sent on a different bus? I’m not really sure how that’s accomplished in savvycan though. So far everything I’ve been doing is on bus 0.
Did you also try 0x07, 0xAE, 0x2a, 0x80 from tjshadyluver? I’m not sure if what he has is worth going after because of the first byte error in what he posted. Thanks for the replies so far guys.
anymore updates?
Cant beleive th3magpi3figures it out and just leave ya hanging
3 Likes