PCM Hammer Release 014

[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 ...

[ColPaul]

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

[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.

[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]

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?

[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(...).

[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(...) ...

[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.

[Gampy]

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

Are you willing to try some changes from me ??

[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?