PCMHammer P04

[zack4200]

Spent a bit of time trying to get this to work. In the end, it appears that on a 97 P04_early 512k and 98 P04 both succeed to do a full read with a J2534 CarDaq plus3 and USB OBDLInk SX but FAILs with my ALLPro. I also tried with the AllPro with 4x disabled. It still failed. I have used that AllPro a lot with 411's with no issues. I attached the 4x disabled logs.

It seems like at the end, the read finishes, then begins to check CRC's from PCM and gets no response. File never gets saved but I assume that is normal behavior. I am pretty sure that I tried verify only and that failed as well.

Please let me know if there are any tests I can provide results from for you.

Try restarting your PC and then try it again, I got the same CRC check error using an OBDXPro, but a restart solved it. Now realizing that I forgot to share my logs after it happened lol

[darkman5001]

Would someone be able to send me two P04 AMD and two P04 Intel flashes that are confirmed as good? I want to do some cross flash testing. Thanks guys.

[antus]

If you have one of each PCM, read them both and write them back the other way. In the end, I wasn't able to reproduce any problems on the bench with cross flashing p04 bins of the same physical size.

[darkman5001]

If you have one of each PCM, read them both and write them back the other way. In the end, I wasn't able to reproduce any problems on the bench with cross flashing p04 bins of the same physical size.

I have already tried that and had no issues. Wanted to try totally different OS in addition to opposite flash chip.

[antus]

I put this together when I was testing. It's C, I used gcc on linux with gcc -o flashtype flashtype.c to compile. It scans the current dir and sub dir for bin files, and looks for some byte patterns that I think identify intel or amd flash chip access for write. The patterns include the code and magic pattern to wake up the flash chip state machine for the write process which are different for the two brands. I ran it over the big bin directory that has been previously shared on the forum to try and identify by year what bins had what flash code in them to start getting an idea what is what. If you have an archive of bins you could use it the same to identify whats what to cross flash.

Code: Select all

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <dirent.h>
#include <sys/stat.h>
#include <unistd.h>

#define INTEL_LEN 16
#define AMD_LEN 12

unsigned char intel_pattern[INTEL_LEN] = {
    0x30, 0xBC, 0x50, 0x50, 0x30, 0xBC, 0x20, 0x20,
    0x30, 0xBC, 0xD0, 0xD0, 0x30, 0xBC, 0x70, 0x70
};

unsigned char amd_pattern[AMD_LEN] = {
    0x24, 0x7C, 0x00, 0x00, 0x0A, 0xAA,
    0x26, 0x7C, 0x00, 0x00, 0x05, 0x54
};

// Search for a byte pattern in a file
int contains_pattern(const char *filepath, const unsigned char *pattern, size_t pattern_len) {
    FILE *f = fopen(filepath, "rb");
    if (!f) return 0;

    unsigned char buffer[4096];
    size_t bytesRead;
    int found = 0;

    while ((bytesRead = fread(buffer, 1, sizeof(buffer), f)) > 0) {
        for (size_t i = 0; i + pattern_len <= bytesRead; i++) {
            if (memcmp(buffer + i, pattern, pattern_len) == 0) {
                found = 1;
                break;
            }
        }

        if (found)
            break;

        if (bytesRead > pattern_len)
            fseek(f, -(long)(pattern_len - 1), SEEK_CUR);
    }

    fclose(f);
    return found;
}

int ends_with_bin(const char *filename) {
    size_t len = strlen(filename);
    return len >= 4 && strcmp(filename + len - 4, ".bin") == 0;
}

void scan_directory(const char *path) {
    DIR *dir = opendir(path);
    if (!dir) return;

    struct dirent *entry;
    char fullpath[4096];

    while ((entry = readdir(dir)) != NULL) {
        if (strcmp(entry->d_name, ".") == 0 || strcmp(entry->d_name, "..") == 0)
            continue;

        snprintf(fullpath, sizeof(fullpath), "%s/%s", path, entry->d_name);

        struct stat st;
        if (stat(fullpath, &st) == -1) continue;

        if (S_ISDIR(st.st_mode)) {
            scan_directory(fullpath);
        } else if (S_ISREG(st.st_mode) && ends_with_bin(entry->d_name)) {
            int has_intel = contains_pattern(fullpath, intel_pattern, INTEL_LEN);
            int has_amd = contains_pattern(fullpath, amd_pattern, AMD_LEN);

            if (has_intel && has_amd)
                printf("%s Both\n", fullpath);
            else if (has_intel)
                printf("%s intel\n", fullpath);
            else if (has_amd)
                printf("%s AMD\n", fullpath);
        }
    }

    closedir(dir);
}

int main(void) {
    scan_directory(".");
    return 0;
}

[antus]

And this is the output from bins on my system. I can't confirm the health or correctness of these bins but it's what I have at the moment. I have flashed a few of them on my bench without trouble so far.

From this list it looks like 2002 and prior bins were all intel, and from 2003 most bins had intel and amd code. I didnt find any bins with amd code that did not include the intel code in this collection. In that regard, it looks like GM used the same timing and approach to switching to AMD on the P04 as they did the P59. In that regard I think it's always OK to flash a later revision bin on an earlier PCM, but flashing an earlier bin on a later PCM might have problems if it needs too persist anything to flash, like VIN changes. But having said that P04 doesn't have the parameter block, so I don't know if they need to be able to do that or not. Its possible they don't and there is no impact but that just my guesswork. I would avoid putting intel bins on amd PCMs to avoid any risk, even if they do not brick.

I can share re-share a couple of these bins if you pick some, or you likely have them in your collection already.

[antus]

Thanks for your help Darkman on this. The update is with testing and cross flashing, we've proven that there is no problem with any intel or amd cross flashing. But there a lot of bad files out there. There was a brick, and the root cause was a mis-labeled bin pulled from TIS that was lacking vin/security data. We've turned up a few more files with the same problem in public repos. So I think to protect P04 users from these files PCM Hammer is going to need some additional logic for P04 to make sure the paramater/vin/security data is present and prevent a write if it is not. That should make things safer.

The 1998+ bins have an easy structure that should not be too hard to look for. The 1996 bins are 256k and the 1997 bins are 512 but do not have this structure. So will need to have a look at these ones next and see if we need to do and can do something similar.

Thanks to the universal patcher team for figuring the file structure and makeing it opensource. I'll probably use the same logic to look for this data block in the P04s.

[SuperGTP01]

Thought I'd update since I got a spare ECM for my Pontiac and got my bench harness out. I successfully did a full read of an ECM from a 2001 Impala, made a few changes and wrote back to it. PCMhammer did it without issue. I then took the bin from my ECM and did a full write on the spare one. No issues. I'm really tempted to do a flash in car when I get more time. All this was done with a OBDX pro VX.

[antus]

I would not recommend in car. These vehicles often have modules on the bus that do not silence when they are supposed to and that causes problems with flashing in car. It's on my list to add a warning about this and advise against it when the program starts up.
Having said that, it may work for you. But do the read in car first and make sure you do not see any errors logged and PCMHammer reports an excellent connection at the end. Anything else and you have a brick risk that I would not take on my car.

[SuperGTP01]

I would not recommend in car. These vehicles often have modules on the bus that do not silence when they are supposed to and that causes problems with flashing in car. It's on my list to add a warning about this and advise against it when the program starts up.
Having said that, it may work for you. But do the read in car first and make sure you do not see any errors logged and PCMHammer reports an excellent connection at the end. Anything else and you have a brick risk that I would not take on my car.

Yea I figured. I'm just lazy even though the ECM isn't hard to pull. Very excited that it wrote without an issue.