OBDX Development - Developer Tools and Suggestions

Programs / Tools / Scripts
User avatar
Tazzi
Posts: 3431
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

antus wrote:@tazzi I dont read that the same as you describe. I think the length is the size of the total payload across multiple frames, and it is sent in smaller packets, segmented. So rather than the application layer knowing what each segement is and reassembling it in the application part of the code, it can be done by the can layer, but you still don't need to handle packets 32kb in size (and that piece of doc doesn't specify the maximum segment size, which may still be different between different interfaces similar to what we see on some current gen interfaces and J2534). So it'd be something like first frame says 128Kb payload. Second frame has a 4k payload, third frame has a 4k payload, and so on and so on, until the whole 128Kb is transmitted. Then the can layer in the pcm could reassemble it and provide the payload to the app as a single piece of data.
I thought the same. And you are correct that you inform the module that it needs to prepare for "X" size flash or memory space. But based on the J2534 document and ISO document, it indicates the chunk size can now be larger then 4095 bytes. The CAN packet itself can be between 0 to 64bytes long, but the actual size of all the multiple packets sent can be larger then 4095.

They had to create a custom command in J2534 4.04 that allows loading up an "extended TXD buffer" and also a "extended RXD buffer" that handles these larger frames.

The document goes further to demonstrate how the new system works on the protocol level.. where an example frame could be:

7E0 10 00 01 02 03 04 00 00
7E8 30 00 00
7E0 21 11 22 33 44 55 66 77
7E0 22 88 99 AA BB CC DD EE

Where 01020304 would be the length, and the data bytes would be: 11 22 33 44 55 66 77 88 99 AA BB CC DD EE.

Its basically identical to how a 4095 chunk would be sent, except the length bytes at the top are done differently to allow for a 4byte length, plus each packet could be 64bytes at a time.

Our next generation of tools will be using the big brother processor of the current chip we use (That has triple CAN), I believe it has 512k flash and 256k ram.. so we should be golden when that time comes around. :thumbup:
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
acln99
Posts: 27
Joined: Fri Feb 22, 2019 3:32 am
cars: Dodge Ram
Location: Ontario, Canada

Re: OBDX Development - Developer Tools and Suggestions

Post by acln99 »

7E0 10 00 01 02 03 04 00 00
7E8 30 00 00
7E0 21 11 22 33 44 55 66 77
7E0 22 88 99 AA BB CC DD EE

The "Yat-Log" a few pages back shows the complete Flash being downloaded in that style.
User avatar
antus
Site Admin
Posts: 8253
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: OBDX Development - Developer Tools and Suggestions

Post by antus »

@tazzi Well so long as your individual packet size is 64 bytes at a time, that's all the ram you need in your interface, the rest you can do in a the driver on the PC side, though that would require a standalone driver and driver signing. Swings and roundabouts!
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: 3431
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

antus wrote:@tazzi Well so long as your individual packet size is 64 bytes at a time, that's all the ram you need in your interface, the rest you can do in a the driver on the PC side, though that would require a standalone driver and driver signing. Swings and roundabouts!
Yeah, it might take a little bit of trial and error, but i think we could load up a buffer to start sending, then refill a secondary buffer while the first is sending, then just keep switching between them like that.

Preferably just moving to a big processor will fix all the problems. But adding CAN FD isn't really much code currently other then allow for 64byte frames. :thumbup:
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
kur4o
Posts: 953
Joined: Sun Apr 10, 2016 9:20 pm

Re: OBDX Development - Developer Tools and Suggestions

Post by kur4o »

Only data that matches flow control filters will be logged in iso15675 protocol.
In this case any message that starts with 00 07 e0 or 00 00 07e8.

I think it is time to clean the thread and move some of the posts to a new thread called Ford and Chrysler pcm hacks.

It got really off topic at one point.
User avatar
Tazzi
Posts: 3431
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

Thats ok, I go on about rants all the time. I dont mind the side missions. :lol:
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
Tazzi
Posts: 3431
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

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.

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.

But... still no high speed request. It stayed at the same baud rate the whole time through. :roll:

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.
Attachments
BVTX4J32 02-04-2015 18.49.04.txt.zip
(769.38 KiB) Downloaded 44 times
Ford AU Falcon PWM 1R23ED_NGIC9E8-20150204-184737.bin
(224 KiB) Downloaded 45 times
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
kostia111
Posts: 48
Joined: Mon Oct 21, 2019 4:58 am

Re: OBDX Development - Developer Tools and Suggestions

Post by kostia111 »

Perhaps you will need
there is a lot about FORD here
https://github.com/jakka351?tab=repositories
User avatar
Gampy
Posts: 2333
Joined: Sat Dec 15, 2018 7:38 am

Re: OBDX Development - Developer Tools and Suggestions

Post by Gampy »

Another off topic continuation ...

In UP Logger J-Console the 1 liner text box under the log pane is a command prompt ??
What is the exact format to get something like the pid list 0100 or VIN 0902 using ISO15765 on this NGC4.

Seems whatever I try either errors or does nothing ...

I can use an ELM with a terminal, send the commands and UP Logger does log them, I just can't send from J-Console command prompt (if thats what it is?).

Thanks

-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!
kur4o
Posts: 953
Joined: Sun Apr 10, 2016 9:20 pm

Re: OBDX Development - Developer Tools and Suggestions

Post by kur4o »

00 00 07 e0 09 02

this should work. At least it works with gm stuff
[14:26:26.271] 00 00 07 E0 09 02
[14:26:26.481] 00 00 07 E8 49 02 01 4B 4C 37 43 4A 4B 53 42 58 47 42 36 33 33 39 37 36


Format needs to follow the flow control filters node.

If you set flow filter 00 00 07 e0<-> 00 00 07 e8 you can send only to node 00 00 07 e0 and get response from 00 00 07 e8

Each module have flow IDs, and diagnostic ID. They differ so you need to find a way to log it, or read some leaked documents how they are set.
In raw can you can try sending
00 00 01 01 FE 01 28 00 00 00 00 00

Each module on bus should respond.
Post Reply