OBDX Development - Developer Tools and Suggestions
Re: OBDX Development - Developer Tools and Suggestions
Lol.
With regards to your question of maybe going to far. I think Forscan for the Ford world has been a godsend. Nothing for GM yet. Seems to me like that space is up for grabs.
With regards to your question of maybe going to far. I think Forscan for the Ford world has been a godsend. Nothing for GM yet. Seems to me like that space is up for grabs.
Re: OBDX Development - Developer Tools and Suggestions
Fords IDS software was nice enough to have all the options in engineering modes... so forscan just copied that data into an easier system to use.hjtrbo wrote:Lol.
With regards to your question of maybe going to far. I think Forscan for the Ford world has been a godsend. Nothing for GM yet. Seems to me like that space is up for grabs.
Where-as GM did not have all their configurations/edits in plain site, majority of it is in calibrations which take alot longer to reverse engineer

But the going to far is only relating to remote programming.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726

Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726

Re: OBDX Development - Developer Tools and Suggestions
Hit a bit of a snag on the high speed gmlan (83.333kbps).
When SPS requests to go to high speed.. it appears it’s being done in a weird way.
As per the GMLAN spec, it is suppose to send the 101 FE 02 A5 03… then straight away switch to high speed gmlan.. and send a tester present message.
Now, SPS is suppose to send the j2534 commands to tell the scantool to automatically swap to high speed, but it does not do that, it actually sends a command to manually switch to high speed.
BUT.. the way it’s doing it.. is completely screwing up.
So.. it sends:
101 FE 02 A5 03 (should go straight to high speed here)
101 FE 01 3E (tester present… still on normal speed)
- sets high speed mode here -
101 FE 01 3E (tester at high speed)
The tester present sent at normal gmlan when it’s supposed to already be at high speed causes massive problems, basically causes the gmlan line to instantly drop out of high speed.
Now trying to jump into high speed on the A5 03 does work.. but sps then sends the tester present too fast so the rest of the car has not yet switched to high speed.
My only solution is to add an artificial delay so that sps doesn’t spam the line too quick.. hopefully that work..??
I have confirmed that the CAN timing is correct, since I can put the cluster into high speed mode manually with my own software.. but Techline is just causing so much grief!!
When SPS requests to go to high speed.. it appears it’s being done in a weird way.
As per the GMLAN spec, it is suppose to send the 101 FE 02 A5 03… then straight away switch to high speed gmlan.. and send a tester present message.
Now, SPS is suppose to send the j2534 commands to tell the scantool to automatically swap to high speed, but it does not do that, it actually sends a command to manually switch to high speed.
BUT.. the way it’s doing it.. is completely screwing up.
So.. it sends:
101 FE 02 A5 03 (should go straight to high speed here)
101 FE 01 3E (tester present… still on normal speed)
- sets high speed mode here -
101 FE 01 3E (tester at high speed)
The tester present sent at normal gmlan when it’s supposed to already be at high speed causes massive problems, basically causes the gmlan line to instantly drop out of high speed.
Now trying to jump into high speed on the A5 03 does work.. but sps then sends the tester present too fast so the rest of the car has not yet switched to high speed.
My only solution is to add an artificial delay so that sps doesn’t spam the line too quick.. hopefully that work..??
I have confirmed that the CAN timing is correct, since I can put the cluster into high speed mode manually with my own software.. but Techline is just causing so much grief!!
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726

Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726

Re: OBDX Development - Developer Tools and Suggestions
SUCCESS!!!
Highspeed gmlan flashing working.
The SAE J2534 document is a little vague in this area, but indicates a J2534 must support going to highspeed automatically when detecting a highspeed request. Now.. it does not say whether this is automatically enabled or not... but does have settings to enable/disable the automatic switch. If making the assumption it should just automatically do it.. it seems to have solved the problem!
I actually had to double check the log to ensure it did actually flash, since it was completed in under a few seconds.. almost didn't seem possible
This now concludes all GMLAN and HS CAN J2534 implementation to suit Techline. I think the only final thing now would be adding ALDL J2534, but I will have to go find a module to update via ALDL first.. only one I know off the top of my head is the VZ instrument clusters. Don't think I have one of them available!!
Highspeed gmlan flashing working.
The SAE J2534 document is a little vague in this area, but indicates a J2534 must support going to highspeed automatically when detecting a highspeed request. Now.. it does not say whether this is automatically enabled or not... but does have settings to enable/disable the automatic switch. If making the assumption it should just automatically do it.. it seems to have solved the problem!
I actually had to double check the log to ensure it did actually flash, since it was completed in under a few seconds.. almost didn't seem possible

