PCM Hammer P04 Support Project

They go by many names, P01, P59, VPW, '0411 etc. Also covering E38 and newer here.
Post Reply
Cincinnatus
Posts: 305
Joined: Fri Jul 30, 2021 5:49 pm
cars: 97 Corvette
92 Camaro
2005 Silverado
2001 Savana 2500
1998 c3500hd
1998 tahoe

Re: PCM Hammer P04 Support Project

Post by Cincinnatus »

[11:14:39:304] Elapsed time 00:03:08.4482016
User avatar
Gampy
Posts: 2330
Joined: Sat Dec 15, 2018 7:38 am

Re: PCM Hammer P04 Support Project

Post by Gampy »

About 3 minutes according to the log ...

Edit:
Jinx ... Same post time!

-Enjoy
Intelligence is in the details!

It is easier not to learn bad habits, then it is to break them!

If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
darkman5001
Posts: 212
Joined: Sat Dec 18, 2021 8:15 am
cars: 2004 Suburban, 2001 Tahoe, 2002 Envoy, 2006 Envoy, 2003 Lincoln LS
Location: New Jersey, USA

Re: PCM Hammer P04 Support Project

Post by darkman5001 »

Awesome. Glad to see we are moving in the right direction. Anyone else that is interested in testing their P04, I need your OSID to add, then I can send you a test. As long as your adapter to connect to the PCM is adequate enough, I suspect it will be successful.
User avatar
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: PCM Hammer P04 Support Project

Post by antus »

The one before the last working one needs 12214378 added to pcmhammers list of OSIDs. pcmhammer has defaulted to p01/p59 and therefore fails the unlock.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
darkman5001
Posts: 212
Joined: Sat Dec 18, 2021 8:15 am
cars: 2004 Suburban, 2001 Tahoe, 2002 Envoy, 2006 Envoy, 2003 Lincoln LS
Location: New Jersey, USA

Re: PCM Hammer P04 Support Project

Post by darkman5001 »

antus wrote:The one before the last working one needs 12214378 added to pcmhammers list of OSIDs. pcmhammer has defaulted to p01/p59 and therefore fails the unlock.
Done. Actually the one before last and the last one are one in the same. Once I added the OSID the read was successful.
User avatar
Gampy
Posts: 2330
Joined: Sat Dec 15, 2018 7:38 am

Re: PCM Hammer P04 Support Project

Post by Gampy »

If the P04 OsID list is being reconstructed with confirmed OsID's, here is another confirmed OsID: 12594316

-Enjoy
Intelligence is in the details!

It is easier not to learn bad habits, then it is to break them!

If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
darkman5001
Posts: 212
Joined: Sat Dec 18, 2021 8:15 am
cars: 2004 Suburban, 2001 Tahoe, 2002 Envoy, 2006 Envoy, 2003 Lincoln LS
Location: New Jersey, USA

Re: PCM Hammer P04 Support Project

Post by darkman5001 »

Gampy wrote:If the P04 OsID list is being reconstructed with confirmed OsID's, here is another confirmed OsID: 12594316

-Enjoy
I have this added as an AMD P04.
User avatar
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: PCM Hammer P04 Support Project

Post by antus »

I think you should have two test builds with the different packet sizes but each build is the same for all known OSIDs. Or make it selectable in settings. It doesn't make sense to me that the type of flash chip would make any difference for packet size for reading as the chips are functionally equivalent for reading and clocked at the same speeds. What type of chip it is matters for the flash process though. For read it is just operating normally hanging off the side of the CPU. You might be able to disprove the requirement for different speeds, or maybe it will be confirmed even if its not clear why at this stage. At this stage the confirmed sample size for different packet sizes is too small to be conclusive. That test kernel on my PCM the actual bin made a difference, I could only get 8 byte packets. If I used the same hardware on another tool I could get any size packets, and if I put a different bin on my pcm, I could get larger packets with the pcmhammer test kernel.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
darkman5001
Posts: 212
Joined: Sat Dec 18, 2021 8:15 am
cars: 2004 Suburban, 2001 Tahoe, 2002 Envoy, 2006 Envoy, 2003 Lincoln LS
Location: New Jersey, USA

Re: PCM Hammer P04 Support Project

Post by darkman5001 »

Antus, I tried using same packet sizes for both the AMD and the Intel P04s using exactly the same hardware and J2534 for both. For some reason I haven't gotten an AMD P04 to read more than 512 packet size. If I try to read more than 512 I get an error. However the Intel chip responds without error and I have read 2048 with no problem on the Intel version. I am not sure what the issue between the two is, but since flash ID is not working for the P04, dividing the two up seemed like the best next option. As long as I put the OSID under the correct flash chip version it seems to read perfectly fine.
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: PCM Hammer P04 Support Project

Post by Tazzi »

I can probably comment on this a bit with messing with the P04s alot.

Some operating systems for the P04 will significantly impact the bit timing for the VPW frames. Even though the kernel is custom code that is being executed, the operating systems setup interrupts are still running in the background which is what makes the difference.
Pete and I had two P04s running two different operating systems, one would read/write perfectly fine at 4x, whereas the other would have HUGE issues and constantly result in corrupted frames (Tested on multiple J2534 tools including our own OBDX tool).
We also confirmed it was the OS since since we switched firmwares on both ECUs and the issue them moved to the other ECU.

When looking at the timing on a logic analyser, the crappy OS was occasionally sending some "short" bits for way to long, which resulted in them being picked up as "long" bits. We fixed this issue by adding a resistor to ground. We found on those ECUs, the only real fix was reading/writing by 1x as 4x was not reliable without adding the resistor.

The above may not be what your seeing, but we hit this issue specifically on P04s, and reduced the packet size as well to minimize the chance or a bad bit.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
Post Reply