pcmhacking.net

Ok we have our first possible bricked PCM (a test spare PCM of which he has about 20) which is quite interesting.

He had ticked sniff ISO15765 comms and then tried a flash during the sniff all with the same cable. I should have disabled the flash write buttons if sniffing was enabled as it uses a different comms mode which doesn't reply, this will result in timeouts and the flash write failing, it should however be recoverable.

He has tried my new version (haven't sent it out to others yet as I haven't finished the DMR stuff completely) and the recovery process also doesn't work. In case anyone is interested this is what I do

There are 3 levels of failure.
J2534 error means the cable didn't receive any packets or it failed to write. Usually this means cable unplugged, no power etc.
OBD error means the basic ISO connect command or poll PID etc got back a packet but it contained an OBD error code.
UDS error means the UDS command structure got back an invalid response or an error code.

In recovery mode the PCM rejects all OBD commands and only accepts the UDS command security access and flash write.

So as part of my recovery if I get any errors during the auto detect including J2534 errors (only buff_empty or timeout, cable hardware errors are still critical) I treat them as an autodetect failure but not a complete critical failure causing a disconnect.
I then try and send the security access command and if that succeeds I assume it is in recovery mode. It seems even the security access command is failing as I don't see "unlocking controller" in the log.

I have tested my recovery mode by pulling out the OBD cable during an erase/flash, also tried pulling all ECU power mid flash and it results in an erased PCM which can still accept a flash on reboot. I have also flashed an FG file onto BF which causes the PCM to erase itself on bootup. All of these failure modes have been recoverable to date.

What I'm assuming is that by enabling CAN sniffing and trying a flash at the same time the PCM wrote to sector 0x0 instead of 0x10000 which overwrote the bootloader. I'm not quite sure how this could happen. The other possibility is the BA does not have a recovery mode. Two other guys I know have bricked BA pcms by writing BF files onto them (with other software), but I imagine this is due to overwriting the bootloader.

So in the time being be more careful with a BA PCM, it may not recover if you power it off or pull the cable during a flash write. The BF/FG PCM however seems unbrickable at the moment, other than purposely overwriting the bootloader I'm not sure how you can brick them.

I will also ensure all other buttons on the software are disabled during a flash write.

Another one is the J2534 logging whilst a flash is not recommended, there is a shitload of text generated which lags the GUI out at this stage. I will probably remove J2534 logging to the GUI and just log to file.

I have a bricked FG that failed 5 or more times when trying to write with HPT & got to 4% each time & failed & then wouldn't detect & now the PCM doesn't send any packets so it is not wirteable by any software I know of!

Thought I would post this PM up if anyone was also curious.

80gus wrote:Hey mate got a chance today to try reading a BA Falcon in car come up with this following
WOULD YOU LIKE TO SAVE THE FILE WITH ACTUAL OFFSETS? NOTE YOU WILL NOT BE ABLE TO WRITE THIS BACK TO THE PCM

Could you explain that to us mate? or is because it was in the car still not on a test bench?

BA uses two banks of memory

0-0x70000 and 0x500,000 to 600000

actual offsets will insert a bunch of nulls from 70k to 500k so when you load it up in IDA pro the pointers are correct.

Otherwise it will just pack the file and make a file 0x170000 long. Either should be writeable back now, I think I added that option.

So basically if you want to view the file in IDA use real offsets, if you want to just save it to write back later, don't select it.

rolls wrote:Thought I would post this PM up if anyone was also curious.

80gus wrote:Hey mate got a chance today to try reading a BA Falcon in car come up with this following
WOULD YOU LIKE TO SAVE THE FILE WITH ACTUAL OFFSETS? NOTE YOU WILL NOT BE ABLE TO WRITE THIS BACK TO THE PCM

Could you explain that to us mate? or is because it was in the car still not on a test bench?

BA uses two banks of memory

0-0x70000 and 0x500,000 to 600000

actual offsets will insert a bunch of nulls from 70k to 500k so when you load it up in IDA pro the pointers are correct.

Otherwise it will just pack the file and make a file 0x170000 long. Either should be writeable back now, I think I added that option.

So basically if you want to view the file in IDA use real offsets, if you want to just save it to write back later, don't select it.

