PCM Hammer Release 014

They go by many names, P01, P59, VPW, '0411 etc. Also covering E38 and newer here.
User avatar
Gampy
Posts: 2331
Joined: Sat Dec 15, 2018 7:38 am

Re: PCM Hammer Release 014

Post by Gampy »

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 ...
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!
ColPaul
Posts: 36
Joined: Tue Dec 31, 2019 11:24 am

Re: PCM Hammer Release 014

Post by ColPaul »

I just got v14 compiled. I’ll remove the first call and leave the finally block to see if that resolves it.
User avatar
Gampy
Posts: 2331
Joined: Sat Dec 15, 2018 7:38 am

Re: PCM Hammer Release 014

Post by Gampy »

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.
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!
ColPaul
Posts: 36
Joined: Tue Dec 31, 2019 11:24 am

Re: PCM Hammer Release 014

Post by ColPaul »

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.
ColPaul
Posts: 36
Joined: Tue Dec 31, 2019 11:24 am

Re: PCM Hammer Release 014

Post by ColPaul »

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
Gampy
Posts: 2331
Joined: Sat Dec 15, 2018 7:38 am

Re: PCM Hammer Release 014

Post by Gampy »

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(...).
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!
User avatar
Gampy
Posts: 2331
Joined: Sat Dec 15, 2018 7:38 am

Re: PCM Hammer Release 014

Post by Gampy »

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(...) ...
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!
ColPaul
Posts: 36
Joined: Tue Dec 31, 2019 11:24 am

Re: PCM Hammer Release 014

Post by ColPaul »

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
Gampy
Posts: 2331
Joined: Sat Dec 15, 2018 7:38 am

Re: PCM Hammer Release 014

Post by Gampy »

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

Are you willing to try some changes from me ??
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!
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 Release 014

Post by antus »

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: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
Post Reply