Open source GM OBD2 flash tool using a ELM327 device

They go by many names, P01, P59, VPW, '0411 etc. Also covering E38 and newer here.
Locked
User avatar
durahax
Posts: 34
Joined: Sat May 12, 2012 3:00 am
cars: 03 GMC Sierra 2500HD - LB7 Duramax Diesel
Location: Philadelphia, PA

Re: Open source GM OBD2 flash tool using a ELM327 device

Post by durahax »

Been thinking these past few days, then I decided to go through this thread again. Glad I did, now I really think this is possible on a stn1100! I was under the assumption that our routine needed to be uploaded in one shot, the answer was in here the whole time. Let me know what you guys think. I understand ELM is not possible, just trying to keep the dream alive. I also understand this is not the ideal setup for upload/download, but that's the fun in it. I really want to make my own open source board with bluetooth, usb, aux inputs (wideband,egt,boost), block mode, 4x, etc. For now I'm just doing this to help me better understand J1850 VPW. I'm at the point I know what's going on but I need spend time in IDA to really understand upload/download code better. I could cheat and use someones code, but like I was saying I really want to understand what's going on...
Importantly, when you are downloading your routine you are sending block transfers like this with submode $00 for all blocks. Except for the start of you code, which you must send as the last block with submode $80. The address you send with a submode $80 will then be exec'd on completion of the download.

2nd part code - 1st Block
send: 6D 10 F1 36 00 00 80 FF 90 80 (128 bytes, loc FF9080) 
$80 bytes data & 2 bytes cksum


3rd part code - 2nd block
send: 6D 10 F1 36 00 00 80 FF 91 00 (128 bytes, loc FF9100)
 $80 bytes data & 2 bytes cksum


...etc...


Then for the last (start of code):

send: 8C 6D 10 F1 36 80 00 80 FF 80 00 (128 bytes, start loc FF8000)


Control will then pass to your routine at $0xFF8000.
User avatar
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: Open source GM OBD2 flash tool using a ELM327 device

Post by antus »

Yes, that is correct. Its also legal to upload the routine from the start then when your done send a zero length packet to the address to execute with the execute bit set (thats the 0x80). 6D 10 F1 36 80 00 00 xx yy zz to execute from xx yy zz
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
160plus
Posts: 90
Joined: Thu Sep 21, 2017 3:00 pm

Re: Open source GM OBD2 flash tool using a ELM327 device

Post by 160plus »