This now concludes all GMLAN and HS CAN J2534 implementation to suit Techline. I think the only final thing now would be adding ALDL J2534, but I will have to go find a module to update via ALDL first.. only one I know off the top of my head is the VZ instrument clusters. Don't think I have one of them available!!
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726

Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726

Re: OBDX Development - Developer Tools and Suggestions
After a little bit of VIN searching, I noticed that VY V6’s can apparently actually have the ECM programmed by SPS. Well, at least their calibrations appear so it would be interesting to see if techline supports flashing.
Well.. at least SPS1 would likely have the calibrations, SPS2 probably throw the “calibration data not available” message.
Well.. at least SPS1 would likely have the calibrations, SPS2 probably throw the “calibration data not available” message.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726

Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726

Re: OBDX Development - Developer Tools and Suggestions
I have updated VX PCM's in the past via SPS, IIRC I did a couple for Psyolent.
According to chemistry, alcohol is a solution...
Re: OBDX Development - Developer Tools and Suggestions
Legend, Thankyou for that confirmation. I’ll go pull my parts bin out and grab a VY ecu to flash.Gareth wrote:I have updated VX PCM's in the past via SPS, IIRC I did a couple for Psyolent.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726

Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726

Re: OBDX Development - Developer Tools and Suggestions
Managed to get a VY V6 ECU to successfully flash with the MDI.. surprisingly it has been the most stable of any programming so far
Attached is the file to suit VIN 6G1YK52A23L153011 that has been set as automatic and Petrol.
Out of curiosity, I have been looking at what SPS uploads (Well.. appears to be upload).. and we get the following:
After a refresher of what the modes mean by looking at VL400's breakdown (viewtopic.php?f=10&t=219), mode 6 is 'Address Of Routine to Execute (GM Development)', which I take as a 'upload and execute' command.
It then goes on to do a few more 06 modes such as this one:
Whats weird is you can almost see patterns, or ALDL frames inside of those requests sent... its honestly quite odd!
When trying to line up the data from GMs files, it doesnt seem to actually line up properly.
So I can find "86 AA 36 18 30 86 06 C6 01 BD FF BD 32"
And then further in I can find the rest of that upload.
So I would assume the first part is some sort of addressing for where its to upload.
Once its done its 06 modes, it then moves onto mode 0x10 which is our Flash PCM write routine which appears to upload in chunks of 32bytes at a time.
Just found it kinda interesting since I have not monitored a VY V6 ECU being written by SPS!
But looking back at the J2534 side... theres honesty not much actually required.. we have a whopping 4 commands used for getting setup:
1) Set protocol to ALDL
2) Set pin to 9
3) Set filter to 0 (Allow everything through)
4) Send 'become master'
Effectively... the "Become Master" literally does nothing in this circumstance. It sends nothing, it receives nothing.. and completes instantaneously.
What is is suppose to do, is monitor the bus for poll message/s (Basically the hearbeat), then fire off a message to take control of the bus (tell the bus to be quiet). But... it doesnt.
SPS seems to just carry on and monitors for messages, waiting for the heartbeat to be received before it then actually fires off a F1 56 08 B1 which is a "disable chatter" command to the BCM.
SPS shouldnt have to even search for the heartbeat, since it should have already made the bus quiet... but appears both Bosch and SPS have assumed that neither would implement the command correctly.. and its just there for SAE compliance... even though... its pointless
So.. to make it work with SPS, I have to implement it the same way.. since doing it the 'proper' way results in SPS timing out as it tries to search for the heatbeat after doing the become master command

