PCMTec Development Blog

[rolls]

BF would be best, if you don't want it back up do some "destructive" testing on it to see what will brick them.

[MeZmeriZe]

BF would be best, if you don't want it back up do some "destructive" testing on it to see what will brick them.

I have a ton of PCM's of all three models.. and I can get more as needed. If you want one Rolls, just msg the postal address and one will arrive pronto. I can get you another PCM plug too if you wish.

In other news, I had a BF NA manual come though to get fixed and wasn't talking to the BCM or anything so nothing in the car was working, but the engine ran fine... Even weirder it started multiple times without the PATS chip reader plugged in.
Turns out the guy just bought the car and the previous owner seems to have stuck a PCM in that has been made standalone.. meaning it can be used without all the other stuff in a falcon to run the engine for conversions and stuff.

Figured if we got a copy of that tune (The guy already offered) we can get the same tune via PHF without the mods and compare to see what was changed to make it stand alone and disable PATS.

Is that something of interest to anyone?

[VX L67 Getrag]

yeah ive tested that sort of stuff & you'll probably find wrong vin & the pats(both reversed from stock).

[headsex]

You are describing live tuning. That means writing a custom OS. BE does not do that for the PPC platform.

"Waves"... Hi Guys

Mine implimentation is a little crude however. the smarts was more on the obd communications / initialization. Ie, the binary was patched with appropriate tables pointing to RAM offsets instead, upon power up, i manually wrote those ram values before starting the engine. I didn't go to the extreme by implementing a copy to ram on startup functionality like others have done ie, Cobb in the GTR's.

It is a huge amount of work. It will require writing your own recompiler (weeks of work to do that alone) as nothing exists for PPC that I'm aware of. Probably over a months work fulltime if you know what you are doing.

Lots of work! However, a recompiler was not needed. All my work was done (painfully) in asm using IDA to verify my patch work.

Here's my claim in the Aussie PPC world.

[youtube]https://www.youtube.com/watch?v=ufQknKigHk4[/youtube]

Anyways, I've been through all of this years ago.. Currently use my own solution to tune Aussie ford vehicles. I often wondered about releasing just a reader/flasher as per the openecu and see what starts in the ford world.
I also did consider selling my product, however, where i lacked was the ability to keep up with the new strategies, and developing the definition data for them. I did try to made some scripts for IDA, but I never got fast enough at unwrapping it all to asm. Each strategy takes me a good few days to get it to a point i can work with.

[headsex]

"Live tuning can be done, but need a dev PCM from Visteon"

That is an interesting thought.. wonder how you'd go about getting one of those.... probably not cheap even if they would sell them to normal folks.

Essentially a Dev PCM has a custom cpu board in place of the normal footprint of the pcb. https://www.accuratetechnologies.com/ECUInterfaces/M6

The only give away of ford dev computers it that the case is screwed shut, not glued... I've seen a couple in my day.

Hptuners have a mod to allow 3bar boost sensor, whilst it isn't a huge modification it is technically a custom OS.

No, Not a custom OS.. Its not a "mod" either.. They have just exposed the calibration values needed to adjust the slope and offset of the Map sensor... I did this over 5 years ago. Reason HPT or SCT didn't show it was possibly due to it being a double float precision and their software didnt support it at the time.

I don't write anything before 0x10000 and neither does hpt afaik. What address is that string at?

I'll take a look when I can mate I'm pretty sure it was 0xEFFE.
Would you be able to write before Ox10000? That would make the perfect cloned ECU if you could? well software side anyway.

You actually CANT write before 0x10000.. Proof? do a full erase (0xAA), and read back entire pcm, the RTOS/Bootloader data below 0x10000 will still be there, however, everything above that address is 0xFF... Been erased.
During my flasher development, I determined how to do Cal Only reflashing (i can flash a BA in 15 seconds, and a BF/FG in 25 seconds). I determined there was actually NO way to erase 0x0 - 0x10000. However, I did manage to erase one of the onboard Flash chips which was for the drive by wire watchdog i think? (whoops).

In summery, You have to erase the associated memory block before you write to it. Flash memory 101

[headsex]

Rolls, I also suggest that having an editor that works with just plain raw bin files can lead to issues like associated with the twin memory banks of the BA.

You don't really want to have to have offset manipulation build into your editor.. ie, you want to have definition data be true memory address.

