PCM Hammer 98/99 Black Box Support

[antus]

It looks like the OBDLink is too slow and the time it takes for the OBDLink to do its thing plus the time it takes the blackbox to do its thing at the crc stage causes timeouts. I don't test PCM Hammer against my OBDLink normally because the thing is so slow its painful, but I dusted it off and did a read on the black box on the bench to confirm your report and observed the same timeout. I then moved across to the XPro GT and repeated the read and it worked fine. If you have another interface try that, and I'll put it on my list of tasks to allow a little longer in the timeouts on the PCM Hammer side to cover this use case in a future version.

Update:
It's not actually a timeout, the PCM is not receiving the request. It takes the PCM 3.2 seconds to calculate the CRC for the first sector with a different type of interface, and it keeps waiting for the response for up to ~27 seconds.
Further I dont see the OK come back from the OBDLink against the transmit. So the problem is now why does it always fail on this transmit operation and not elsewhere in the flash process with OBDLink?

[01:48:57:566] TX: STPX H:6C10F0, R:1, D:3D02020000060000
*** Should be an OK in here, but there is nothing ***
[01:49:04:698] Timeout during receive.
[01:49:04:699] CRC read failed, re-trying 00060000 / 00020000
[01:49:08:795] Timeout during receive.
[01:49:08:796] CRC read failed, re-trying 00060000 / 00020000
[01:49:12:881] Timeout during receive.
[01:49:12:881] CRC read failed, re-trying 00060000 / 00020000
[01:49:16:987] Timeout during receive.
[01:49:16:987] CRC read failed, re-trying 00060000 / 00020000
[01:49:21:091] Timeout during receive.
[01:49:21:092] CRC read failed, re-trying 00060000 / 00020000
[01:49:25:183] Timeout during receive.
[01:49:25:271] Something went wrong. Object reference not set to an instance of an object.

[antus]

Got it. The default timeout on the OBDLink is 3000ms for CRC. The Blackbox happens to respond in 3100 ms and that is right in the time when the first poll expires and before the next poll starts. So the response is missed. Just another reason these polling interfaces are junk compared to the streaming ones. Anyway, I bumped the CRC timeout up to 4000ms (from 3000ms) and now it waits long enough and can complete the read and CRC on the black box. Looks like I'll need to create a test build for black box users with the latest code and this change.

Screenshot 2026-02-19 174347.png

Update: You can get the fixed version here (github account needed): https://github.com/PcmHammer/PcmHammer/ ... 2172959025

[SmichaelR22]

thanks for efforts!!! I was able to pull a bin with the new version and attached it for reference.

moved on to finding an 16265175 XDF for tuner pro editing, found nothing.
Found a thread with a 16265175 VATS patch here: viewtopic.php?t=9079

failed to loaded it, and have appeared to have bricked the PCM.
will not read properties: VIN query failed: UnexpectedResponse
either of my other OBD scan tools will not communicate with the PCM any more either. i forgot to check if HP tuners will before i left the shop.

bah.

[antus]

That is bad news

I tested the same version here and it is working correctly at my end. I noticed you have 10 communication retries in your log, which is a sign there may be poor quality power or signal on your bench, that could be the root cause. Also 12.2v which is above 12, but if it were me I would be looking for 12.5-13.5. My bench runs at 13.581v. The communication failures have basic checksums and retries. A real error can slip through every so often, but unlikely to be the cause here as it retried 3 times with the same result. I think the PCM was genuinely failing to be able to write the flash for a reason external to PCM Hammer.

For this test I put some junk in the bin at address 6200 which is an unused sector that is not included in the checksum tested by the OS. This means that the change causes a sector to go through an erase / write cycle for testing but if it fails it won't brick because the sector is not used for anything. I am not aware of a way to BDM recover this generation and to my knowledge they are too old to have the recovery mode in the boot sector. If anyone knows otherwise let us know. I only have 1 PCM and so far its never been bricked.

