Inexpensive Opensource Flashing(Read is 100% working)
Since fixing that bricked P59 a few days ago, I figured out what went wrong in the failed flash, and have reflashed it several times without issues.
PeteS figured out why that flash failure bricked it, and I'm going to make a couple changes to prevent bricking in the case of random failures.
Tazzi has a couple of changes in mind that will make it more reliable with ScanTool interfaces.
When all of those changes are in, I'll put out a new release. Hopefully within a couple weeks.
The next release will include a data logger, but the data logger will probably suck. The next-next release, hopefully before January, should have a data logger that actually works reasonably well.
PeteS figured out why that flash failure bricked it, and I'm going to make a couple changes to prevent bricking in the case of random failures.
Tazzi has a couple of changes in mind that will make it more reliable with ScanTool interfaces.
When all of those changes are in, I'll put out a new release. Hopefully within a couple weeks.
The next release will include a data logger, but the data logger will probably suck. The next-next release, hopefully before January, should have a data logger that actually works reasonably well.
I just want to finish up the P59 stuff and get it out there. I know what to do, and I think it won't take long.
The data logger... It does work, but it occasionally pauses for too long between rows of data. I have some ideas for fixing that, and making it faster in general, but it might take a lot of trial and error to get it right, so I don't know how long that will take.
Basically if there are P59 people out there who want to reflash, I don't want to keep them waiting while I fumble around with getting the data logger to work better.
The data logger... It does work, but it occasionally pauses for too long between rows of data. I have some ideas for fixing that, and making it faster in general, but it might take a lot of trial and error to get it right, so I don't know how long that will take.
Basically if there are P59 people out there who want to reflash, I don't want to keep them waiting while I fumble around with getting the data logger to work better.
I just put up a new release with support for writing to the calibration and parameter blocks on P59s:
EDIT: There was a bug. Use Release 8 instead: https://github.com/LegacyNsfw/PcmHac.../2019.11.25.01
Keep in mind that I don't actually have a vehicle with a P59, so I've only done bench testing with it. But I've reflashed the PCM on my workbench about a dozen times now.
Who wants to be the first volunteer to try it in a vehicle?
Keep a spare PCM handy just in case.
EDIT: There was a bug. Use Release 8 instead: https://github.com/LegacyNsfw/PcmHac.../2019.11.25.01
Keep in mind that I don't actually have a vehicle with a P59, so I've only done bench testing with it. But I've reflashed the PCM on my workbench about a dozen times now.
Who wants to be the first volunteer to try it in a vehicle?
Keep a spare PCM handy just in case.
Last edited by NSFW; Nov 26, 2019 at 01:59 AM. Reason: Release 7 couldn't read.
tried read full in vehicle and had errors, full logs of p59 emailed to you. It is a custom 3bar operating system from HPT. Tried 2 different adapters, allpro and vcx nano,
had to disconnect battery to revive pcm each time
Edited to shorten message
had to disconnect battery to revive pcm each time
Edited to shorten message
Last edited by i420tom; Nov 25, 2019 at 11:59 PM.
tried read full in vehicle and had errors, full logs of p59 emailed to you. It is a custom 3bar operating system from HPT. Tried 2 different adapters, allpro and vcx nano, same result error summary below
had to disconnect battery to revive pcm each time
[08:25:23:655] No payload following read request.
[08:25:25:671] ReadMsgs OBDError: ERR_BUFFER_EMPTY
[08:25:25:671] No payload following read request.
[08:25:25:671] Something went wrong. Offset and length were out of bounds for the array or count is greater than the number of elements from index to the end of the source collection.
[08:25:25:686] System.ArgumentException: Offset and length were out of bounds for the array or count is greater than the number of elements from index to the end of the source collection.
at System.Buffer.BlockCopy(Array src, Int32 srcOffset, Array dst, Int32 dstOffset, Int32 count)
at PcmHacking.CKernelReader.<TryReadBlock>d__5.MoveNe xt()
--- End of stack trace from previous location where exception was thrown ---
had to disconnect battery to revive pcm each time
[08:25:23:655] No payload following read request.
[08:25:25:671] ReadMsgs OBDError: ERR_BUFFER_EMPTY
[08:25:25:671] No payload following read request.
[08:25:25:671] Something went wrong. Offset and length were out of bounds for the array or count is greater than the number of elements from index to the end of the source collection.
[08:25:25:686] System.ArgumentException: Offset and length were out of bounds for the array or count is greater than the number of elements from index to the end of the source collection.
at System.Buffer.BlockCopy(Array src, Int32 srcOffset, Array dst, Int32 dstOffset, Int32 count)
at PcmHacking.CKernelReader.<TryReadBlock>d__5.MoveNe xt()
--- End of stack trace from previous location where exception was thrown ---
This is a little embarrassing, but the fix is...
1) del read-kernel.bin
2) copy write-kernel.bin read-kernel.bin
In other words, write-kernel.bin works for both reading and writing.
The P59 requires a small change in the kernel, and I only made that change in the write kernel, because I forgot that we had two kernels, Because the write kernel does work for both reading and writing.
I'll put out another release that just has a single "kernel.bin" to simplify things.
1) del read-kernel.bin
2) copy write-kernel.bin read-kernel.bin
In other words, write-kernel.bin works for both reading and writing.
The P59 requires a small change in the kernel, and I only made that change in the write kernel, because I forgot that we had two kernels, Because the write kernel does work for both reading and writing.
I'll put out another release that just has a single "kernel.bin" to simplify things.
If it produced a 512k file, I'm going to guess that you actually have a 512k PCM. I don't know why else that would happen.
Can you try with a PCM that has a GM operating system on it? I don't have HPTuners, so I don't do any testing with HPTuners (or EFI Live or any other commercial tuning tools), so I can't guarantee they will play nice together.
Also please get Release 8, it does some extra validation after reading from the PCM, which might help explain what's going on.
Can you try with a PCM that has a GM operating system on it? I don't have HPTuners, so I don't do any testing with HPTuners (or EFI Live or any other commercial tuning tools), so I can't guarantee they will play nice together.
Also please get Release 8, it does some extra validation after reading from the PCM, which might help explain what's going on.
In regards to scaling VE tables.
In my experimentation, I was attempting to scale a 6.0 VE table down to accomodate a 5.3 running a 4L80e, to get around segment swapping.
In HP Tuners I would just subtract 12% from the VE and use the 6.0 as a starting point.
Tunerpro seems to start at 0 and go up, and doesn't seem to accept negative values.
So amI going about this all wrong?
In my experimentation, I was attempting to scale a 6.0 VE table down to accomodate a 5.3 running a 4L80e, to get around segment swapping.
In HP Tuners I would just subtract 12% from the VE and use the 6.0 as a starting point.
Tunerpro seems to start at 0 and go up, and doesn't seem to accept negative values.
So amI going about this all wrong?
Try a "quick compare" using a 1mb file, I think it will print the chip ID before it starts the comparison... Yours might have a chip that I haven't seen yet. I'm pretty sure there's an Intel chip that the app doesn't know about yet, for example. That should be easy to fix though.
So far pcm hammer 7 with (new) read kernel produces a 512kb (not 1mb) file but it is corrupt? Last read block Recieved block starting at 520192
Also when trying pcm hammer 8 on this and another p59 pcm I have installed in another car I get same read error at the end on both. Does not save files but the last read block in the logs was
Recieved block starting at 520192 which is same as pcm hammer 7,
So it stops reading after 512kb. As 520192 start block read ends with 524288. 524288 is =512kb as 1kb is 1024.
I am for sure reading 2 different 1mb p59 pcms. But the read stops after the 512kb
Also when trying pcm hammer 8 on this and another p59 pcm I have installed in another car I get same read error at the end on both. Does not save files but the last read block in the logs was
Recieved block starting at 520192 which is same as pcm hammer 7,
So it stops reading after 512kb. As 520192 start block read ends with 524288. 524288 is =512kb as 1kb is 1024.
I am for sure reading 2 different 1mb p59 pcms. But the read stops after the 512kb
Just realized after browsing another forum that it is import to note that I believe both of these are intel f800 flash chip 2003? P59 Pcms.
These pcms are actually an oddball but also desirable p59 computers because they have the ability to control a cable throttle body with IAC.
Most of all the later P59s pcms cannot control the cable throttle as they are missing the IAC drivers on the board and are used solely for drive by wire electric throttle bodys
These pcms are actually an oddball but also desirable p59 computers because they have the ability to control a cable throttle body with IAC.
Most of all the later P59s pcms cannot control the cable throttle as they are missing the IAC drivers on the board and are used solely for drive by wire electric throttle bodys