This was my biggest mistake with my initial application. I was constantly working with a algorithm to get me from the real definition address to what it was in the file.

In the end, I ended up writing code that creates files, which maintains their true memory location. much like a PHF/Hex file has the address in every line... But that Hex format is so 80's!

Idea's I've gained from this example - https://ssm.codeplex.com/SourceControl/ ... geRange.cs

[rolls]

"Waves"... Hi Guys

Mine implimentation is a little crude however. the smarts was more on the obd communications / initialization. Ie, the binary was patched with appropriate tables pointing to RAM offsets instead, upon power up, i manually wrote those ram values before starting the engine. I didn't go to the extreme by implementing a copy to ram on startup functionality like others have done ie, Cobb in the GTR's.

Anyways, I've been through all of this years ago.. Currently use my own solution to tune Aussie ford vehicles. I often wondered about releasing just a reader/flasher as per the openecu and see what starts in the ford world.
I also did consider selling my product, however, where i lacked was the ability to keep up with the new strategies, and developing the definition data for them. I did try to made some scripts for IDA, but I never got fast enough at unwrapping it all to asm. Each strategy takes me a good few days to get it to a point i can work with.

Wow sounds like you've been around the block a few times! Good to see this thread bringing some people out of the wood work.

I like the proof of concept of initialising the RAM via OBD, very easy to simply patch the address to load from r13 instead of r2 vs writing a full init routine. Only problem is you need to write a custom OS to the PCM, do live tuning then revert, still very cool. I wasn't sure if the PCM would crash due to a null pointer if the car wasn't running, interesting to see it doesn't even execute the code and hence is fine, makes for a great proof of concept!

So you are a tuner that has done this for your own commercial use? Pretty interesting, did you do this all via CAN over an AVT cable, or you used J2534? Do you have a coding background?

Developing definitions for all cars is definitely a hurdle, we have managed to come up with some algorithms that will use a base strategy (several actually) and compare an unknown bin to it and find all the same maps, parameters and DMRs. This means we can auto generate definitions and datalogging for all BA/BF/FG falcons, V8 and I6. The algorithm matches about ~4000 parameters currently, not everything but all of the important stuff anyway. The other benefit of this is there is no manual labour, it means far less human errors. I've seen quite a few errors in the HPT stuff due to like you said the double precision floats and also simple mapping errors, we hope to avoid this. Once we generate the definitions we have a verification algorithm as well which checks that they are indeed mapped correctly.

Essentially a Dev PCM has a custom cpu board in place of the normal footprint of the pcb. https://www.accuratetechnologies.com/ECUInterfaces/M6

The only give away of ford dev computers it that the case is screwed shut, not glued... I've seen a couple in my day.

No, Not a custom OS.. Its not a "mod" either.. They have just exposed the calibration values needed to adjust the slope and offset of the Map sensor... I did this over 5 years ago. Reason HPT or SCT didn't show it was possibly due to it being a double float precision and their software didnt support it at the time.

You actually CANT write before 0x10000.. Proof? do a full erase (0xAA), and read back entire pcm, the RTOS/Bootloader data below 0x10000 will still be there, however, everything above that address is 0xFF... Been erased.
During my flasher development, I determined how to do Cal Only reflashing (i can flash a BA in 15 seconds, and a BF/FG in 25 seconds). I determined there was actually NO way to erase 0x0 - 0x10000. However, I did manage to erase one of the onboard Flash chips which was for the drive by wire watchdog i think? (whoops).

In summery, You have to erase the associated memory block before you write to it. Flash memory 101

What does the dev kit actually support over the stock ecu? A flash chip that can be written and debugged live?

Regarding the MAP sensor I'm surprised more people didn't add it sooner, it is not a big change like you said, just modding some values.

I actually tested this out a few days ago with another PCM and found the same results. Eg that it won't erase and won't write below 0x10000. I even went digging in the binary to see if there were any other hidden erase commands but the command handler only accepts the one erase command for the flash (at least that I could find). There are some benefits of this, it makes bricking the PCM close to impossible.

Writing calibration only is a good idea, far less data to write, however writing the software to do so could be prone to error. For simplicity sake I think I will stick to full writes or at least just large blocks only in the short term, the ~50 seconds the BF/FG take is not long.

Rolls, I also suggest that having an editor that works with just plain raw bin files can lead to issues like associated with the twin memory banks of the BA.

You don't really want to have to have offset manipulation build into your editor.. ie, you want to have definition data be true memory address.

