PowerPCM_Flasher: my tool for E38 and E67

[tpepmeie]

clyde, I am also getting the exact same errors on both programs with an E38. Did you ever resolve the issue? I'm using OBDXPro GT also. My device works flawlessly with SPS. I was hoping to use this tool to pull a binary from my ECM after a clean SPS re-place and reprogram.

I am in the USA, this e38 is from a Canadian 2008 Chevrolet Silverado 1500, the other e38 is from a USA 2008 Chevrolet Express 2500. Both have the same (similar) error and both I got off eBay and they should be junkyard pulls. I tried to use the ECU brute force unlocker, but I get the mscorlib error on both computers too.

ECU brute force unlocker-tested with E38,E78, and E92 ecu and gm MDI
Should work with any GM ecu with a 2 byte seed/key and a 10 second timeout between keys
This could take up to 7 days so make sure you have a stable power supply.
using dll from https://github.com/BrianHumlicek/J2534-Sharp
1 - Unlock Ecu
2 - Change starting key from decimal:0 / Hex:0000
3 - Connect to MDI and check connection by reading Vin
4 - Change Send timout from 600 milliseconds
5 - Change Read timout from 600 milliseconds
6 - Enable debug- more feedback
7 - Close Program
8 - Read vin - check connection and ecu
8
1 - OBDX Pro VX

Input Device Number:1
SendCommand Error source: mscorlib
SendCommand Error source: mscorlib
SendCommand Error source: mscorlib
SendCommand Error source: mscorlib
SendCommand Error source: mscorlib
SendCommand Error source: mscorlib
Press any key to exit.

This is the only J2534 device I have (OBDX Pro VX). Since the driver just got released, I'm not sure where the issue might be.

[Tazzi]

I have just tried running the Brute Forcer code here, and I see the issue.

So, by default, the J2534 compliancy indicates that the scantool must indicate it successfully transmitted a message to the vehicle network.
This is done by adding a message with the CAN header ID and a flag indicating TXD successful.

It looks like this app does not check if the received message is a TXD success message so its getting itself a bit confused.

Now, trying a few other J2534 tools, my MDI 1 seems to work fine, but MDI2 does not.
My PCAN j2534 tool also does not go through either. Interesting, a drewtech mongoose and cardaq do go through.

I will have to re-read the J2534 documentation, I wonder if their is a specific clause for the raw CAN protocol that indicates a txd success message is not required?

[ironduke]

I have just tried running the Brute Forcer code here, and I see the issue.

So, by default, the J2534 compliancy indicates that the scantool must indicate it successfully transmitted a message to the vehicle network.
This is done by adding a message with the CAN header ID and a flag indicating TXD successful.

It looks like this app does not check if the received message is a TXD success message so its getting itself a bit confused.

Now, trying a few other J2534 tools, my MDI 1 seems to work fine, but MDI2 does not.
My PCAN j2534 tool also does not go through either. Interesting, a drewtech mongoose and cardaq do go through.

I will have to re-read the J2534 documentation, I wonder if their is a specific clause for the raw CAN protocol that indicates a txd success message is not required?

Thanks for taking a peek at the code, definitely not surprised I am doing something wrong, curious if that is something the dll I am using is supposed to be doing? I do know with ISO protocol I see the message after a transmit that your describing but I am not seeing that with raw CAN..

I have found an issue with the mdi2 and the latest update that came out recently. It might be the dll but I cannot get rid of filters even with raw can. I have a small dtc program that reads the vin from the ecm so I have an ecm filter setup, then I stop and clear the filter and set up a pass all filter to ping every module with a 1a b0 and see what replies. The only module replying is the ecm because the ecm filter is still active. Haven't had time to dig down with it but If I disconnect and reconnect the filter is gone so I've done that for a quick patch. it's on a todo list though.. The regular mdi's are fine, it's only the mdi 2 that has the problem. This might be the brute force problem and the mdi2 update is merely showing my programming ignorance..
Edited to add. Brain cramp, with the brute force code I connect and just have 1 filter for the ecm so doubtful the mdi2 problem I have is related to this.

[Tazzi]

Thanks for taking a peek at the code, definitely not surprised I am doing something wrong, curious if that is something the dll I am using is supposed to be doing? I do know with ISO protocol I see the message after a transmit that your describing but I am not seeing that with raw CAN..

I have found an issue with the mdi2 and the latest update that came out recently. It might be the dll but I cannot get rid of filters even with raw can. I have a small dtc program that reads the vin from the ecm so I have an ecm filter setup, then I stop and clear the filter and set up a pass all filter to ping every module with a 1a b0 and see what replies. The only module replying is the ecm because the ecm filter is still active. Haven't had time to dig down with it but If I disconnect and reconnect the filter is gone so I've done that for a quick patch. it's on a todo list though.. The regular mdi's are fine, it's only the mdi 2 that has the problem. This might be the brute force problem and the mdi2 update is merely showing my programming ignorance..
Edited to add. Brain cramp, with the brute force code I connect and just have 1 filter for the ecm so doubtful the mdi2 problem I have is related to this.

I cannot find anything specifically in the J2534 documentation stating the raw CAN does or does not get the TXD success message. I am going to make the assumption it is not suppose to.
Once I am back infront of the work computer, I will make some edits to the J2534 code for the OBDX tools and see if they get up and running with your app

[antus]

I might split this out to a new thread shortly to stop polluting the powerpcm flasher thread, but I have been thinking about this and could it be that the can protocol uses flow control and raw can does not and the message you are talking about is only required for can with flow control?

[Tazzi]

I might split this out to a new thread shortly to stop polluting the powerpcm flasher thread, but I have been thinking about this and could it be that the can protocol uses flow control and raw can does not and the message you are talking about is only required for can with flow control?

The message that is sent is just the scantool saying the CAN message has been transmitted, basically it’s just the DLL acknowledging to the software that the sent CAN message was successfully transmitted.

[julespatch]

I haven't tried the Brute Forcer with MDI2 for a while but there was an update recently that got it to stop asking me to select it every time you tried to do a new operation

[antus]

@julespatch, the brute forcer stuff has moved over here, please keep this thread for questions about the PowerPCM Flasher. viewtopic.php?p=107289#p107289