PCM Hammer E38

[antus]

If you have a github account you can download the latest snapshot from the develop branch. it'll read and write the main flash now to see if it works but best not change the os until the slave is figured out

[AngelMarc]

CLI only?

[antus]

No, Normal windows (winforms) portable or setup and installed, and windows cli and linux cli are all good. the windows uno version, and android uno version run and may work but are not considered ready for use or expected to work properly and I would strongly advise against writing with those versions. There is also a new bus data logger in there as well, but only for Can500k and VPW as they are relevant to pcm hammer which I have been useing lately because it runs fast and drops no packets on my machine when other tools do, and its easy to use. At the moment you'd probably want portable or setup from https://github.com/PcmHammer/PcmHammer/ ... 9754475113

[AngelMarc]

Thanks, always prefer portable.

Capture.PNG

I'll assume that's the one.

[MPC001]

If you have a github account you can download the latest snapshot from the develop branch. it'll read and write the main flash now to see if it works but best not change the os until the slave is figured out

Cool Antus . Once I got the VS build done & put the kernel in the folder with the executable, it worked very well on OBDXPro GT & did the read in about 1:40 IIRC. Great work! It's quite slick & snappy. The block by block CRC compare flash <> file is a handy option too. It'll be a good addition when flashing can be done without touching the boot block too.

[antus]

Slow progress. But it looks like the slave service mode reboot is hooked to the erase function of the main flash. So this will mean its not possible to read the slave without writing the main flash. Still working through this and using the factory boot sector and flash style to do it. Need to get it working this way first, then strip it back to get it down to minimum and finally port it in to the pcmhammer kernel. It'll suck if we have to erase one or more main flash sectors to even read the slave, but if that's the hardware limit then that's what we have to work with. It'll mean that a read includes a write operation so there wont be such thing as a 100% safe slave read, even if it can be made reliable.

[antus]

Dead end for now on slave execute. I know less than I thought I did. I am not sure the erase function is tied to the salve reboot, and it kinda doesn't make sense. More RE, testing and thinking required.

As for the cross flash and corrupted vin etc, now have a handle on that process. The param blocks are C000 and E000 in the flash and they are different between years. Somehow I managed to get a param block mismatched in to one of my test bins from an incompatible year. Therefore, the limit was never the year of my PCM, it was every time I wrote this file, things became corrupted. So it looks like erasing the SRAM copy of the param block at flash time works great. More testing required, but if anyone knows what limitations people hit when cross flashing between 2006-2007, 2008, 2009 and 2010+ E38s, I would like to know.

For my PCM I found another bin of the same OSID with it's own original param block and a write of that one works fine on my PCM.

[antus]

It looks like we have to emulate the factory programming style for slave programming, but it can be done.

But it has become clear why other aftermarket apps use their own file formats. It's not vendor lock in, or at least not solely vendor lock in. For slave, there does not seem to be a way to determine from the bin what the slave os and slave cal need to be to match. So, now we have a concept of metadata that needs to be recorded and saved when we read a PCM. This metadata needs to go somewhere, and we could put it alongside the bin, but I know from watching what happens with XDFs with checksum plugins that people copy one file and not the pair and then ask over and over again on forums and groups why its not working. I'd like to avoid this and make it foolproof. So it might be time for a pcmhammer file format, to contain both the main bin, as well as identifiers for the slave. And if we have this, then might as well go as far as files for multiple devices on the vehicle bus like PCM and TCM, and who knows, maybe we end up adding IPC or BCM one day (not currently planned, though I would like to add a TCM next). I created this POC for such a file format with assistance from AI so the UI/Logs are not exactly what I want, but it does work. It supports bin and phz (pcmhammer zip) which is just a zip file with one or more bins, and metadata as a json file. So it's possible to store the main flash bin, and the IDs for the slave. The bin file part can be included, or omitted, and pcmhammer gets a library of known slave segments that it can draw on when omitted. This solves the lack of slave read, similar to what other apps do.

The down side is that now we don't have a bin, without extracting it and repacking it. This will break the ability for it to be editable with tools like universal patcher or tunerpro. I think we could add the format to universal patcher, being opensource, if it would be accepted. It would be nice for tunerpro to support it too. In general maybe we need an open standard for tuneing tools that apps with the same requirements could start using. Is anyone aware of similar existing?

This is a manifest.json from the phz file written by the POC and in the screen shot.

Code: Select all

{
  "format": "pcmhammer/package",
  "formatVersion": 0,
  "generator": "PcmHammer",
  "created": "2026-07-29T22:43:45.5850938Z",
  "controllers": [
    {
      "id": 1,
      "type": "PCM",
      "moduleType": "E38",
      "images": [
        {
          "target": "main",
          "file": "main.bin",
          "size": 2097152,
          "sha256": "029d7632fa26ded366b2aeb8a45697a93df1b89b5c515dcb877c45263ce51045",
          "osid": 12628990
        },
        {
          "target": "slave-os",
          "file": "12625892.bin",
          "partNumber": 12625892
        },
        {
          "target": "slave-calibration",
          "file": "12629150.bin",
          "partNumber": 12629150
        }
      ]
    }
  ]
}

[AngelMarc]

A zip with the plain .bin and whatever in it sounds good. Can do a basic, well supported unzip, for raw data and conversion if needed.
A zip with a different name is what APKs (Android OS) are apparently.
Call it a .ham file lol

[pman92]

.phz is good but my suggestion is .hmr for hammer. If it's going to support modules other than the PCM eventually then why bake PCM into the name.

Or maybe .hzf or .hzp (hammer zip file).
Or maybe .bfm (binary file manifest)

I'm sure someone will think of something even better