This was my biggest mistake with my initial application. I was constantly working with a algorithm to get me from the real definition address to what it was in the file.

In the end, I ended up writing code that creates files, which maintains their true memory location. much like a PHF/Hex file has the address in every line... But that Hex format is so 80's!

Idea's I've gained from this example - https://ssm.codeplex.com/SourceControl/ ... geRange.cs

I simply used full size files for the BA/BF. Eg a 1mb or 6mb binary with a load of nulls in the middle which I load as a simple byte array and address directly. Much easier to code, no offsets to worry about and RAM/HD space is basically free these days. I really wanted to avoid the problem of offsets that you describe.

[rolls]

BF would be best, if you don't want it back up do some "destructive" testing on it to see what will brick them.

I have a ton of PCM's of all three models.. and I can get more as needed. If you want one Rolls, just msg the postal address and one will arrive pronto. I can get you another PCM plug too if you wish.

In other news, I had a BF NA manual come though to get fixed and wasn't talking to the BCM or anything so nothing in the car was working, but the engine ran fine... Even weirder it started multiple times without the PATS chip reader plugged in.
Turns out the guy just bought the car and the previous owner seems to have stuck a PCM in that has been made standalone.. meaning it can be used without all the other stuff in a falcon to run the engine for conversions and stuff.

Figured if we got a copy of that tune (The guy already offered) we can get the same tune via PHF without the mods and compare to see what was changed to make it stand alone and disable PATS.

Is that something of interest to anyone?

Someone already sent one off but thanks for the offer! I'll let you know if I ever need another.

So why isn't the BCM talking to the ECU? Be interesting to see what is in the PCM, I suspect its had all the PATS stuff disabled. Let me know if you get a copy.

[headsex]

Wow sounds like you've been around the block a few times! Good to see this thread bringing some people out of the wood work.

I like the proof of concept of initialising the RAM via OBD, very easy to simply patch the address to load from r13 instead of r2 vs writing a full init routine. Only problem is you need to write a custom OS to the PCM, do live tuning then revert, still very cool. I wasn't sure if the PCM would crash due to a null pointer if the car wasn't running, interesting to see it doesn't even execute the code and hence is fine, makes for a great proof of concept!

So you are a tuner that has done this for your own commercial use? Pretty interesting, did you do this all via CAN over an AVT cable, or you used J2534? Do you have a coding background?

Developing definitions for all cars is definitely a hurdle, we have managed to come up with some algorithms that will use a base strategy (several actually) and compare an unknown bin to it and find all the same maps, parameters and DMRs. This means we can auto generate definitions and datalogging for all BA/BF/FG falcons, V8 and I6. The algorithm matches about ~4000 parameters currently, not everything but all of the important stuff anyway. The other benefit of this is there is no manual labour, it means far less human errors. I've seen quite a few errors in the HPT stuff due to like you said the double precision floats and also simple mapping errors, we hope to avoid this. Once we generate the definitions we have a verification algorithm as well which checks that they are indeed mapped correctly.

Yeah, use custom OS, for the real time tuning. As part of the initialisation, i did insert code to populate it with dummy numbers to prevent that issue, but yeah, changing the pointer part was easy, and making sure that part of the ram isn't used was also part of the challenge. Once you are done, you then write the changes in to a normal OS.. I didn't progress much further but to prove i could run a table from RAM and real time it. As you've found, this all takes alot of time! The reward of the personal accomplishment however is very good

I have been "hacking" these things for years. Originally started on the LS1, but lost interest fast due to not having a LS vehicle. I got involved with a former owner of SCT prior to them making the Aussie stuff available for development and testing purposes on the pre oak (eec-v) processor. I then got interested in the powerppc stuff, with plans to conquer the world (got to have goals right?.. lol). I'm also quite well known Tuner in the Ford XR6 Turbo tuning community here in vic (well Australia wide infact). But this really is only a hobby to me, I'm not a coder by trade either, all self taught.

Unfortunately when i started with this, the only cable/device available to me was either, make it myself (pass), or the Cardaq plus which was a ~$3000AUD purchase at the time, You guys have it lucky now with the openport2..

Definition data certainly is where I had difficulty, it was very manual, and given the complexity of these strategies, certainly there is ALOT of values you want to expose to the end tuner. It was interesting to read the system you've come up with. SCT also isnt without its definition errors. Eric however, has done real well in bringing HPTuners into the game with its Ford support.

