Ah, I wondered if it was a trial read of a smaller set of blocks or if I missed some. File attached. I will attempt another read as soon as I can.Originally Posted by kur4o
Definitely possible that the cable was loosened. I can't find my better usb cable for the obdx so the one I'm using is only 12" and loose.
What other databases are in your program??! Your work is amazing.
looking at the log, to my amateur eyes it looks like it send another request but received nothing back after 07 F0 00 <-- is that the address of the next data block requested? I've done some in depth disassembly so I'm not completely oblivious.
07 F0 00 is the address of last block. I suspect the communication dropped earlier than that point. The usb cable might be one of the reason.
When you do more testing can you save all the bus messages in vpw console. It will help alot where it fails and what needs to be optimized.
Universal patcher have support for ls1 calibration, and most v6 FWD, and covers lots of gm pcm for DTC editing and checksums, some limited tuning available for e38.
Here's the VPW console stuff from that.
I'm going to make a second attempt right now.
This second attempt was an obvious fail. Didn't make the file at all.
This one got further, but still failed. I accidently saved it in a weird place again. Searching on windows 8 is impossible for me so I have no idea where the files are, but I don't think it matters
This also looks like after the app gets spooked, the communication continues and it dumps the remaining blocks after.
When this is happening the guages reset and it stops and wants to save, but it's definitely before the end of the data stream. Somewhere in the 02 80 00 area. Then I notice the data come through significantly faster. These attempts are very slow data transfers. Each block takes 5 seconds or so. Not sure what's normal.
First and last log does seem complete. On first at some point timestamps get lost, by any chance you have unchecked the timestamp checkbox mid script. Last log don`t have timestamps at all and is also complete. Does the bin saved in full 512kb and can be opened in tuner.
The communication looks solid now. Now we need to debug why it fails with pcmhammer.
On the 2 failed logs I think script file got messed somehow. If you have done some modification to it, it might lost some encoding and the program can`t read it.
I'll try again with the timestamp back on. Not sure why I turned it off, but I did uncheck it. I cannot find the files saved from those logs. I don't know if they saved at all.
I definitely didn't modify the script, I wouldn't know what I'm doing at all.
I got it! Thanks!
Now... how do I upload and since this has been experimental and temperamental should I worry about an issue happening and bricking the PCM?
Last edited by Professwrx; 10-05-2023 at 07:46 PM.
Uploading is a bit tricky, It is easy to make a script, but there is no error detection and retries.
Great news is pcmhammer beta is finally released. It have been tested really well, but it is still a beta so use on your own risk. I think getting a spare pcm from ebay will be 20-40$ and will get you a piece of mind if something bad happens.
Here is the link
https://pcmhacking.net/forums/viewto...124498#p124498
wow, that is some shocking timing for that to be released!!
thanks for everything you’ve done man.
time to order a back up PCM for sure.
Ok, so I put in a new PCM with the same part number, but I'm having the same issue with PCM hammer. It doesn't recognize it at all. YFXS is the code on this new PCM. I can't get the logger to see any chatter. I can't pull any codes from it. It might be completely dead or there's a major step I'm not aware of.
Last edited by Professwrx; 10-14-2023 at 08:06 PM.
PCM hammer beta does not work for my car. I was able to get my account set up on PCMhacking so I posted there. Hopefully this can be sorted shortly. Stock driveability is lacking.
Last edited by Professwrx; 10-14-2023 at 11:51 PM.
Posting Permissions
Reply With Quote
Bookmarks