pcmhacking.net

Highlander wrote:

Tazzi wrote:VE V6, E77.. uses MPC562 also... that should fall inline to being supported also.

Currently tracking down the following ecus:
E39 (VE V6 ECU)
E39a (VF V6 ECU)
E92 (Colorado)
E98 (Colorado)

I have an E98 here, although unfortunately is not mine to strip apart, being held for a conversion. I can use it to get a SPS log but thats about it.

The Colorado V6 is an E82.. the Diesel is E98.

Might as well as that to the list! Ill Ebay stalk a E82 next.

Missed out on a E41 yesterday, it popped up for $100usd, everything else on ebay is like $500. Guess just gotta keep on waiting!

I have a fair few T42, T43 & even the not common T68 file reads if they help.

kur4o wrote:T42 bin have opcodes for 68332 processor in it. If it doesn`t have built in code for read and write will be POS to develop.

I scored a incomplete file of e78. It is 3mb size and you can look for the bin layout here.

e78_decode.txt

I am eager to look at a bin dump for the other pcms.

I've started to map out some of these in tunerpro like boost threshold at 47E20 & cranking fuel EQ at 5A338 but can't for the life of me figure out the row & column axis's the tables are in 16Bit & I'm pretty sure the axis's are 32Bit but don't know how to identify which & where they are for each table for this controller.

VX L67 Getrag wrote: I've started to map out some of these in tunerpro like boost threshold at 47E20 & cranking fuel EQ at 5A338 but can't for the life of me figure out the row & column axis's the tables are in 16Bit & I'm pretty sure the axis's are 32Bit but don't know how to identify which & where they are for each table for this controller.

Being power pc, it maybe makes sense the axis are 32bit.
Got some example data to search in a bin?

Yeah this is a stock 1 I got a while ago...

Quick little update. I found every so often I would get a failed chunk received from the scantool to ECU kernel when writing. It would occur at the exact moment the scantool sends its first CAN frame which indicates its going to send lots of data.
Out of suspicion, I disabled the kernels tester present message.. and the problem disappeared.

When the scantool sends the request to upload data, the kernel responds back with a flow control message ( 7E8,30,00,00 - As per SAE spec), but instantly after the flow control, the kernel was firing off a tester present frame (As its been over 1 second since last one).

Now the issue with it sending the tester frame instantly after a flow control frame is this cleared the interrupts register flags which included clearing incoming messages flag.
This meant the Kernel was missing the first data frame after the flow control as it was cleared when sending the tester present message. Now to top that off, is the hard coded delay I had after each CAN frame write in the kernel was right on the border of missing the first data frame, so if the kernel detects requiring to send a tester present right after the flow control message, it would then miss that frame from the scantool, hence block write would fail.
Soooooo... a proper CAN transmit check is implemented instead of a (hackish) delay between frames in the write routine.

This then completely trolled me by breaking the ECU reading. The kernel was then firing off CAN frames at absolute max speed (less than half a millisecond apart) so the scantool could not keep up!
A hard coded delay between frames for the read routine is now implemented which has everything working correctly.

Anyways.. wasnt expecting to do more kernel work tonight.. but it was bugging me to see the occasional chunk miss when I know there shouldnt be a reason for it. Only way I justify the time spent is it will be applicable for all future kernels realistically

I am now officially at the absolute maximum kernel size so more additions really isnt possible without moving all variables further up into the ram as the kernel runs right up to the edge of the variables ram location.

As for software updates, I now have implemented a CRC check before writing (no point writing if its a match) along with CRC after writing to ensure its a perfect match. OS writes are currently only using a SUM due to the fairly large wait time for them.

Thats it for tonight! Sorry if the above is a little bit boring!

Not boring in any way whatsoever... It is mostly over my head, but I do have the gist of it, and it is making me read up on and research on my own even with the lack of information out there.. I need to work on how to use a Jtool with C++ instead of just the elm.. No idea on where to start, but I am working on it..

Just how big is your kernel?, and this is primarily just for the E38 so far, but may cross over to additional ECU's? Or are you trying to write a universal kernel for every ECU you'd run across?? I know it worked in the E67 as far as reading? but should it be able to write as well??

ironduke wrote:Not boring in any way whatsoever... It is mostly over my head, but I do have the gist of it, and it is making me read up on and research on my own even with the lack of information out there.. I need to work on how to use a Jtool with C++ instead of just the elm.. No idea on where to start, but I am working on it..

Just how big is your kernel?, and this is primarily just for the E38 so far, but may cross over to additional ECU's? Or are you trying to write a universal kernel for every ECU you'd run across?? I know it worked in the E67 as far as reading? but should it be able to write as well??

Read through the J2534-1 SAE technical document to get a better understanding of the commands needed and used by J2534 compliant tools.

The kernel is exactly 0x1000 bytes (4096bytes). The kernel is currently setup for reading and writing on both E38 and E67 since they are (almost) identical for reading/writing other than a slave chip difference. I have tested on both and works happily.
I wont be going for a universal kernel, it would get way too big and complicated to support too many CPU variants will have to make new kernels for other ECUs such as E77, E98 ect.
Most of the major functions in the kernel will be reused, just a matter of updating the core functions to suit the CPU and flash chip if external.

I now understand why NXP developed VLE commands for the newer processors, since most ASM functions can be reduced to 2 bytes, meaning it could basically reduce my entire kernel to half its size

*Edit
Once I have the software to a stage I am happy with for people to use, will need to put focus towards what ecu to mess with next! Theres a good 6-7 here now.. might need to take votes on the next to mess with

Couple little bugs I picked up on, if I disconnected the ECU while reading, it caused the application to jump to the next chunk (which it shouldnt do), so it would report as read completed in a matter of seconds
Simple little mistake on the error handling side for a case I had not added any coding to. It will now reattempt a chunk 10 times before it gives the user a prompt to retry again or to exit routine.

In the event of a failed read or write, the application is leaving the kernel running instead of ending it. I feel that is the safest approach

I do have to admit the application is quickly getting quite large. It *should* make adding new ecus/kernels fairly straight forward though, although am having to forward plan everything so everything can be modified to suit different ecu requirements. If the application can happily differentiate between E67 and E38, then its just a matter of copy/paste to add new ecus.

I am having a bit of a time working out the best course of action for a couple things:
1) Identification from bin - Im thinking my ECU library class needs to have a function specifically called "Analyse Bin" which can look for unique markers for that specific ECU. That way a simple loop through all defined ecus can be performed.
2) Upon verifying the ECU type for a bin, it can then validate the CRC/checksum for each segment to ensure its valid. In the event a segment is bad, Im assuming the application should just reject the file completely? Since any tampered files is a brick waiting to happen.
3) How many warnings screens should someone go through before being allowed to write OS+cal or clone? I feel like a good 2.. and if its a mismatched OS.... 4

Taz, who's your intended target / end user of your app?

I assume with the amount of time your putting into it your not making it freeware.