What does the dev kit actually support over the stock ecu? A flash chip that can be written and debugged live?

Regarding the MAP sensor I'm surprised more people didn't add it sooner, it is not a big change like you said, just modding some values.

I actually tested this out a few days ago with another PCM and found the same results. Eg that it won't erase and won't write below 0x10000. I even went digging in the binary to see if there were any other hidden erase commands but the command handler only accepts the one erase command for the flash (at least that I could find). There are some benefits of this, it makes bricking the PCM close to impossible.

Writing calibration only is a good idea, far less data to write, however writing the software to do so could be prone to error. For simplicity sake I think I will stick to full writes or at least just large blocks only in the short term, the ~50 seconds the BF/FG take is not long.

I simply used full size files for the BA/BF. Eg a 1mb or 6mb binary with a load of nulls in the middle. Much easier to code, no offsets to worry about and RAM/HD space is basically free these days. I really wanted to avoid the problem of offsets that you describe.

The Dev pcm had a custom OS on it, which has XCP / CCP extensions to allow read / write to the additional memory onboard the M6 Tab. You could prob find out more here - https://www.accuratetechnologies.com/ECUCalibration
Accurate Technologies is actually the product suite of software Ford/Visteon use for their calibration products from what i've been told.

In terms of the erase/bootloader routine. I never studied it from a ASM level, i just brude forced all values from 0x00 to 0xFF (including 0xAA) to see the result.

Implementing the Calibration only write (particularly for the BA's which 443kb mpc555 flash was slow!!) saved my sanity. Think back when SCT released their XCAL1. It was serial interface to the PC, 115200 baud.. So, you make a change to your file, upload the 1.4mb file to the XCAL1 (took about 5 minutes), and then flash the PCM (another 5 minutes).. thats like 10 minutes (or more) of wasted time, because usually you'd walk away from the PC at the first step!
So, yeah.. Sanity saved! Unfortunately for Workshops, they still have a ~4minute wait for the flash, as transferring the file to the xcal now is via USB, and relatively fast these days.

In terms of the file, yeah, full size is ok, but do you include the 0x0 -> 0x10000 in that file? of not, you already have a need for a -0x10000 offset. My view on the subject is bigger, Ie, not to limit your editing software to just this purpose, but makes it available for all micro controller types.. Also, ZF transmission, from memory, the Calibration data (the only data you need to write) will give you large files with null at the start, when the entire cal section is only about 100k in size.. Its just my suggestion, You will thank me later.. Once you have it in a non raw format, you could always write a exporter which exports it to HEX, to be able to open in IDA, so best of both worlds there.

I'm also surprised you mentioned PHF, as I believe ford moved away from that format to VBF, which, out of all things is a Volvo format (volvo binary file?).. Its a very cool format, I'll have to try and find references online that i found years ago for you to look at.

I haven't had a chance to look at your code on github, however, i read in this thread you've changed timeout values a number of time.. I spent alot of time optimising my code that interfaced with the j2543 dll / PCM to improve speed significantly.. Of what you've noticed, yeah, the BA can take OVER 1 minute to erase in some instances, HPTuners was bricking PCM's at one point cause they didnt cater for this excessive period, assumed 40 seconds was enough.. (bricking in the sence of blanking out the pcm, and not writing to it).
In terms of the transfer loops to send and receive data on the bus, with the j2534 read command, i would only requested 1 message, with a large timeout (ie, 5 seconds). If no data is read from the pcm, the app would loop the request. this reduced the talk between the app and passthru device, and the moment it had data, the app had it. When writing, I always made the timeout 0. Took me a while to determine this was fastest way of doing it, as it wouldnt hammer the passthru dll/device with huge amount of requests.

[headsex]

Oh, furthermore, given that you cant erase the bootloader code, you cant change the seed/key algorithm in order to "lock" these pcms, like you can in the GM world.
Its interesting to see how SCT have attempted to stop HPtuners Reading the tunes. They appear to be garbling the Strategy text in the VID block, this is given away by the fact that when you read the strategy (via the xcal hand held, or hptuners), its non english characters. As a result, it makes it difficult for hptuners to know what definition file to associated with the file you just read.
Hptuners however don't appear to garble the strategy in order to "lock" the tune.. It appears they have implemented some additional data in the file written to the pcm.. Presumably to lock the tune between HPtuner customers.