Attached is the file to suit VIN 6G1YK52A23L153011 that has been set as automatic and Petrol.
Out of curiosity, I have been looking at what SPS uploads (Well.. appears to be upload).. and we get the following:
Code: Select all
F7 83 06 02 00 32 36 84 F0 27 0F CC 09 00 36 18 30 CC 06 01 BD FF BD 32 20 15 3C 30 86 06 97 36 CC AA 00 ED 00 C6 02 9D 16 38 C6 50 F7 10 00 39 35
It then goes on to do a few more 06 modes such as this one:
Code: Select all
F7 FD 06 01 56 86 AA 36 18 30 86 06 C6 01 BD FF
BD 32 39 86 F7 8D 26 17 8B 55 8D 21 96 36 8D 1D
5A 27 0A 18 A6 00 8D 15 18 08 5A 26 F6 96 30 40
8D 0B 1F 2E 40 FC 1D 2D 08 18 38 32 39 9D 19 1F
2E 80 FA A7 2F 9B 30 97 30 39 37 C6 55 F7 10 3A
53 F7 10 3A C6 50 F7 18 06 C6 A0 F7 18 06 33 39
3C CE 10 00 1C 03 08 1D 02 08 38 39 3C CE 10 00
1C 03 08 1C 02 08 38 39 36 20 03 36 86 0A 37 4D
27 0A C6 4B 9D 19 5A 26 FB 4A 26 F6 33 32 39 37
FC 10 0E FD 10 16 33 7F 10 22 20 07 B6 10 23 84
80 27 05 86 80 B7 10 23 39 00 E7
Whats weird is you can almost see patterns, or ALDL frames inside of those requests sent... its honestly quite odd!
When trying to line up the data from GMs files, it doesnt seem to actually line up properly.
So I can find "86 AA 36 18 30 86 06 C6 01 BD FF BD 32"
And then further in I can find the rest of that upload.
So I would assume the first part is some sort of addressing for where its to upload.
Once its done its 06 modes, it then moves onto mode 0x10 which is our Flash PCM write routine which appears to upload in chunks of 32bytes at a time.
Just found it kinda interesting since I have not monitored a VY V6 ECU being written by SPS!
But looking back at the J2534 side... theres honesty not much actually required.. we have a whopping 4 commands used for getting setup:
1) Set protocol to ALDL
2) Set pin to 9
3) Set filter to 0 (Allow everything through)
4) Send 'become master'
Effectively... the "Become Master" literally does nothing in this circumstance. It sends nothing, it receives nothing.. and completes instantaneously.
What is is suppose to do, is monitor the bus for poll message/s (Basically the hearbeat), then fire off a message to take control of the bus (tell the bus to be quiet). But... it doesnt.
SPS seems to just carry on and monitors for messages, waiting for the heartbeat to be received before it then actually fires off a F1 56 08 B1 which is a "disable chatter" command to the BCM.
SPS shouldnt have to even search for the heartbeat, since it should have already made the bus quiet... but appears both Bosch and SPS have assumed that neither would implement the command correctly.. and its just there for SAE compliance... even though... its pointless

So.. to make it work with SPS, I have to implement it the same way.. since doing it the 'proper' way results in SPS timing out as it tries to search for the heatbeat after doing the become master command

- Attachments
-
- aservy53.bin
- (120 KiB) Downloaded 148 times
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726

Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726

Re: OBDX Development - Developer Tools and Suggestions
GM Uart (ALDL) for J2534 is now implemented, we have successful reflashes with SPS
This time using the same VIN, I selected auto then LPG.
It did also come up with a catalytic converter option which was not present previously, I selected the close cats option.
Attached is the update file that it used.
And thats it folks! All supported protocols are now implemented for J2534. This includes ALDL, VPW, HSCAN and GMLAN.
D-PDU compliance for both ALDL, HSCAN and GMLAN will be the next things to work on. But I will be finalizing the GT's firmware now, ready for the first batch of GTs to be received. I have to implement a timer into the GT for measuring LED time on, since protocols such as Canbus are so fast, that we don't even see it flicker as its ON then OFF within microseconds.

