P04 R&W Testing

[kur4o]

I agree on the p/n soup. Actually I just organize them by size and year in UNniversal patcher to avoid confusions.

The hardest part is to identify the pcm before uploading anything on it. You just have a vin and OS and seed/key pair.
If you get lucky some more data can be read via mode 23.

Now how to identify all that based on some very limited piece of data. A huge user provided database with every possible OS number=very inefficient and error prone.

A vin decoder to narrow things down + OS lookup.

Using the unlock algo can also narrow down, but not a complete solution.

The best approach will be Vin decoder + A rip off of tis2000 database with all p/n extracted to custom pcmhammer database.
It is 1gb of file and very hard to read. Anyway I can send you extracted tis2000 database so you can figure something out of.
AT least you got all the p/n there old+latest but reading it is another matter.

[Gampy]

I think that is the bloated approach.

IMO That is like dumping a truckload of shit on your potted house plant to solve it's nutrient deficiency, all it does is stink up your house and kill the plant!

Not to mention complicated!

I think if we quit calling every unknown FWD PCM a P04, and break them up accordingly the problem will go away and things will become much clearer.

I'm comfortable saying that GM has a different moniker for each vastly different unit, when I say vastly different, I mean it takes different handling and programming!

-Enjoy

[antus]

I think going service number by service number is the best approach. We can turn service numbers in to a list of OSIDs, and plugging service numbers in to ebay works quite well to find which cars they came in, an have the interchange database down the bottom. This is enough to confirm if they are a p04 or not. This is what I have done with what is in pcm hammer now. I checked all the service numbers again, one was out of place so I removed that one. But what is in there is verifiably P04s. There are probably service numbers missing. If we find an OSID thats not there, we can look up its OSID to get a service number, then service number back to list of OSIDs and put it in. This way we get good coverage without needing samples of hundreds of different OSIDs, which to be honest I dont think we'll get, and it'll just tarnish pcmhammers reputation when people try it on p04 and it doesnt work because we need to work with them and make a test build with their number for it to work. Most people I dont think would bother with this, they'd just call it a fail and use something else like lsdroid.

I do think the list is getting long enough that it might make sense to move it in to an sqlite database or something. The worlds biggest case statement is starting to get a bit over the top, even for me lol. If we add more P04, P08, E54, any missing P01/P59/P10/P12 its going to be big.

[kur4o]

In that case we can group the pcm families by flashing similarities. ANd name them whatever we like.

If DLC equals, watchdog equals, flash registers equals,bin identifiers equals, than we can treat it the same type, no matter what flash type and size and casing it have.

[kur4o]

Gampy ,

You want proof the 96-97 v6 = 98-05 v6 as a software point of view, registers and flash sequence. I dig up an old archive of flash routine.
You can see it yourself the 256kb pcm with old casing can be used with very same p04 settings.
The only real difference is eeprom area, 256kb don`t have one on main memory chip, while 512kb have it.
Also each version can have different memory size,
chipID =2275-256kb and chipID=4471-512kb chipID=22AB-??512kb AMD??
Later ones also have an amd chip, that needs third case. The loading address might differ, but some that can work with all should be found easily.

[antus]

In that case we can group the pcm families by flashing similarities. ANd name them whatever we like.

If DLC equals, watchdog equals, flash registers equals,bin identifiers equals, than we can treat it the same type, no matter what flash type and size and casing it have.

Well, yes. I don't think that changes anything though. We still need the same details we use already, and we are still just re-implementing the C kernel in asm for size. The SIM and hardware registers we know for the types that we support write in C already, and I think we only need the hardware io register for P04, P08 and E54. They are easy to find. Its mainly just a matter of implementing the erase and write functions that we have in C, in asm. What we did with the C kernel is start with erase, then do write.

We can develop and test this the same way we did for the C kernel - by putting some changed data in the middle of the unused param block so it has no effect on the PCMs operation but can test if erase and write is working in that sector first. And we can implement on P01 or one of the others before we try a new platform. I have BDM on my P01 so would probably start there, even though BDM should not be needed.

[Gatecrasher]

The best approach will be Vin decoder + A rip off of tis2000 database with all p/n extracted to custom pcmhammer database.
It is 1gb of file and very hard to read. Anyway I can send you extracted tis2000 database so you can figure something out of.
AT least you got all the p/n there old+latest but reading it is another matter.

I have it imported into MySQL, and I know how to read it. The only thing it doesn't have is service part numbers.

I'm not as experienced with the older stuff, so maybe this is a dumb question. Why is it so hard to identify the hardware? End model and base model part number, among other things, are supposed to be available through mode 3C. It's the same as the mode 1A read DID on the later GMLAN stuff.

[antus]

I am not aware of this, if you can explain what should be available that would help. We need a way to know which kernel to load. OSID isn't great because there are so many of them, but if we could get service number back, that would help us. There is a hardware number, but I dont know how to make sense of it.

For example my P08 is returning, and most of them return something. I just havnt been able to figure out what a hardware ID is.

Code: Select all

[01:06:55:554]  TX: 6C 10 F0 3C 04
[01:06:55:572]  RX: 6C F0 10 7C 04 00 F8 3C 16
[01:06:55:573]  Hardware ID: 16268310

[Gatecrasher]

3C 04 is supposed to be the beginning of the traceability data. Hmm.

What do you get for 08, 09 and 14?

[zack4200]

I am not aware of this, if you can explain what should be available that would help. We need a way to know which kernel to load. OSID isn't great because there are so many of them, but if we could get service number back, that would help us. There is a hardware number, but I dont know how to make sense of it.

For example my P08 is returning, and most of them return something. I just havnt been able to figure out what a hardware ID is.

Code: Select all

[01:06:55:554]  TX: 6C 10 F0 3C 04
[01:06:55:572]  RX: 6C F0 10 7C 04 00 F8 3C 16
[01:06:55:573]  Hardware ID: 16268310

I don't know if it's helpful or not, but one of my p08s reports the same Hardware ID, which also matches the "HDW NO." printed on the sticker on the back of the pcm.

interestingly, I just also realized that the small number in the lower right of that ID sticker is the calibration ID - this matches on both P08s and both P04s that I have.