PowerPCM_Flasher: my tool for E38 and E67

[daniel2345]

Thanks alot

Sure, oldscool C. No classes, lots of pointers

As in the good old days

[kur4o]

I got an error on startup, no entry point REGGETVALUAA in advapi32.dll. On xp sp3 and sp2

[daniel2345]

Right after starting the tool or when selecting PassThru as device?

Seems to be a Problem with the Windows Registry Queries on XP. Have not done this with initial version.

Will test that later

[daniel2345]

Updated to Version 0.0.0.6.


Issue with Registry Query for Windows XP is fixed.
Turned out that the Windows function i used is available for XP 64Bit but not 32 Bit. Microsoft...


Also the disconnect/reset should work now or give at least a message/retcode.

Tool release for PassThru should work now also.


Happy testing

[kur4o]

Thanks for the quick fix.

I managed to connect and disconnect to mdi without issues. Worked great. No pcm to test more though.
Since you have connect and disconnect to the tool can it be used as a monitoring device. I guess it will be simple command send to monitor all bus traffic and output it to the app. Adding pin select for monitoring and protocol will be just awesome. I am sure that mdi have and support pin reassignment.

On the flashing side. Do you think 0-BFFF area can be reflashed or is it part of the internal cpu memory.

[ironduke]

This is great!!! Can't wait to try out the new version..

One thing to mention, and this is not a great concern, but... using the MDI wireless it fails every time trying to read the flash.. well not every time.. I tried a bunch of times on another bench E38 and last night and the 7th time it made it thru a full read and was a byte for byte match of the file so no errors.. This is not a point of concern, lol.. Just for down the road it would be nice.. You mentioned a possible timing issue with Antus and his read issue which seems to have resolved itself? I failed to take note of what the exact error was, I believe it was not getting the correct response but I'll pay more attention next time.. If there is a small timing issue and it gets nailed down now then this will prevent future issues and might even help the elm327 issues??
Your programming is way over my head, but if I can help with testing or logging let me know..

Has anyone tried this in a vehicle yet?? so far all mine have been on the bench, I am assuming your sending the stop chatter command so it should be ready for vehicle testing?? I'm game to try probably tomorrow if you give me the go ahead, at least for reading, lol... If I can unbrick my E38 I'll throw it in a vehicle and give that one write attempt as well..

Any ideas on if we can perform a write entire? I saw that when writing boot was unchecked, I did try checking it and performing a write but when reading afterwards and doing a file compare it doesn't appear anything was written before 0x10000 That may have been the end of my bench E38 but I don't know if unchecking/checking any of the calibrations/sections actually does anything?? In my zeal last night I threw everything at my bricked bench.. Now it just flatlines the canbus at around 2.4 or 2/6 volts as soon as you turn the key on.. No chatter whatsoever.. Powered down for today and I'll check it again tomorrow morning when I get in the shop..

If I haven't thanked you yet today, thanks a ton for providing this!!! Looks like we're going to have to start figuring out how to find definitions out of the bin files.. I've been working on my figuring out of the CVN and SUM of each segment, giving it my own attempt at some code to compute these, baby steps for me...

Which OS were you looking for information on?? I'm assuming you have a pet project all this work is pointd towards??

[daniel2345]

Thanks for the quick fix.

I managed to connect and disconnect to mdi without issues. Worked great. No pcm to test more though.
Since you have connect and disconnect to the tool can it be used as a monitoring device. I guess it will be simple command send to monitor all bus traffic and output it to the app. Adding pin select for monitoring and protocol will be just awesome. I am sure that mdi have and support pin reassignment.

On the flashing side. Do you think 0-BFFF area can be reflashed or is it part of the internal cpu memory.

Unfortunately i didn't get it completely...

What is pin select / pin reassignment?
Do you think it is of use to have the plain bus bytes of all ECUs in a window or log file?.


Flashing: in E38 this Area can be reflashed, yes.
But its extremely dangerous in terms of bricking the ecu.
Thatswhy this will probably not be included in this tool.
OS is not that dangerous, but needs lot more work to get it stable.

Will see if im dining this sometimes, but it is not planed for now.