I normally wouldn't drag up an old post like this but some of my recent work lead me to this thread. After reading it and based on my current projects I decided to give this a go from a slightly different perspective. I read the log from a LS Flash tool using a serial terminal as well as an Elm App(2 separate devices reading the same thing as the pcm's bin was read out. I was getting nothing useful to start with and then some of the comments around page 5 got me thinking. So I turned off 4x mode on the LS program I was using to read the PCM and BAM. Got the full log....so after looking though it I deiced to give it a shot manually entering the commands(wasn't worried about bricking the pcm).

I'm able to send the what I believe is the "payload" that was being discussed here, I'm not a programmer by any means but there were two VERY large blocks that were sent almost as soon as the Pcm's bin was read out and the format was almost exactly like it was outlined on the 1st page of this thread. Here's some snipps of what I was able to send to the pcm and what I got back.
E8 FF 10 03 B3
Send>6C FE F0 28 00 10
Read>6C F0 10 68 00 9F

Send>6C 10 F0 27 01 B0
Read>6C F0 10 67 01 60 CB E2

Send>6C 10 F0 27 02 C7 ED D3
Read>6C F0 10 67 02 34 4B

Send>6C 10 F0 34 00 CA 10 00 00 00 00 00 00 56 CF 01 06 00 00 00 00 46 CF 01 07 60 07 30 00 00 00 00 00 66 CF 01 07 50 15 40 00 00 00 00 00 66 DF 01 03 60 10 00 00 00 00 00 00 00 00 00 00 A1 BD 70 03 32 FF 91 3E 28
(no response but no error or reset either)

Send>6C 10 F0 0C A1 00 00 00 00 00 00 05 6C F0 10 60 00 00 00 04 6C F0 10 76 00 73 00 00 00 00 00 06 6C F0 10 75 01 54 00 00 00 00 00 06 6D F0 10 36 01 00 00 00 00 00 00 00 00 00 00 0A 1B D7 4E
(no response but no error or reset either)

Send>6D 10 F0 36 80 00 00 FF 91 3E 02 4E 52
Read>6C F0 10 7F 36 80 00 00 FF 91 22 B9

Send>6D 10 F0 36 80 00 00 FF 91 3E 02 4E 52
Read>6C F0 10 7F 36 80 00 00 FF 91 22 B9
Pcm Reset on it own>68 13 10 11 00 46
This was sent using macros with Tera term VT, since I have to watch a separate screen for responses my timing was very good on the sends. It took me nearly an hour with a PC before I gave up and linked it up to my phone. It was actually much easier to send the commands using a basic Elm app. Here's a screen shot off my phone at one point, I had no issues sending the packets.....however I'm also not using common or even cheap Elm devices(still sub $100 though).

Screen shot from phone(android)
https://imgur.com/a/OlOoW

Here's some clips changing 1 digit in the pcm's serial number
E8 FF 10 03 B3
6C FE F0 28 00 10
6C F0 10 68 00 9F
6C 10 F0 27 01 B0
6C F0 10 67 01 60 CB E2
6C 10 F0 27 02 C7 ED D3
6C F0 10 67 02 34 4B
6C 10 F0 34 00 00 0C FF 80 00 11
6C F0 10 74 00 44 1E
8C FE F0 3F 00 04 8C FE F0 3F 2C
6C 10 F0 36 00 00 0C FF 80 08 32 44 47 30 32 46 42 55 38 32 39 32 04 64 69
6C F0 10 76 00 73 04
6C FE F0 20 B1

-------------------------------------------

E8 FF 10 03 B3
6C FE F0 28 00 10
6C F0 10 68 00 9F
6C 10 F0 27 01 B0
6C F0 10 67 01 60 CB E2
6C 10 F0 27 02 C7 ED D3
6C F0 10 67 02 34 4B
6C 10 F0 34 00 00 0C FF 80 00 11
6C F0 10 74 00 44 1E
8C FE F0 3F 00 04 8C FE F0 3F 2C
6C 10 F0 36 00 00 0C FF 80 08 31 44 47 30 32 46 42 55 38 32 39 32 04 63 A4
6C F0 10 76 00 73 04
6C FE F0 20 B1

If there's any interest in this still I can provide full logs for: Bin read, Bin flash, Calibration flash, Vin number changes and even serial number changes. I could also provide the same type of logs using a commercial product like Efi Live and possibly even Hp Tuners. I've got more then a couple of pcm's and I'm not afraid to brick a couple of them if someone would like to explore this further with me. I honestly don't under stand that much about this type of code. I personally don't need something like this since I have an "alternative" product that works just fine for flashing but I would be interested in porting something like this into an Android App rather then a Pc program if it can be made to work.


Given the age of this thread and the advancements in technology I think someone a bit more knowledgeable then myself should take a second look at this again.
User avatar
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: Open source GM OBD2 flash tool using a ELM327 device

Post by antus »

The problem is the legality. The large blocks (which you havnt posted here) are proprietary code that executes on the pcm. To publish it or use it an another product is likely to attract the wrong type of legal attention from the big players who want to protect their code. The process is understood, cloning others commercial software is easy, but writing alternate code for the pcm is hard. I have done it for read, dimented24x7 has done it for write.

What interface are you using that supports large packets? How large can it handle?
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
User avatar
vwnut8392
Posts: 59
Joined: Fri Feb 28, 2014 7:38 am
cars: AAN powered 83 audi 4000 quattro
1983 audi UR quattro
1992 GTI VR6

Re: Open source GM OBD2 flash tool using a ELM327 device

Post by vwnut8392 »

not to stray off topic but i work a bit in the german car car ECU world that use bosch related products and there have been chinese clone after clone of the high end tuners software and hardware and there is nothing the tuner can do about it unless they have a patent on their hardware and software which 98% of them dont because they are developing tools for profit that modify code that is owned by bosch. to get patents or anything of that nature the tuner needs to have permission from bosch to be allowed to patent their tools that allow the modification of bosch specific code. bosch is never ever going to give an outside company permission to profit from their work legally and i would imagine GM/delco is the same way so all the big tuners can do is cry and moan about open source tuning becoming readily available because you guys here are doing exactly what the big tuners did to develop their stuff. i went through legal scuffle with a big german car tuner and at the end of it they had no case because they did not have backing nor permission from bosch to reverse engineer or profit from their tools/tuning. the ECU developer like bosch doesnt care what people really do with the ECU, they arent going to chase people down and file law suit against any of us for working on such a project. in some instances people like us are prided by the manufacturers for expanding the capabilities of their product to do things they never even imagined. not trying to start a big debate about legalities here but i figured i would point that out. now not posting proprietary code and such from a high end tuner is just common courtesy. having a public way to read/write to the stock ECU and reverse engineering the TX/RX protocol is in my opinion does not have anything to do with any high end tuner as that was developed by the manfacturer. now posting how to hack an HPtuners cable and make unlimited free credits is something someone should keep to themselves out of respect.

On another note, is it possible that there is a back door into these ECU's? all bosch products have a boot mode that can be invoked where the ECU will always dump or take a flash. this is normally done on a bench harness by the way. for example, the motronic 7 ECU has a boot mode that is invoked by grounding pin 28 on the flash chip when the ECU powers on and it will give up all of its secrets over the OBD port. later Motronic 9 ECU's have a header that when a pin is grounded along with a serial connection those ECU's will give up all their secrets. boot mode is known as a developer back door left there by the manufacturer and from what i've seen most ECU manufacturers have this back door that can be invoked to give up the flash.
160plus
Posts: 90
Joined: Thu Sep 21, 2017 3:00 pm

Re: Open source GM OBD2 flash tool using a ELM327 device

Post by 160plus »

vwnut8392 wrote:not to stray off topic but i work a bit in the german car car ECU world that use bosch related products and there have been chinese clone after clone of the high end tuners software and hardware and there is nothing the tuner can do about it unless they have a patent on their hardware and software which 98% of them dont because they are developing tools for profit that modify code that is owned by bosch. to get patents or anything of that nature the tuner needs to have permission from bosch to be allowed to patent their tools that allow the modification of bosch specific code. bosch is never ever going to give an outside company permission to profit from their work legally and i would imagine GM/delco is the same way so all the big tuners can do is cry and moan about open source tuning becoming readily available because you guys here are doing exactly what the big tuners did to develop their stuff. i went through legal scuffle with a big german car tuner and at the end of it they had no case because they did not have backing nor permission from bosch to reverse engineer or profit from their tools/tuning. the ECU developer like bosch doesnt care what people really do with the ECU, they arent going to chase people down and file law suit against any of us for working on such a project. in some instances people like us are prided by the manufacturers for expanding the capabilities of their product to do things they never even imagined. not trying to start a big debate about legalities here but i figured i would point that out. now not posting proprietary code and such from a high end tuner is just common courtesy. having a public way to read/write to the stock ECU and reverse engineering the TX/RX protocol is in my opinion does not have anything to do with any high end tuner as that was developed by the manfacturer. now posting how to hack an HPtuners cable and make unlimited free credits is something someone should keep to themselves out of respect.

On another note, is it possible that there is a back door into these ECU's? all bosch products have a boot mode that can be invoked where the ECU will always dump or take a flash. this is normally done on a bench harness by the way. for example, the motronic 7 ECU has a boot mode that is invoked by grounding pin 28 on the flash chip when the ECU powers on and it will give up all of its secrets over the OBD port. later Motronic 9 ECU's have a header that when a pin is grounded along with a serial connection those ECU's will give up all their secrets. boot mode is known as a developer back door left there by the manufacturer and from what i've seen most ECU manufacturers have this back door that can be invoked to give up the flash.
I'm from the US so I can't speak for the rest of the world but your on the right track for a lot of this. The J2534-1 mandated a uniform platform to gain flash access to any computer on a vehicle that interacts or directly controls the vehicles emission system. The ability to flash the engine controller is not restricted or protected under the J2534 protocol and last I knew the design for the hardware was publicly available. As far as the actual flash goes it seems there are two ways people look at it. People refer to the "code" as being priority but your exactly right that companies have already reverse engineered what the OEM's created in the first place. Several OEM's have tried to keep the ability to flash all modules proprietary and have been shot down numerous times in court. The ruling is always that any computer that interacts with the emission system can not have restricted access. Now some companies(such as GM) have maintained the J format across most modules in a vehicle allowing aftermarket tools to access proprietary systems such as the bcm, tcm etc but as a subset of the j2534-1 protocol such as j2534-2 or -3. So I would say it's hard if not impossible to say that the "code" is actually proprietary since if an OEM manufacturer isn't able to lock it down or restrict access than how can any company claim rights to the "code" used to access the same thing? No one's going to argue this fact about a tuning program such as Hp Tuners or Efi Live since the way that that alter the bin file is clearly prosperity information. Once the bin file is out of the pcm it's no longer in control of any emission components and I'm sure no one would argue that fact. This is likely the reason that you have to pay to access OEM programming information... on that same thought the J protocol also specifies that OEM's must make their software avaible at a "Reasonable" cost and it must be compatible with the J2534 standards. Now any thing prior to the J protocols is an entirely different beast but lucky for us GM is pretty good about rolling every thing into one tool to start with.

Now the way I personally see this....and I've been told before I'm totally wrong here but just about every "Flash" I've spy'd on while it took place uses almost the same format/layout in how the flash takes place. What I have noticed that changes is the size of the blocks being written and the order that lines are sent in as they are being flashed. The main reason I disagree with the belief that a flash method could be protected is because technically it could be done with out ANY type of flash program. You could flash a pcm in a terminal window with nothing more then a keyboard if you could type fast enough and knew exactly what you were typing.....because you'd be manually every line/byte/bit of a bin file by hand. I know this can be done for a fact because I've been able to do it using macros, I've made it though the 1st block on a 411 pcm and every response from the pcm was exactly what I was expecting as if it was being done with a normal flash tool. I did it with something like 40 macros before I ran out of places to put them and keeping that many macros straight was nearly impossible. I knew I couldn't flash it but I was pretty sure it could be done that way and wanted to give it my best shot. When I look at a bin being flashed all I see are pairs of numbers and letters and honestly I don't have any clue what they mean but that didn't mean I could replicate exactly what I was seeing. So I flashed a couple of vastly different files and looked for similarity between them to try and figure what was the program and what part was the bin. O
I don't see any code here, what I see are the headers being changed on an Elm device and commands being sent....commands that look just like

AT H1 AT AL AT SH AT SP 01


So.......I leave off the checksum for each line and run it
AT SH 6C FE F0
Send: 28 00
AT SH 6C 10 F0
Send: 27 01
AT SH 6C 10 F0
Send: 27 02 C7 ED
AT SH 6C 10 F0
Send: 34 00 00 0C FF 80 00
And so on......I see pairs of numbers and letters not any type of propriety code. Tell me I'm wrong.....I'll look again and still just seem numbers and letters

AT SH 6D 10 F0
SEND: 36 00 00 DC FF 8A 00 0C 01 00 01 66 F2 11 FC 00 0C F6 0C 10 11 61 08 4E 75 11 FC 00 04 F6 0C 11 C0 F6 0D 3A 3C 10 00 61 00 00 8A 04 45 00 01 4A 45 67 12 42 80 10 38 F6 0E 02 00 00 03 0C 00 00 03 67 E4 4E 75 4E F9 00 FF 82 46 42 80 61 64 52 00 0C 00 00 03 66 F6 4E 75 42 81 20 7C 00 09 C0 00 22 7C 00 0B 00 00 4A 01 66 02 61 46 06 01 00 01 20 18 0C 80 57 30 35 50 67 16 0C 80 57 30 36 50 67 0E 0C 80 57 30 37 50 67 6 B3 C8 66 D8 60 10 20 10 0C 80 48 54 20 20 66 CC 11 FC 00 AA 81 FB 4E 75 20 28 63 29 32 30 30 35 20 45 46 49 4C 49 56 45 08 78 00 07 D0 06 11 FC 00 55 FA 27 11 FC 00 AA FA 27 4E 75 3A 3C B0 00 61 E6 06 45 00 01 0C 45 FF FF 66 F4 4E 75 4C 53 31 42 5F 76 31 2E 37 43 42 BF 42

PCM Response: 6D F0 10 76 00 73 42
160plus
Posts: 90
Joined: Thu Sep 21, 2017 3:00 pm

Re: Open source GM OBD2 flash tool using a ELM327 device

Post by 160plus »

Making a separate post so it doesn't get lost in my wall of text to pass on some information.

The OBDLink stn11xx family of chips has come a long ways. They currently have firmware (by request only) that allows up to 3.5kb to be sent in a single hit, it also supports continuous write with no packet size limit since it's transmitting in real-time as a continuous packet until you line break.

The hardware is capable of supporting the 4x mode however it is not implemented in the firmware and that's where it would require someone that knows this stuff inside and out to get working......but it IS capable of it.

So....Hardware is avaible for flashing for under $100 in a commercial device or you could design your own with the data they provide for replicating the devices they sell. However it would need someone extremely knowledge to make it work the way people wanted using 4x with 4kb pack sizes.



Some other things to consider.....

A read/write solution with out 4x is better then nothing....

A 3.5kb........2kb.....1kb...even 500byte read/write is also better then nothing......

Current progress.....Read only/change vin using hardware that cost $280 bucks.

I'm all for setting a project goal but at the end of the day something is better then nothing at all and I think that's where this whole thing got side tracked. Every one was so set on getting something comparable to commercially avaible programs that the actual goal of the project was lost along the way some where. My understanding was this goal was to create an opensource program with inexpensive commercially avaible hardware that was readily avaible and could Read/Write a pcm that's almost 20 years at this point. I wish I knew more about this stuff or actually under stood what was being done because the progress I've made just fumbling around with things and having no clue what I was doing was enough to make me think I might actually be able to figure this out if I think on it long enough.
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: Open source GM OBD2 flash tool using a ELM327 device

Post by Tazzi »

The letter/number pairs your seeing is called Hexadecimal.
A single byte can be a value between 0 to 255, which in hexadecimal is 00 to FF.

The J2534 protocol and J2534 compliant devices are just tools in the scheme of things, they are useless without designing an application (Or macros) to perform actions. Now, its these actions which tend to need some custom work.. which is where the IP code comes into play.

The IP people refer to in GM vehicles for tuning is called the bootloader. The bootloader is custom code that runs on the ECU and allows reading or writing to the flash.. ie.. tuning.
Not all GM modules require one, some have them have a bootloader inbuilt into them, but most of them do require a custom bootloader made up.

This bootloader is custom built by tuning companies. I do believe alot of the tuning companies essentially just copy each other by decompiling the code.. seeing what it does.. and basing their own from that.

Anyways.. back on target... looking at the lines you sent.. what I see is the following:

AT SH 6C FE F0 -Set VPW header.. FE target (Global ID).. F0 sender (Scantool)

Send: 28 00 - Send mode 28 (Tell everything on the comms line to shutup)

AT SH 6C 10 F0 -Set VPW header.. 10 target (ECU).. F0 sender (Scantool)

Send: 27 01 - Send mode 27 (Security), sub function 1 (Request Seed)

AT SH 6C 10 F0 -Set VPW header.. 10 target (ECU).. F0 sender (Scantool)

Send: 27 02 C7 ED - Send mode 27 (Security), sub function 2 (Send key), C7 ED (Key)

AT SH 6C 10 F0 -Set VPW header.. 10 target (ECU).. F0 sender (Scantool)

Send: 34 00 00 0C FF 80 00 -Send mode 34, prepare memory and load at address.

Then the next chunk would be part of the bootloader.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: Open source GM OBD2 flash tool using a ELM327 device

Post by antus »

@160plus That chunk you called "send" IS the code being sent. Some PCMs, such as (I believe but may be wrong) the bosch types have the flash ability built in so you only need to talk the protocol and send the data to write. But the delco/delphi flash PCMs have the ability to change some things, but not the ability to do the flash. So you have to unlock the PCM then upload extra code.

For example, I'll put some of my code here:

Code: Select all

| GM '0411 Read code - (c) 2013 Antus / pcmhacking.net
| Processor:	    68330
| Target Assembler: 680x0 Assembler by GNU project
| ===========================================================================

.equ J1850_Config, 0xFFF600
.equ J1850_Command, 0xFFF60C
.equ J1850_TX_FIFO, 0xFFF60D
.equ J1850_Status, 0xFFF60E
.equ J1850_RX_FIFO, 0xFFF60F
.equ toolid, 0xF0

start:
    bsr.w   WasteTime			
    move.b  #3,	(J1850_Command).l	| Flush	frame except for completion code
    move.b  #0,	(J1850_TX_FIFO).l	| Load dummy byte to initiate transfer - needed

wait01:
    bsr.w   ResetWatchdog			| Branch to Subroutine
    bsr.w   WasteTime				| rate limit rx	loop
    move.b  (J1850_Status).l, %d0		| get the vpw status
    andi.b  #0xE0, %d0				| Mask Receive FIFO Status Field (RFS) register	1110 0000
    cmpi.b  #0xE0, %d0				| Check	for "completion code only, at head of buffer" message 1110 0000
    bne.s   wait01					| not ready? wait and retry
    move.b  (J1850_RX_FIFO).l, %d0		| strip	off the	completion code
    bsr.w   LongWaitWithWatchdog		| Branch to Subroutine - needed

MainLoop:
    bsr.w   J1850_ReadPacket				| wait for and read next frame
    cmpi.b  #0x35, (InputMode).l			| Is it a mode 0x35 (Tool asking PCM to send data)
    beq.w   processmode35				| process it
    cmpi.b  #0x20, (InputMode).l 		 	| Is it a mode 0x20? (return to normal comms)
    bne.w   MainLoop					| No more options, next packet
    movea.l #VPWMode60Msg, %a0			| Reply to a mode 20 with a mode 60 (+40)
    move.l  #3, %d0					| Message Length
    bsr.w  WriteVPW_a0_buffer_d0_length		| Send normal comms message
    bsr.w Stop						| Reboot PCM

<snip>
Then together with the build tools you end up with the program to send to the pcm in hex, which is the opcodes the processor actually executes. Remember the code is not interpreted so what the processor executes is not human readable or parseable without putting it through a disassembler, and even then if you know what the opcodes are doing its hard to make sense of the big picture. This is why assembly source code tends to need so many comments inline.

Code: Select all

[root@gemini readcode-1.3]# ls -l
total 4000
-rw-rw-rw-. 1 nobody nobody     88 Mar 19  2013 link.lds
-rwxrwxrwx. 1 nobody nobody 540728 Mar 19  2013 m68k-elf-as
-rw-rw-rw-. 1 nobody nobody 973838 Mar 19  2013 m68k-elf-as.exe
-rwxrwxrwx. 1 nobody nobody   4637 Mar 19  2013 m68k-elf-ld
-rw-rw-rw-. 1 nobody nobody 946190 Mar 19  2013 m68k-elf-ld.exe
-rwxrwxrwx. 1 nobody nobody 403196 Mar 19  2013 m68k-elf-ld.real
-rw-rw-rw-. 1 nobody nobody 961038 Mar 19  2013 m68k-elf-objdump.exe
-rw-rw-rw-. 1 nobody nobody 205838 Mar 19  2013 make.exe
-rw-rw-rw-. 1 nobody nobody    298 Sep 23 06:36 makefile
-rw-rw-rw-. 1 nobody nobody    897 Mar 19  2013 makeheader
-rw-rw-rw-. 1 nobody nobody  11840 Mar 19  2013 readcode.asm
-rwxr-xr-x. 1 nobody nobody    789 Sep 23 06:37 readcode.bin
-rw-r--r--. 1 nobody nobody   4848 Sep 23 06:37 readcode.h
-rw-r--r--. 1 nobody nobody   2948 Sep 23 06:37 readcode.o
[root@gemini readcode-1.3]# make clean
rm *.bin *.o *.h
[root@gemini readcode-1.3]# make
./m68k-elf-as  readcode.asm -o readcode.o
./m68k-elf-ld -m m68kelf --oformat binary -T link.lds readcode.o -o readcode.bin
perl makeheader readcode.bin readcode.h
size: 789
hexsize: 0x03, 0x15
sum: 0DD5
[root@gemini readcode-1.3]# hexdump readcode.bin | head
  Address  | 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F | 0123456789ABCDEF
-----------+-------------------------------------------------+-----------------
0x00000000 | 61 00 00 98 13 FC 00 03 00 FF F6 0C 13 FC 00 00 | a...............
0x00000010 | 00 FF F6 0D 61 00 02 B4 61 00 00 80 10 39 00 FF | ....a...a....9..
0x00000020 | F6 0E 02 00 00 E0 0C 00 00 E0 66 E8 10 39 00 FF | ..........f..9..
0x00000030 | F6 0F 61 00 00 2E 61 00 02 16 0C 39 00 35 00 FF | ..a...a....9.5..
0x00000040 | 94 43 67 00 00 78 0C 39 00 20 00 FF 94 43 66 00 | .Cg..x.9. ...Cf.
0x00000050 | FF E6 20 7C 00 FF 94 51 70 03 61 00 00 9E 61 00 | .. |...Qp.a...a.
0x00000060 | 00 44 2A 3C 00 00 27 10 61 00 02 60 61 00 00 2C | .D*<..'.a..`a..,
0x00000070 | 61 00 00 28 61 00 00 24 61 00 00 20 61 00 00 1C | a..(a..$a.. a...
<snip>
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: Open source GM OBD2 flash tool using a ELM327 device

Post by Tazzi »

160plus wrote:The OBDLink stn11xx family of chips has come a long ways. They currently have firmware (by request only) that allows up to 3.5kb to be sent in a single hit, it also supports continuous write with no packet size limit since it's transmitting in real-time as a continuous packet until you line break.

The hardware is capable of supporting the 4x mode however it is not implemented in the firmware and that's where it would require someone that knows this stuff inside and out to get working......but it IS capable of it.
The problem with ELM based scantools.. is their actual protocol is too limited.

For example. ELM based tools such as the OBDlink allow for sending one message to the car, and then receiving one message back.
The flaw with that design, is sometimes you actually need to get multiple responses back from the car. This occurs often when flash updating most modules in GM vehicles, since once you send a chunk of code for flashing, the ECU tends to respond with a "Please wait, Im slow and taking a while to process" message, it will continue to send that same 'message' until it has finished processing and then sends another message saying "Im finished and ready for the next chunk".

Not all ECUs do the above.. but it does occur alot (Maybe more so with CAN based modules.. not VPW).

Looking at VPW specifically.. 4x is not required at all. Its a silly mis-conception there. Flashing can be done at 1x VPW speed which some tuning tools allow selecting. And flashing can be done with smaller chunk sizes. The faster speeds and larger chunks is all done to speed up the flashing process.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
Locked