antus wrote: Thu May 22, 2025 11:53 pm
Neither. It looks to be working properly, but the PCM is refusing the request to upload the kernel to the address we are using on other PCMs. It likely would be able to work, if we can figure out what memory range that PCM needs. If you can provide the service number for our records, that will be useful. We can see if any of us have the same type, and if it is working for us, then it is something particular about your pcm. If we can get one and get the same results we can compare to other tools and maybe change the load address to solve it.
I think I had it in the original post?
Serv No. 12583827
HDW No. 12582720
Are those not the numbers you need? or is there something else?
Sorry I probably just missed it. I am always half between day job and then dropping in and out of active threads responding to the last post. You can also try it a couple of times. I have a memory that when I was seeing similar on mine, sometimes it would be accepted by the PCM. Maybe try it 3 or 4 more times (hitting re-init device in between attempts) and if you get the same result, then it definitely doesn't like the load address. If it suddenly does work then you will get a read but it'll remain unclear why it was saying that.
Im going into attempt 4 or 5 at this point. Checking different different troubleshooting items off the list between each attempt to see if im over looking something.
Should I just try cloning it to a known good .bin file from another car?
EDIT: Tried Cloning it with a known good .bin file. No luck. Still cant get permission.
I am little bit confused though, as this Serv#/HDW# match my monte carlo. It was able to load the kernel when I attempted an in-car read.
If they're the same PCM shouldn't it be able to read both of them?
This is the type of stuff we often need to solve during development. When its working fully, you as a user never see these types of problems. During development we do see things we don't (yet) understand and its the developers problem to figure out what is going on and modify the software so that it is reliable. In particular P04 have a reputation for strange problems to solve as they are an earlier system than later types of PCM where GM have improved and matured the design of the operating systems. Something like this happening is often because we don't understand all of the logic or addresses we need to use for 100% reliability across all P04s. We can compare to other programs but our kernel size is different thus what we overwrite in RAM even if we do use the same address to load in the PCM is different and everything works a little different. In particular not all pcms being able to load the kernel is something we did see earlier in the development cycle. I thought we had a setup that was 100% now but maybe not. Your reports is helpful and just what we have this preview testing to look for.
After multiple .dlls for different VCIs and a whole lot of dicking with COM drivers, I finally just disabled High Speed Transfer in PCMHammer Settings and it worked.
Succesful Read Results for 2003 Malibu - P04 PCM - Serv No. 12583827/HDW No. 12582720
User Logs, Debug Logs, and .bin files
Fantastic. Thanks for the feedback. I dont think the DLLs etc were you're problem, but it seems the PCM would have been refusing to allow upload at 4x for some reason, but did accept the request when it was running at 1x.
I think soon we may need to add some documentation to the tool about common faults. Covering attempts at lower speed, something for smaller packet sizes, the existence of known incompatible tools, and bench flashing versus in the car flashing. Maybe we even need a 'safe mode' sort of thing that forces 512byte packets and 1x speed or similar for people to try if they are having no luck. Food for thought.
Just for comparison, this is where the PCM responded OK, instead of a refusal.
