pcmhacking.net

antus wrote:It should be enough. It was developed against Australian Commodores, and the logic that is in there seems to work fine on P01 / P59 for other vehicles. No doubt logic holes are starting to appear as we add more platforms. We just need help/time from those with these cars to look at what is breaking, and why, and improve the logic. It is part of the logic tidyup that the app would benefit from.

I am happy to make a modification on my branch to see if it helps.
Although that branch is based on the development branch which does not have the P04 kernels implemented I believe? At least when I tried to force it to write, it did nothing.

I think priority #1 is to get any and all hanging branches in to develop. There are a couple when you look at 'network' in the project, not all have merge requests. We also don't have Gampy's source tree. I have asked him to send a merge request. I think the kernels are fine, and we need to get the loose pieces back together. Then we can add a linter and tidy up the formatting. Then we can move forward from there. For now you can try the antus/p08 branch, but drop the kernels in from Gampys, but I am not certain we used the same load addresses. You may need to look at the logs of Gampy's test build and update antus/p08 branch to use the same for those kernels to work.

Another failure. This time I didn't do anything to provoke it.

Only thing I can think of is the car has been sitting so maybe there was some bus activity that doesn't usually happen if the car is on more recently?

Don't know. I'm hoping another PCM power reset will work as it never got to writing anything beyond the kernel.

5 seconds expired before a bus activity or 3f message being send, And all other modules wake up.

Pcm is in great condition and alive, just remove battery power for 5 seconds and your good to go.

Is there any idea what is doing this?

I really don’t want this to happen in the middle of actually writing.

Should I disable the checksum so if it does happen it’s less likely to brick?

It is design flaw, nothing you can do.

kur4o wrote:It is design flaw, nothing you can do.

Is it with pcmhammer?
So I’d see this same behavior on a bench?

It is a bus control flaw. With single pcm that is running from custom code on bench, you shouldn`t have any problems.

All modules are set to be quiet for 5 seconds, after mode 28 is sent on bus. When that timer expires they reset on their own and start normal communication. Only way to keep that timer on is to send a 3f message within that 5 seconds time frame. It should be hardcoded in pcmhammer, no matter what to keep bus control, within 5 second timer.

Yep known fault that will need to be fixed in a future version. The PCMs supported in the release version function a little differently, most devices dont start communicating again while there is bus traffic and there is 3f messages during the flash process. At this stage there is no fix for pcmhammer, you are running a build to test the kernels only, with enough p04 support that it does work. But you will need to use it on bench until the p04 work is finished. For those of us working on this it is a spare time project, p04 support is not moving fast.

antus wrote:Yep known fault that will need to be fixed in a future version. The PCMs supported in the release version function a little differently, most devices dont start communicating again while there is bus traffic and there is 3f messages during the flash process. At this stage there is no fix for pcmhammer, you are running a build to test the kernels only, with enough p04 support that it does work. But you will need to use it on bench until the p04 work is finished. For those of us working on this it is a spare time project, p04 support is not moving fast.

If I had a clue how, I'd do it. I taught myself everything else, but don't know where to start for all that.

And I can't keep up, is this the same OBDxVT issue or something else?