pcmhacking.net

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.

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.

@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!

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.

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.

Thats ok, I go on about rants all the time. I dont mind the side missions.

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.

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.

Perhaps you will need
there is a lot about FORD here
https://github.com/jakka351?tab=repositories

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

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.