pcmhacking.net

What about the linking of the PIM to the BCM?
It won't communicate without linking?

evilstuie wrote:What about the linking of the PIM to the BCM?
It won't communicate without linking?

As far as Im aware, I think the PIM still does its main job even if not linked. Not sure if it technically needs to be linked if VATs is disabled?
I had a client recently replace a faulty PIM with a another one (not linked) and things like temp and fuel gauge started working instantly after the replacement. Although because VATs wasnt disabled, they couldnt start the car.

Wont know till you try really!

The way it works... I think is as follows:
BCM-> PIM -> ECU

So the BCM links to the PIM.. and the PIM links to the ECU. So really, the ECU is the final judge (Or executioner )

The BCM sends a code to the PIM on startup for valid security key found... PIM verified and then sends another message to the ECU saying 'all good bud, dont disable fuel pump'.
So with VATs disabled.. doesnt matter if BCM and PIM are not linked.. or PIM to ECU... as the ECU makes the final call.

Thats my understanding of it anyways!

Thanks mate.
That's a relief going into the last stages of this wiring.

Now my only concern is whether the rumours are true about the BCM and the triggers for things like door locks and lights being voltage/current sensing and whether it'll cause issues with old 80's motors and solenoids.

But we'll see. Worst case scenario I just run isolated circuits for the m and leave the BCM to do the complex calculations required to turn on the dome light

Been tinkering some more with GM stuff, and have been looking into simulating a J2534 interface to have full control over what is actually sent to/from apps like tech2win/gds2/tis ect.

But.. naturally.. being GM.. they haaaaaave to be difficult, so their apps such as tech2win don't actually use the J2534 protocol for communication with interfaces.
Instead, they use a different offshoot called ISO 22900 (D-PDU API), this basically does the same thing.. just alot more expensive to work out the protocol, as the datasheets are 5x as much!

I did notice in the tech2win config settings, there is actually an option to select j2534.. although greyed out. The option selected is the ISO22900, so one would only assume that the j2534 could be used.. but they have prevented it.

The ISO229900 api calls can easily be 'monitored'.. but makes zero sense without protocol documentation to understand what each request means!. Basic information from the function names such as "LogicalConnect" show it making the connection to the protocol, but all in/out parameters cannot be interpreted any further.

Was hoping to find examples of VPW and GMUART for J2534 through monitoring.. but looks like thats out the window!!

I think they had to use D-PDU to cover all the legacy protocols. Heres what they have to say about it in the spec:

The MVCI protocol module is the key component to exchange implementations of diagnostic protocols among
OEMs and tool suppliers without re-engineering already implemented software. By relying on the D-PDU API,
the application may easily access other or additional MVCI protocol module implementations. In a similar way
to existing standards like SAE J2534-1 and RP1210a, applications compliant to the MVCI standard are
basically independent of the underlying device as long as the required physical interface is supported and no
tool supplier specific feature is required.

Even though the D-PDU API extends the capabilities beyond the definitions of SAE J2534-1 and RP1210a,
the existing standards and their related devices and applications do not become obsolete by introducing the
D-PDU API. Instead, the transition and co-existence of all standards are facilitated to save development and
investment costs. The definition of the D-PDU API is closely related to SAE J2534-1 and RP1210a to allow
mapping of functionality in both directions. However, it extends their definitions to cover the full width of
enhanced diagnostics.

Thanks Ant!
So the D-PDU is basically an extension of the J2534 to make development easier by the sounds of that. A bit of googling shows you pay for the usage and documentation for a prebuilt D-PDU DLL and build software around that.

Something I found weird, was removing the J2534 dll actually breaks the software from working even though it uses the D-PDU DLL. The J2534 dll is actually never called for or used, so it must be a hard coded check that its present.. for whatever reason!

Theres no words.. to explain the absolutely unreal head banging rage that I have at the ALDL implementation through J2534.

It basically wants to force you to pause communication in the car before speaking to anything. This causes warnings and errors to display in car which is quite annoying, instead of a nice seamless live data logging experience.

The alternative to it, is the scantool can be setup to send off a specific message when the poll message from the car is detected. But, the problem now is you have no idea how many times this message has been sent, or if it has even successfully sent. This method is how GMs t2w performs alot of its communication.. which makes sense to why it freaks out and completely crashes if it misses a single response.
Technically, t2w uses the D-PDU, but this is an extension of J2534 so it would utilize the same format with the same limitations.

A better way to handle this would be to manually search for the poll message, send the message manually and then look for a response. But the J2534 protocols hardcoded timings don't allow this, as it doesnt believe the huge 300ms window is big enough to manually send off a message. Whereas, if I disconnect the BCM, I can manually send off a message without any problems.

..Just a bit of a rant... since.. well... I literally found no content about ALDL over J2534.

Yeah ALDL is hard with its specific timing requirements. And D-PDU is hard with its complexity. There are reasons why nearly all aftermarket J2534 interfaces dont support ALDL at all.

Probably suits certain vehicles.. but literally doesnt want to play nicely with the commodores.

Have managed to come up with a solution which has so far sent and received 200frames consecutively with a VY BCM on bench. Its a bit of hack way, but way more reliable then the rubbish way they recommend to use.

Managed to get the MDI to program a brand new MAP key to a VY and VZ BCM. Super happy with that result!

Found a little interesting fact though, the MAP keys (From super cheap auto) can be re-written. T2win doesn't allow it, but it can be done happily by unlocking BCM then sending key writing routines. T2win stops after it reads the BCM key status tables which indicate preprogrammed already.

I tried on a genuine Holden VY key also but it failed. Wiping the eeprom to FF's allowed the genuine key to write (Unable with t2win)... but its not a happy camper and believes it is key number 255 (FF in hex). Would need to read a brand new key and write that to the key first I think. But old keys should be re-usable with a bit of an eeprom hack!