PCM Hammer Suite development

[NSFW]

There's a problem with the change that made the delay dialog modal, but I will push up a fix in a few minutes. The 'write' background thread is now trying to do UI stuff, but the fix is just to move the delay dialog into the same .Invoke() call that was used for the file-open dialog.

[NSFW]

The fix for the delay dialog is in.

The app works better with the XPro with these changes. I'll try it in my car tomorrow and push out a new release if that goes smoothly.

[Gampy]

Sorry I've been out of the loop for so long, but I just fixed the LPT issue and merged a bunch of pull requests.

The only PR I didn't merge is the one that removes a bunch of WasteTime calls, because Antus had a PR that might also be sensitive to timing changes, so I want to test before and after first.

The others all looked straightforward so I figured I'd merge first and test later.

It's cool, you have a life to live ...

I have tested with Antus's PR #156, timing is fine, besides that they are purely local to flash and not affected by outside influence or vise versa.

The one I'd recommend a look at is the Autel fix, Obviously Antus looked at it and approved of it so it should be ok.

There's a problem with the change that made the delay dialog modal, but I will push up a fix in a few minutes. The 'write' background thread is now trying to do UI stuff, but the fix is just to move the delay dialog into the same .Invoke() call that was used for the file-open dialog.

So I can delete the Pull Request I have waiting here to do that ...
I try not to push things that would cause you merge conflicts so I was waiting for merges to take place.

The fix for the delay dialog is in.

The app works better with the XPro with these changes. I'll try it in my car tomorrow and push out a new release if that goes smoothly.

Awesome ...

Thank you

[NSFW]

Flashing in my car did not go well... the first flash worked, the second failed. Fortunately the kernel continued running so the app was able to start over and I didn't have to remove the PCM from the car this time.

I'm guessing there's something wrong with the timing of the response to the 'erase' command since that's where it failed last time and this time. But then again this only happens in the car, never on my desk, so it could be cause by interference from other modules. Weird that it happens at the same step both times though.

[Gampy]

Bummer ...

Does it happen at the same point (address) as well ??

Is it the app side that is impatient ??

Does disconnecting other modules help ??

Not that you need help diagnosing ... I'm just curious.

if it was me, I would first try removing the,
.. 4 WasteTime()'s in intel_EraseBlock() ... (As PR#152 does)
.. 1 VariableSleep(2) in HandleEraseBlock() ... (As a un-pushed PR does)

[NSFW]

I think it might be due to a timeout. I was working on reducing various timeouts for AllPro and LX last night and the response to the Erase command takes forever. (AllPro is way faster now though.)

I'll see if those changes help, thanks for the ideas.

[Gampy]

Gosh I hope the AllPro works on bench.

I have been testing the following for about a week now ... They are the only two time killers I have left in my test kernel.
No issues whatsoever ...

Code: Select all

WriteByte()
	while ((status == 0x02 || status == 0x03) && loopCount < 250)
	{
		loopCount++;

-		// With max iterations at 25, we get some 2s and 3s in the loop counter.
-		for (int iterations = 0; iterations < 50; iterations++) WasteTime();
+		//PrivateSleep(1, 25);  // Match original 200 NonOps.
+		PrivateSleep(1, 2);

		ScratchWatchdog();
		status = DLC_STATUS & 0x03;
	}


WriteMessage()
		while (status != 0 && loopCount < 500)
		{
			loopCount++;

-			for (int iterations = 0; iterations < 100; iterations++)
-			{
-				ScratchWatchdog();
-				WasteTime();
-			}
+			//PrivateSleep(1, 50);  // Match original 400 NonOps.
+			PrivateSleep(1, 2);

			ScratchWatchdog();
			status = DLC_STATUS & 0x03;
		}

[NSFW]

The key thing about getting the AllPro to work on my bench is to have it hooked up to a Y cable with an ObdLink device on the other side of the Y.

I was getting pretty confused annoyed with AllPro kernel uploads failing yesterday when I realized I had the XPro on the other side of the Y harness... switched to ObdLink and the AllPro was happy again. That hasn't been an issue in my car, but it's definitely an issue outside my car.

I've been trying to return the timeouts for the XPro and been having random issues with it, and it just occurred to me that I should try putting the ObdLink next to it instead of the AllPro...

A resistor would probably also work.

[NSFW]

BTW I'll try those kernel timing changes next time. I should have done that before the timeout tuning actually.

[Gampy]

Ignore the following ... I spoke too soon.
------

Bum deal ... Things have gone downhill for my tools. (code current (499d569))

The AllPro is completely nonoperative now, not in 1x or 4x ... unless, as you state, you have a second device connected on a Y cable.
I believe this to be an AllPro issue, not a PcmHammer issue.

I don't have a Y cable, so I guess I'll try to figure out what pins to try a resistor on, maybe the AllPro can be modded (hacked) to add the resistor internally once figured out.
I have NO CLUE as to where to start with what size of resistor or on what pins ... That's above my pay grade.
I'm not afraid to poke around and try. What can I do, teach a broken tool to smoke!

The Sparkfun (STN1110) Uploads (writes) awesome, however downloads (reads) are slow and many retries ... 400 to 500 retries for a read if it survives.
Bunches and bunches of,

Timeout during receive.

Back to back reads do not happen ...