OBDX Development - Developer Tools and Suggestions
Re: OBDX Development - Developer Tools and Suggestions
Looks like dodge don`t like GM code.
Last attempt, removed all bloatware, only 1a XX left.
Hope it spits out something at the end.
The vehicle is indeed a very special one, We will be very careful, and use purple gloves for experiments.
At least we should get the bin out of it.
Last attempt, removed all bloatware, only 1a XX left.
Hope it spits out something at the end.
The vehicle is indeed a very special one, We will be very careful, and use purple gloves for experiments.
At least we should get the bin out of it.
- Attachments
-
- ISO15765_1a_no_bloatware_ngc4.txt
- (87 Bytes) Downloaded 50 times
Re: OBDX Development - Developer Tools and Suggestions
kur4o,
I can send some of the commands from the scripts with PuTTY and a STN1110 and they work, UPLogger even logs them ...
However if UPLogger sends commands, nothing happens ... there is something not right.
This ngc4 does not like the 1a's, even from PuTTY and ELM.
-Enjoy
I can send some of the commands from the scripts with PuTTY and a STN1110 and they work, UPLogger even logs them ...
However if UPLogger sends commands, nothing happens ... there is something not right.
This ngc4 does not like the 1a's, even from PuTTY and ELM.
-Enjoy
Intelligence is in the details!
It is easier not to learn bad habits, then it is to break them!
If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
It is easier not to learn bad habits, then it is to break them!
If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
Re: OBDX Development - Developer Tools and Suggestions
I'm having same issue with NGC4 . With ELM commands like 09 02 read VIN . Direct send to PCM doesn't work yet. I think I have the msg format wrong...Gampy wrote:kur4o,
I can send some of the commands from the scripts with PuTTY and a STN1110 and they work, UPLogger even logs them ...
However if UPLogger sends commands, nothing happens ... there is something not right.
This ngc4 does not like the 1a's, even from PuTTY and ELM.
-Enjoy
What command from the script does receive a response? ( I don't have same tool as you to actually run the scripts )
Re: OBDX Development - Developer Tools and Suggestions
Oh heck, I don't remember, I know that 1axx and 22xx do not ... 0101 does.
Read VIN 0902 works, get pids 0100 works but they are required standards here in the US.
Edit:
Everything that works, works thru PuTTY and the STN1110, nothing works from UPLogger command prompt or scripts.
-Enjoy
Read VIN 0902 works, get pids 0100 works but they are required standards here in the US.
Edit:
Everything that works, works thru PuTTY and the STN1110, nothing works from UPLogger command prompt or scripts.
-Enjoy
Intelligence is in the details!
It is easier not to learn bad habits, then it is to break them!
If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
It is easier not to learn bad habits, then it is to break them!
If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
Re: OBDX Development - Developer Tools and Suggestions
In-Tech wrote:64 10 F1 31 A0 00 D8 01 00 BC
C4 F1 10 7F 31 A0 00 D8 00 91 Still not sure why the Ford stuff replies with what would normally be a fail 7F ???
64 10 F1 27 01 48
C4 F1 10 67 01 78 79 0B F4
64 10 F1 27 02 87 41 BC
C4 F1 10 67 02 34 A3
C4 10 F1 35 01 04 00 00 20 00 92 request 1024 bytes(0400h) starting at address 002000
C4 F1 10 7F 35 01 04 00 00 0D
C4 F1 10 36 FF FA 27 FE FF FF 33 6 bytes of read at address 002000
C4 F1 10 36 FF FF FF FF FF FF 7B Continues next 6 bytes read
C4 F1 10 36 FF FF FF FF 60 20 E6
C4 F1 10 36 63 20 66 20 69 20 4A
C4 F1 10 36 6C 20 6F 20 72 20 B4
C4 F1 10 36 75 20 78 20 7D 20 9E
C4 F1 10 36 82 20 87 20 8C 20 95
C4 F1 10 36 91 20 96 20 9B 20 BE
It does seem to be the 31 A0 is required with this Ford stuff, before it will allow a proper seed/key. otherwise just nonsense. I dunno, just watching
I'm back, a great time but what a shit showIn-Tech wrote:Hiya Guys,
Unfortunately, I will not be able to test this quickly. I am on my way to Vegas for the Mint400 off-road race. I should be back Sunday night, late. I will report back as soon as I can get my work station set up to reply with better answers. I've always wanted to know how long FEPS needs to be active so it will be a good test. Sorry I can't comply quickly.
My setup says to cycle the key(3 seconds offkur4o wrote:Thanks for the logs. In short summary, I figured some of the missing pieces and how to set j-tool to monitor all data on pwm bus.Tazzi wrote:I have successfully read the AU Falcon ECU on the bench. Attached in the .bin and also a VCM2 log of it reading!
So my ECU is a 3byte seed and 2byte key as per the previous unlocks we have seen by Intech. Yay
24 10 F5 27 01
C4 F5 10 67 01 57 59 BC
24 10 F5 27 02 00 CD
C4 F5 10 67 02 34
We can see the seed is 57 59 BD and key is 00 CD
I can confirm this is correct using the unlock algo which matches.
It then does another unlock almost immediately after the first one:
24 10 F5 27 01
C4 F5 10 67 01 37 38 2C
24 10 F5 27 02 DA 64
C4 F5 10 67 02 34
Seed is 37 38 2C and key is DA 64, this also works when applying the second key derivative.
And after that.. it reads the memory. It doesnt take very long to be honest, its quite fast. How long does a dump take for you? Are you starting at 002000h or ??? My read in standard speed takes about 2.5 minutes.
But... still no high speed request. It stayed at the same baud rate the whole time through.
I feel like Im chasing a mythical ability at this point! Id rather not base my coding off of dealing only with a simulating PWM highspeed requests on a scantool, Id rather actually get live data from an ecu since its real results including time interval between IFR bytes and end of frame bytes.
I should be able to just half the timings I currently use for it to be correct.. but again, I want to know its right first.
The feps is also applied on all the time during the read/write event. I noticed it took 10 seconds for pcm to send 00 05 message after feps been on. Does this require some ignition cycling or it is some security timeout.
Re: OBDX Development - Developer Tools and Suggestions
I apologize, all the questions I had asked about time was answered looking through Tazzi's log. I will reply shortly with what I see and comment on it
edit, here is what I see from Tazzi's log of the EecV. Of course I could be completely wrong, lol. What I see here is mode 23 being used after the dual seed/key that mine didn't do. Is this part of the high speed?
edit, here is what I see from Tazzi's log of the EecV. Of course I could be completely wrong, lol. What I see here is mode 23 being used after the dual seed/key that mine didn't do. Is this part of the high speed?
Code: Select all
24 10 F5 31 A0 00 D8 01 01 Mode $31 - Enter/start Diagnostic Routine by Test Number
C4 F5 10 7F 31 A0 00 D8 00 7F - Accept test mode
24 10 F5 27 01 Request Seed
C4 F5 10 67 01 57 59 BC Seed is 57 59 BC
24 10 F5 27 02 00 CD Key is 00 CD
C4 F5 10 67 02 34 7F - Key Accepted
24 10 F5 27 01 Request Seed again
C4 F5 10 67 01 37 38 2C Seed is 37 38 2C
24 10 F5 27 02 DA 64 Key is DA 64
C4 F5 10 67 02 34 7F - Key Accepted
24 10 F5 23 09 FF 14 Mode 23 Request Diagnostic Data by Memory Address (RAM???)
C4 F5 10 63 FF 14 31 52 32 33 Mode 63 Report Diagnostic Data by Memory Address
24 10 F5 23 09 FF 18 Mode 23 Request Diagnostic Data by Memory Address
C4 F5 10 63 FF 18 45 44 20 2A Mode 63 Report Diagnostic Data by Memory Address
24 10 F5 23 09 FF 06 Mode 23 Request Diagnostic Data by Memory Address
C4 F5 10 63 FF 06 4E 47 49 43 Mode 63 Report Diagnostic Data by Memory Address
24 10 F5 23 09 FF 0A Mode 23 Request Diagnostic Data by Memory Address
C4 F5 10 63 FF 0A 39 45 38 2E Mode 63 Report Diagnostic Data by Memory Address
24 10 F5 35 80 02 00 00 20 00 Mode 35 Request 0200h(512d) bytes from address 002000h
C4 F5 10 7F 35 80 02 00 00 7F Accepted
On 02/04/2015 at 18:50:02.220, <<< Start time of read
C4 F5 10 36 FF FA 27 FE FF FF <<< Mode 36 Report first 6 bytes at 002000h
...
C4 F5 10 36 FF FF 00 00 00 00 <<< Report last 6 bytes of final block padded with 00's at end.
24 10 F5 37 80 Mode 37 Request Stop Data Transfer
C4 F5 10 7F 37 80 00 00 00 7F Accepted
On 02/04/2015 at 18:51:47.442, <<< End time of read
Code: Select all
EecV Memory Map
Name Address Physical Address Size
Bank_0 Bank 0 0x02000-0x0FFFE 0xE000
Bank_8 Bank 8 0x82000-0x8FFFE 0xE000
Bank_9 Bank 9 0x92000-0x9FEFE 0xE000
Bank_1 Bank 1 0x12000-0x1DFFE 0xC000
Mode 23 Request Diagnostic Data by Memory Address
Mode 63 Report Diagnostic Data by Memory Address
Last edited by In-Tech on Tue Mar 14, 2023 12:10 am, edited 1 time in total.
Re: OBDX Development - Developer Tools and Suggestions
I believe the second unlock is required before being able to request high speed, but it doesn't appear this ECU supports it or the application simply does not use high speed.In-Tech wrote:I apologize, all the questions I had asked about time was answered looking through Tazzi's log. I will reply shortly with what I see and comment on it
edit, here is what I see from Tazzi's log of the EecV. Of course I could be completely wrong, lol. What I see here is mode 23 being used after the dual seed/key that mine didn't do. Is this part of the high speed?
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 agree, it appears to do the work but then it isn't used. When I can hook up some later Ford stuff, I will check again. Thanks Tazzi, let me know if I can helpTazzi wrote:I believe the second unlock is required before being able to request high speed, but it doesn't appear this ECU supports it or the application simply does not use high speed.In-Tech wrote:I apologize, all the questions I had asked about time was answered looking through Tazzi's log. I will reply shortly with what I see and comment on it
edit, here is what I see from Tazzi's log of the EecV. Of course I could be completely wrong, lol. What I see here is mode 23 being used after the dual seed/key that mine didn't do. Is this part of the high speed?
Re: OBDX Development - Developer Tools and Suggestions
Already done more than enough! Have saved me probably a couple weeks of reverse engineering!In-Tech wrote:let me know if I can help
I just need to finish my own website overhaul due to the theme becoming no longer updated to meet requirements.
Should be finished by tomorrow before hitting this project again.
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
Hi Gampy - Have you had any break throughs on this. I also still can't get commands to work? Monitoring/reading traffic works fine.Gampy wrote:Oh heck, I don't remember, I know that 1axx and 22xx do not ... 0101 does.
Read VIN 0902 works, get pids 0100 works but they are required standards here in the US.
Edit:
Everything that works, works thru PuTTY and the STN1110, nothing works from UPLogger command prompt or scripts.
-Enjoy