PCM Hammer 15 Failed Erase

[smartman__007]

I'm fairly confident it erased because the first block it tried erasing had the CRC change. I'd rather not power down the PCM to prove your theory,

You don't think the hand ran "Erase Sector" command succeeded? I sent the same bytes the App does to initiate a block erase, after modifying the Scan Tool's (STN1110) timeout setting to be 3000 milliseconds. (STPTO command allows a value larger than 255 * 4 milliseconds). I then compared the returned bytes to a working debug log file I found elsewhere on the forums and it is identical. I'm not saying it took 7 seconds, (It didn't, it took between 1 and 3 seconds I would say). Some devices are just slower in my experience due to tolerances, build binning, age, voltage, etc... I'm not saying it's a tool failure, but it appears to be a timeout setting that is too low to accommodate this specific PCM for some reason.

[smartman__007]

I just confirmed my assumptions. I swapped the deprecated STN timeout command (AT ST) for the newer (STPTO), extended it to 3000 milliseconds for the erase, and the PCM is flashing successfully as I type this.

[smartman__007]

I forgot I was running a differently configured PCMHammer, so it didn't save the log files on close. You'll have to trust me that it worked successfully, and flashed the entire PCM. The tool even reported that it didn't require any retries which I thought was surprising.

1. Update eraseRequest.MaxTimeouts in EraseMemoryRange() to 7
2. Change "AT ST" to "STPTO" in ElmDevice.cs SetTimeout() STPTO takes milliseconds in decimal as parameter
3. Change TimeoutScenario.EraseMemoryBlock in ScanToolDeviceImplementation to 7000 (Largely Overkill, wanted to be certain)

I was able to completely reflash my PCM, and it now responds to OSID, VIN, and other commands again.

[Gampy]

Awesome!

Why would anyone have reason to doubt you ...

I don't disagree, some PCM's do respond slower, no doubt about it, timing has been a constant tuning headache.
Personally I'm the kinda guy that would just set it long and not worry about it, unfortunately there are those that are in a hurry in life and would bitch because PcmHammer takes 5 seconds longer then tool x.

AT ST is not depreciated, it is an ELM command, not a STN command.

Now that you fixed it, do an OS change using release 015, not a modified version ... does it work ??

I just upgraded my STN1110 to v5.0.0 did two flawless OS changes on a P01. Pure Perfection!

[smartman__007]

Yeah, I'm with you on setting it to worst case. The system responds as quick as it can, so in theory it will only allow more devices to work, and the existing devices will be as fast as they've always been.

AT ST is "deprecated" in STN's documentation: Table 5 on Page 8 for their chips. As far as an ELM327 command, you're correct. My assumption would be STN is trying to migrate people to the better command they offer with a wider range of timeouts and an easier interface if backwards compatibility isn't required with standard ELM327 tools. (No silly x4 multiplier)

Edit: Also, the ELM327 command only allows a maximum of 255 x 4 milliseconds for a delay, which is probably not enough to recover from my scenario for whatever reason.

I will give that a shot with Release 015. I do not have high expectations for it, but I will try it once, and report back.

I was skeptical on the STN1110 firmware version 5.0.0 causing any issues. Release notes didn't indicate anything, but it was worth a shot. Awesome! Glad we got that marked off the list as a culprit.

[Gampy]

Gee wiz! I can't win for losing today ... Guess I should go climb back in my hole and STFU!

Semantics, to me depreciated means they are going bye bye, they are not, they have been superseded by the more powerful ST commands.

[smartman__007]

Haha, no worries! I really appreciate the help and guidance. I was on a mission to not end up with a paper weight for a PCM at the end of the day and have been bit WAY too many times by not reading the f****** manual.

Seems like a decent change to make if the Apps only support STN ELM327 devices, (I may have to check into that some more). I’ll try to throw up a pull request and see if they want the changes I’ve made or not. This is a great community and tool. I just wish this stuff was around 16-20 years ago when I first started doing this stuff.

[smartman__007]

Here's the before/after logs I promised. The failure is with the old 'AT ST XX' command setting the timeout, and the Success uses the STN 'STPTO' timeout commands with a value of 7000 milliseconds. I didn't go back and set things to 3000 and rebuild for this test. But, I do see that the erase block command took 1050 milliseconds to complete according to the debug logs. I also only tried erasing the calibration so I didn't end up with a brick if things failed and my power dropped out. Seems like I was only 50 milliseconds away from success.

[09:53:33:986] Setting timeout for EraseMemoryBlock, 7000 ms.
[09:53:33:986] TX: STPTO 7000
[09:53:33:989] OK
[09:53:33:995] TX: STPX H:6C10F0, R:1, D:3D05008000
[09:53:35:045] RX: 6C F0 10 7D 05 00 00

PCMHammer Logs.zip

PCM Hammer Logs Before/After

(50.43 KiB) Downloaded 216 times

[antus]

It looks like someone sent us a pull request for this change. Thanks if that was you. It looks like it might break the allpro so we'll have to do some more investigation so we might need to do it another way but its good information that your pcm took this long to erase and this fix worked.

[Gampy]

As Antus has already eluded to, the changes as they are, would in fact be incompatible with the AllPro ... No investigation necessary!

Although WTF do I know, I've been wrong about everything in this thread ...