yeah.. thats what I choose.. don't add the offsets.. for the ticking stuff.. I figured if you put it there and setup telemetry.. then you must want data from runs.. so I ticked it all.

no matter.. I still have the tune from that PCM here and I'm gonna see if my CAN logger gets anything at all from the PCM.. with any luck it'll be recoverable.. I want it because it's the only other turbo one I have (other than the one in my car) but not a super big deal.

IF you want a suggestion Rolls, put the name of the active J2534 that gets loaded up in the UI somewhere.. the log shows about 6 found drivers from mine. (VCX/Mongoose and a bunch from the VCM) you asked why I kept hitting detect, it was because it's not clear what it detected and in one of the logs later on it actually had the details of the VCX driver (which was odd because the VCX was apart on my kitchen table for reasons I'll detail shortly.)

It will only connect to the cable that is plugged in. It isn't possible to connect with another driver.

When it connects it says which cable it is using.

The detect button just lists the drivers in the registry. I might delete it because it is misleading and will always report the same cables.

Also if you didn't press sniff on the sniffing screen the J2534 logging won't have done anything so the fact it failed must be due to some other reason. It looks like it did the Erase and then just totally died.

Thought it was kinda interesting to monitor the security chatter, seems to spit out 4-5 times of the same message then moves to the next.
I actually thought all that data came from the BEM, but its actually the ECU!

Also, the ECU I currently have on bench (BA 6cyl), comes up with a blank vin when reading.
Confirmed by monitoring at the same time, whats being read out is:
7DF 02 09 02 00 00 00 00 00
7E8 10 14 49 02 01 00 00 00
7E0 30 00 00 00 00 00 00 00
7E8 21 00 00 00 00 00 00 00
7E8 22 00 01 01 01 01 01 04

So its all blank.. except those ending bytes.

Hi Folks,

As I said I would, I pulled the VCX apart and started tracing pin13 to see if it actually went anywhere. I was partially expecting to discover that it just wasn't hooked up to anything but it turns out it actually is.

Took some photos:

I started on the back.. the writing was done on my phone so excuse if it's unreadable.. but the pin13 trace leads down the side of the other one and though a resister where it seems to end.. It doesn't though.. there must be a layer I'm not seeing as the capacitor marked in the pic below shows a resistance from it's legs to pin 13.. it's not a low resistance, but it's there.



Keep in mind that this thing is tiny and my close up vision sucks.. I had to use a lite up magnifying glass and zoom on my camera to see it with any detail.

So some effort was made for pin13 to hook up to "something" but since there is no voltage on it.. it either has a problem or the software code is buggy. If not for Feps I'd love this thing as it's tiny.. uses micro USB cables or Wireless or Bluetooth (not for writing obviously, but for PATS and steering calibration etc it's fine wireless) Rolls has indicated that it doesn't really have to be 18v and 12 would probably work fine, so I'm thinking of trying to either fix it as is.. or at least find the problem.. or to put a switch on the side to do it manually.. or to put a tiny relay in there and have it switched by the actual transistor or chip that was supposed to be doing it all along.. (assuming that transistor or whatever isn't faulty.) I don't want to do it manually, but I'd mean I would have a second write capable J2534 adaptor.. and I'll probably get an openport too at some stage.

Any thoughts on how they think the FEPS is supposed to work on this thing? If I can trace the circuit further though.. I can use the J2534tool from drewtech to set the voltage and then follow the circuit back to see if I can find the failure point.. hopefully it's a dry joint (and hopefully it's the only dry joint).. easy fix then...



ta

Frank

What car is the VCX meant to work with? If it isn't Toyota or ford then it might be hooked up but I doubt it will be programmed to do anything. VCI has it hooked up to a gpio pin but the software isn't programmed to do anything.

rolls wrote:It will only connect to the cable that is plugged in. It isn't possible to connect with another driver.

When it connects it says which cable it is using.

The detect button just lists the drivers in the registry. I might delete it because it is misleading and will always report the same cables.

yeah, I know.. I thought at first that I had some driver loading issue due to having IDS and the mongoose setup on the same machine. (all the testman and other services for IDS were stopped though)

Probably better to do what BE and the drewtech tool do and just have a drop down with the reg entries listed and the one with the loaded driver selected.. that way you know at a glance what is there and what is active.