[daniel2345]

This is great!!! Can't wait to try out the new version..

One thing to mention, and this is not a great concern, but... using the MDI wireless it fails every time trying to read the flash.. well not every time.. I tried a bunch of times on another bench E38 and last night and the 7th time it made it thru a full read and was a byte for byte match of the file so no errors.. This is not a point of concern, lol.. Just for down the road it would be nice.. You mentioned a possible timing issue with Antus and his read issue which seems to have resolved itself? I failed to take note of what the exact error was, I believe it was not getting the correct response but I'll pay more attention next time.. If there is a small timing issue and it gets nailed down now then this will prevent future issues and might even help the elm327 issues??
Your programming is way over my head, but if I can help with testing or logging let me know..

Has anyone tried this in a vehicle yet?? so far all mine have been on the bench, I am assuming your sending the stop chatter command so it should be ready for vehicle testing?? I'm game to try probably tomorrow if you give me the go ahead, at least for reading, lol... If I can unbrick my E38 I'll throw it in a vehicle and give that one write attempt as well..

Any ideas on if we can perform a write entire? I saw that when writing boot was unchecked, I did try checking it and performing a write but when reading afterwards and doing a file compare it doesn't appear anything was written before 0x10000 That may have been the end of my bench E38 but I don't know if unchecking/checking any of the calibrations/sections actually does anything?? In my zeal last night I threw everything at my bricked bench.. Now it just flatlines the canbus at around 2.4 or 2/6 volts as soon as you turn the key on.. No chatter whatsoever.. Powered down for today and I'll check it again tomorrow morning when I get in the shop..

If I haven't thanked you yet today, thanks a ton for providing this!!! Looks like we're going to have to start figuring out how to find definitions out of the bin files.. I've been working on my figuring out of the CVN and SUM of each segment, giving it my own attempt at some code to compute these, baby steps for me...

Which OS were you looking for information on?? I'm assuming you have a pet project all this work is pointd towards??

Hehe, thank you

Entire write as i said to kur4o: i don't think so.
OS might be included in the future.

I think i wrote a little on page 1. We have an Camarao or Corvette SS LS3 engine with 525 Hp (???) in the container towards us.
It comes with E38, i do not have it yet in my hand. Will be fittet in G20 A-Team Van.
This E38 im playing with for now is from eBay.

So not clear which E38 OS we will end up, but any info / description files and so on will be useful.


We will take care of the wireless issue, probably timeouts.
When everything works stable, i will add some switches to lengthen them.
Maybe that will do the trick

[kur4o]

Some of the pins on the DLC end are multilpexed. Meaning they can be reassigned.
For example, when you select kwp2000 protocol, the pin on the DLC you want to listen the communication can be selected, like pin 7 or pin3 or pinX or whatever is supported.
GMlan also have handfull of DLC pins that can selected.

I am not sure is this can be extracted from the dll.
Otherwise from register you can find the protocols that the j-tool supports.
Here are some screenshots.

Logging to screen and to file with options to hide the screen print for long logs. Adding some filters for the data being logged will make it really powerful. For example select only frames originating from ecu to be logged, or select tcm to ecu comm only and so on.

In case there is only cal data write, if not already done, some security checks can be implemented. Since you will soft brick the pcm in the event that the last 8 bytes of os and the last cal segments are AA 55 66 66 FF FF FF FF, but there is checksums mismatch or some of the data is not compatible with the OS.

Usually the pcm will enter recovery mode when the check bytes are not the exact values of AA 55 66 66 FF FF FF FF.

It will be nice for extra piece of mind to
confirm the OS with pcm and selected file and, or checking that bootblock p/n matches the that in the selected file, in the event of full write.
This will bring down the chances of soft bricking to zero.

[daniel2345]

Ok, ill do some more checks regarding wrong CRC an recovery mode.

I will put can logging on the whish list, but currently tool was not intended for such things

Im afraid these Pin switching thing is too device specific.

@Ironduke: checking the boxes has no effect. Currently it only flashes calibration area. Not OS and not Boot.



How about the others?
Does it work for you all without any issues?