It did also come up with a catalytic converter option which was not present previously, I selected the close cats option.
Attached is the update file that it used.
And thats it folks! All supported protocols are now implemented for J2534. This includes ALDL, VPW, HSCAN and GMLAN.
D-PDU compliance for both ALDL, HSCAN and GMLAN will be the next things to work on. But I will be finalizing the GT's firmware now, ready for the first batch of GTs to be received. I have to implement a timer into the GT for measuring LED time on, since protocols such as Canbus are so fast, that we don't even see it flicker as its ON then OFF within microseconds.

- Attachments
-
- g01srv14.bin
- (120 KiB) Downloaded 101 times
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726

Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726

Re: OBDX Development - Developer Tools and Suggestions
Over the past week iv had a multiple questions in regards to obdx and myself.. I figured I’d put the questions and answers before for those interested:
Q) So does this mean obdx will include tech2win and gds2?
A) No it does not. You have to purchase a license to use those applications from acdelco. All the work I have done is so the obdx tools will work with those dealership softwares. The big advantage here is it significantly lowers the cost for DIYers to use dealership software as a very expensive j2534 is not required.
Q) Can I use it on a “insert non gm vehicle car you have”
A) if it uses standard CANbus then it should be ok to use. But obdx gt has been explicitly designed around GM.
Q) (I’m paraphrasing this one as it was a big message) Aren’t you against reverse engineering?
A) I love to reverse engineer. In fact almost everything I post up is reverse engineering something to understand how it works. Whether it be breaking down GM kernels, or communication to/from dealership software to identify programming or logging routines. I am all for encouraging others to do the same. Part of the command set is explicitly designed around making reverse engineering easier!
Q) I have “insert car here”, can I use the obdx for tuning?
A) OBDX is just the tool, it is not flashing software. For GM, two free flashing applications are LS Droid and PCMHammer.
Q) does Obdx work with efilive or hptuners?
A) No it does not. They use their own proprietary hardware.
Q) Will it work with pcmtec
A) I have not tested yet, but as it is now j2534 compliant with CAN, it should happily work..
Q) (the most common question) When will the obdx gt be available?
A) Hardware is useless without software to go with it. The last month has been a matter of getting the GT support with as many things as possible (just as j2534) so that it has more purpose then just ls droid and pcmhammer
Q) Are you using the GT to build any new software?
A) Sure am! Envyous has not had new ‘public’ software in a long time, Iv been holding off for a long time (6+ years) to have a custom tool to use. There will be a few new additions including 1 for diagnostics, 1 for custom programming and a couple others that’ll stay under wraps for now.
Q) So does this mean obdx will include tech2win and gds2?
A) No it does not. You have to purchase a license to use those applications from acdelco. All the work I have done is so the obdx tools will work with those dealership softwares. The big advantage here is it significantly lowers the cost for DIYers to use dealership software as a very expensive j2534 is not required.
Q) Can I use it on a “insert non gm vehicle car you have”
A) if it uses standard CANbus then it should be ok to use. But obdx gt has been explicitly designed around GM.
Q) (I’m paraphrasing this one as it was a big message) Aren’t you against reverse engineering?
A) I love to reverse engineer. In fact almost everything I post up is reverse engineering something to understand how it works. Whether it be breaking down GM kernels, or communication to/from dealership software to identify programming or logging routines. I am all for encouraging others to do the same. Part of the command set is explicitly designed around making reverse engineering easier!
Q) I have “insert car here”, can I use the obdx for tuning?
A) OBDX is just the tool, it is not flashing software. For GM, two free flashing applications are LS Droid and PCMHammer.
Q) does Obdx work with efilive or hptuners?
A) No it does not. They use their own proprietary hardware.
Q) Will it work with pcmtec
A) I have not tested yet, but as it is now j2534 compliant with CAN, it should happily work..
Q) (the most common question) When will the obdx gt be available?
A) Hardware is useless without software to go with it. The last month has been a matter of getting the GT support with as many things as possible (just as j2534) so that it has more purpose then just ls droid and pcmhammer
Q) Are you using the GT to build any new software?
A) Sure am! Envyous has not had new ‘public’ software in a long time, Iv been holding off for a long time (6+ years) to have a custom tool to use. There will be a few new additions including 1 for diagnostics, 1 for custom programming and a couple others that’ll stay under wraps for now.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726

Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