[08:49:25:161] Saving contents to C:\Users\a\Downloads\blackbox_test1.bin
[08:51:11:377] C:\Users\a\Downloads\blackbox_test1-antus at 6200.bin
[08:51:11:401] Identifying 512KiB file.
[08:51:11:415] File is Vortec BlackBox 512KiB.
[08:51:11:428] File operating system ID: 9365085
[08:51:11:439] File is Vortec BlackBox 512KiB.
[08:51:11:448] Start End Stored Needed Verdict Segment Name
[08:51:11:461] 20002 668CF 4DF6 4DF6 Good Operating system
[08:51:11:473] 08002 0E651 82F3 82F3 Good Engine calibration
[08:51:11:486] 0E654 0EF93 C056 C056 Good Fuel system
[08:51:11:499] 0EF96 0F0D1 2D6A 2D6A Good System
[08:51:11:513] 0F0D4 0F109 2D69 2D69 Good Speedometer
[08:51:11:528] 14906 14923 06FF 06FF Good VIN
[08:51:11:544] 0F10C 14903 33EE 33EE Good Transmission calibration
[08:51:11:560] Requesting operating system ID...
[08:51:11:615] File is Vortec BlackBox 512KiB.
[08:51:11:631] PCM and file match hardware BlackBox
[08:51:11:650] File is Vortec BlackBox 512KiB.
[08:51:11:667] PCM and file are both operating system 9365085
[08:51:14:864] Unlock OK.
[08:51:14:900] Attempting switch to VPW 4x
[08:51:14:938] Module 0x10 (engine controller) has agreed to enter high-speed mode.
[08:51:21:118] Upload permission granted.
[08:51:21:544] Kernel upload 100% complete.
[08:51:24:683] Kernel Version: 82400288
[08:51:24:696] Kernel uploaded to PCM successfully.
[08:51:24:718] File is Vortec BlackBox 512KiB.
[08:51:24:731] PCM and image file are both operating system 9365085
[08:51:24:752] Flash chip: Intel 28F400B, 512KiB
[08:51:24:764] Calculating CRCs from file.
[08:51:24:778] Requesting CRCs from PCM.
[08:51:24:789] Range File CRC PCM CRC Verdict Purpose
[08:51:27:923] 060000-07FFFF 2B5D35B4 2B5D35B4 Same General
[08:51:31:082] 040000-05FFFF 7F2C45F4 7F2C45F4 Same General
[08:51:34:226] 020000-03FFFF F45CAD6A F45CAD6A Same General
[08:51:36:611] 008000-01FFFF 45983FA8 45983FA8 Same General
[08:51:36:863] 006000-007FFF 5B18E624 85B5BB36 Different General
[08:51:37:089] 004000-005FFF 85B5BB36 85B5BB36 Same General
[08:51:37:503] 000000-003FFF EF6FF421 EF6FF421 Same General
[08:51:37:520] Processing range 006000-007FFF
[08:51:37:538] Erasing.
[08:51:38:368] Writing...
[08:51:42:762] Calculating CRCs from file.
[08:51:42:803] Requesting CRCs from PCM.
[08:51:42:823] Range File CRC PCM CRC Verdict Purpose
[08:51:45:963] 060000-07FFFF 2B5D35B4 2B5D35B4 Same General
[08:51:49:123] 040000-05FFFF 7F2C45F4 7F2C45F4 Same General
[08:51:52:263] 020000-03FFFF F45CAD6A F45CAD6A Same General
[08:51:54:645] 008000-01FFFF 45983FA8 45983FA8 Same General
[08:51:54:881] 006000-007FFF 5B18E624 5B18E624 Same General
[08:51:55:117] 004000-005FFF 85B5BB36 85B5BB36 Same General
[08:51:55:535] 000000-003FFF EF6FF421 EF6FF421 Same General
[08:51:55:567] All relevant ranges are identical.
[08:51:55:580] All write-request messages succeeded on the first try. You have an excellent connection to the PCM.
[08:51:55:592] Flash successful!
[08:51:55:616] Clearing trouble codes.
[08:51:56:687] Elapsed time 00:00:41.7973991

