PCM Hammer Release 014

They go by many names, P01, P59, VPW, '0411 etc . Circa 1999 to 2006. All VPW OBD2 PCMs.
User avatar
Posts: 726
Joined: Sat Dec 15, 2018 7:38 am

Re: PCM Hammer Release 014

Postby Gampy » Thu Jul 30, 2020 8:23 am

I did just notice that it is failing on the second call to Cleanup().

Timeout issue maybe in the loop ... still should not crash, it should gracefully bitch and quit.

Never quite understood that, the finally block has worked all the time I have been involved in the project, maybe at an earlier point in development it wasn't being triggered and it's a left over, there is a note in the code that says,
Code: Select all
                await this.vehicle.Cleanup(); // Not sure why this does not get called in the finally block on successfull read?
Obviously that is the first call, the second is in the finally block.

Maybe it's time to remove it ...
Temporary is a permanent problem!

Posts: 35
Joined: Tue Dec 31, 2019 11:24 am

Re: PCM Hammer Release 014

Postby ColPaul » Thu Jul 30, 2020 9:02 am

I just got v14 compiled. I’ll remove the first call and leave the finally block to see if that resolves it.

User avatar
Posts: 726
Joined: Sat Dec 15, 2018 7:38 am

Re: PCM Hammer Release 014

Postby Gampy » Thu Jul 30, 2020 9:53 am

That might get you past the issue, but not solve it ...

It would be better to find the issue and fix it first.

I assume you know right were to look.
Temporary is a permanent problem!

Posts: 35
Joined: Tue Dec 31, 2019 11:24 am

Re: PCM Hammer Release 014

Postby ColPaul » Fri Jul 31, 2020 5:01 am

Gampy, I'm guessing here, but it looks like it having a problem changing back to 4x mode on the 2nd reset. Something in the FindResponseFromTool function.

Posts: 35
Joined: Tue Dec 31, 2019 11:24 am

Re: PCM Hammer Release 014

Postby ColPaul » Fri Jul 31, 2020 6:54 am

I verified that this.ReadDVIPacket on line 164 of OBDXProDevice.cs returns null and line 165 triggers the exception. Line 184 of Vehicle.Kernel.cs sets the device time to a minimum. I assume that the software is not waiting long enough for the response on the 2nd reset request. If so, what should the wait time be. I'll try reseting the wait time at the beginning of ExitKernel() to see if that will avoid the crash. Alternative, should there be null checking in OBDXProDevice.cs after this.ReadDVIPacket to ensure that the device actually responded appropriately?

User avatar
Posts: 726
Joined: Sat Dec 15, 2018 7:38 am

Re: PCM Hammer Release 014

Postby Gampy » Fri Jul 31, 2020 6:55 am

You're guessing pretty right ...

Stack trace says it failed in FindResponseFromTool(...), FindResponseFromTool(...) is called from SetVpwSpeedInternal(...).

I suspect ReadDVIPacket(...) returns a 'null' when it should return a Response<Message> ... Might have a look at line 331 and 342 in ReadDVIPacket(...).
Temporary is a permanent problem!

User avatar
Posts: 726
Joined: Sat Dec 15, 2018 7:38 am

Re: PCM Hammer Release 014

Postby Gampy » Fri Jul 31, 2020 7:30 am

Ah Ha, Port.Receive(...) will bail if it's not in try catch blocks, that is most likely the problem ...
Something like the following,
Code: Select all
                try
                {
                        await this.Port.Receive(rx, 0, 1);
                }
                catch (TimeoutException)
                {
                        this.Logger.AddDebugMessage("Timeout.. no data present.");
                        return Response.Create(ResponseStatus.Timeout, (Message)null);
                }

Obviously adjusted to fit each location in ReadDVIPacket(...) ...
Temporary is a permanent problem!

Posts: 35
Joined: Tue Dec 31, 2019 11:24 am

Re: PCM Hammer Release 014

Postby ColPaul » Fri Jul 31, 2020 9:05 am

I think the delay between this.Port.Send(Msg) in SetVpwSpeedInternal and the this.ReadDVIPacket in FindResponseFromTool is too short. I moved the await Task.Delay(50) to the start of the for loop in FindResponseFromTool in OBDXProDevice.cs, as well as added null checking. The null checking (without moving the wait to the front of the for loop) did catch the error and prevented the crash, but didn't perform the function. Moving the delay to the front of the for loop made the switch to 4x work. Below is the modified FindResponseFromTool for your consideration for change in the next build.

public async Task<Response<Message>> FindResponseFromTool(byte[] expected)
{
//this.Logger.AddDebugMessage("FindResponse called");
for (int iterations = 0; iterations < 5; iterations++)
{
await Task.Delay(50);

Response<Message> response = await this.ReadDVIPacket(this.GetReceiveTimeout());

if (response == null)
break;

if (response.Status == ResponseStatus.Success)
if (Utility.CompareArraysPart(response.Value.GetBytes(), expected))
return Response.Create(ResponseStatus.Success, (Message)response.Value);
}

return Response.Create(ResponseStatus.Timeout, (Message)null);
}


I also commented out the first call to await this.vehicle.Cleanup(); in the try section of ReadContents, which avoided the double call to Cleanup.

User avatar
Posts: 726
Joined: Sat Dec 15, 2018 7:38 am

Re: PCM Hammer Release 014

Postby Gampy » Fri Jul 31, 2020 9:40 am

Pretty sure the issue stems from my previous thoughts ...

Are you willing to try some changes from me ??
Temporary is a permanent problem!

Site Admin
User avatar
Posts: 6322
Joined: Sat Feb 28, 2009 8:34 pm

Re: PCM Hammer Release 014

Postby antus » Fri Jul 31, 2020 10:02 am

Good debugging there. Are you sure the dvi (xpro) isnt crashing, and it really is not returning a response? Can you exit pcmhammer, start it again, and does the xpro init ok from software or does it need a power cycle?
Have you read the FAQ? For lots of information and links to significant threads see here: viewtopic.php?f=7&t=1396

PreviousNext

Return to GM LS1 512Kbyte and 1Mbyte

Who is online

Users browsing this forum: No registered users and 1 guest