[SmichaelR22]

ya it did the 10 thing, and i was afraid to mess with it and just let it crank. I forgot the throw the battery charger on it since i was so excited to try it first thing in the morning when i saw your post. at least i have the bin file, and i have an HPT file. Its not a huge issue as this is just a rock crawler that needs to just run in basic form.

i will be able to make a more proper bench flash setup using my normal P01/P59 swap power supply now that i have the black box harness plugs pulled from 0411 swapping this harness this afternoon lol.

Part of me never wants to touch a black box again, but ill grab a few at the local yard next time, as i hate being beat.

[antus]

how are you with hex editors? when your testing next have a look in the stock bin and if its empty (all FF) from 4000-5FFF or 6000-6FFF then you have at least 1 unused flash sector outside the checksum. You can type something in, I tend to go for address 6200 because sometimes there could be special purpose stuff - headers - right at 6000 the pcm might be looking for, so to stay clear of that and save to a new clearly marked file. Check the file is still healthy with a verification test then write that. It should only erase and write the unused sector and if it fails wont brick the pcm. Then you can do a genuine write with your changes after that. If it does fail you can look at power / wiring again and keep testing.

[CDNL]

Hi all,
I'm a newly minted member on this forum. Firstly, I would like to thank the people that allowed me to join. I'm new to forums in general and new to pcm tuning, although I have tinkered with cars for a long time. So, if I should happen to break forum rules it's not by intent but out of ignorance. I'm not a mechanic just someone who knows enough to get himself in trouble. I have downloaded copies of PCPHammer with 2.0 preview and PMHammer with the beta extension. My interest at the moment is to try and tune GM 96 -99 Black box pcms. I have built a bench harness to connect to them and have tried reading the two boxes that I picked up from the junkyard using both of the above mentioned PCMHammer versions. I had the same exact problem that SmichaelR22 had. I understand from the post from antus that the problem was was fixed and a newer version of PCMHammer is available. However, I am not a member of GitHub so I was hoping to get a copy from someone in this forum. To see if it would read the black boxes I have.
Thanks in advance for your help

pcmhammerlog1.txt

[antus]

Welcome aboard! Firstly, delete pcmhammer 2.0-preview. That is a development release with known problems and has been officially removed. Development happens at a pace compatible mostly with my available free time and interest, but anyone is welcome to join the project and submit any code on github to improve the product. I could post a recent build here, but I have learnt from with happened with pcmhammer-2.0-preview is that if that happens then we end up loosing track of what is posted around the place and development versions with known problems end up being used by people who do not properly understand the risk. For this reason I like people who are working with the new pcms in pcmhammer 2 to have to create an account and download from github actions. This way it is clearer what they are doing and they they can see it is not a general release. The latest development version you want is available here, when you are logged in, from the download link in the bottom right hand corner of the page. Github accounts are free. https://github.com/PcmHammer/PcmHammer/ ... 2173043169

[CDNL]

Thanks for the quick reply. I will proceed as per your instructions. Once I have the program I will use it to read the pcms that I have and post the results.

[CDNL]

Well, I downloaded the latest version of PCMhammer from gihub and was able to read both of my pcms without any problems. As it turns out, my pcms have the same OSIDs as others on this thread. The read took over ten minutes, because I am using an OBDlink sx as my connection. Which is fine with me because I don't mind waiting. I know they are considered junk by some, but it lets me do a read on the black box pcms with something that I already have. No one asked, but if someone were to ask for my two cents worth, I would vote to leave it in PCMHammer. I have attached the bin, result and debug files in case they may be useful to someone else.
At the moment I'm having problems with Universal Patcher not being able to read the data in the bin files. And am wondering if this the place to have this discussion or whether I should bring this up on another thread. Thanks in advance for your help.