pcmhacking.net

With this script you can read 6,12 or 18 consecutive bytes with different refresh rate.
6 bytes are updates every 15ms

Edit start address for ram in script.

Giving up on getting a TAC dump for now. I feel like this renesas flash tool will work with the right config files, I'm just really not good with hardware. I did measure the clock speed at 16MHz on my oscope, but can't figure out how to set the BRR accordingly- and I get an error trying to connect over the BRR.

Anyways, if anyone else wants to take a look I can pass along all that I've done so far.

Going to focus a little more on the assembly within the PCM and this message hand shake. If I can break down the message maybe I can even determine if the TPS match/mismatch is within the TAC or PCM.

kur4o wrote:With this script you can read 6,12 or 18 consecutive bytes with different refresh rate.
6 bytes are updates every 15ms

Edit start address for ram in script.

sweet I'll give this a try soon.

kur4o wrote:With this script you can read 6,12 or 18 consecutive bytes with different refresh rate.
6 bytes are updates every 15ms

Edit start address for ram in script.

script works great, thanks!

not sure if its the RAM or what but it still misses frames of communication. The only way I've found so far to miss nothing is to use a standard UART and serial terminal. Likely the RAM just isn't updating quickly enough. I have the PCM/TAC coms mapped generally but there is some bit mapping left to do. I have all the TPS_desired and TPS_indicated and APP_indicated portions nailed. I have many of the TAC state PID booleans mapped, but more to do.

There must be a hard-set ~31.4% TPS max limit in the tac module when APP=0. I'm really bummed. I tried looking a little at the PTO logic but I fear it will have the same TPS limit as I noticed it has a max allowed area. ~31.4% is more than I was getting before and I found some other limiters and RAM variables to log to ensure I know which limiters I'm hitting...so all in all not a complete failure- but I'm short of complete control.

I also can't change the TPS sensor calibrations without tuning the tac so I may put some more time on trying to dump it and reflash it. Seems like I could do it chip level but I haven't been successful yet.

I know this has been going for a while so maybe it was already suggested... but my truck had a max idle area setting in the ECM that I had to increase because it was overriding my other idle settings. no matter what I did it would not increase the throttle over that amount if app was 0%

gmtech825 wrote:I know this has been going for a while so maybe it was already suggested... but my truck had a max idle area setting in the ECM that I had to increase because it was overriding my other idle settings. no matter what I did it would not increase the throttle over that amount if app was 0%

yeah I've exhausted all tuning options within the PCM.

the only thing I'm not 100% sure on is if it is a TPS max or an area% max. I'll mess with that today and see.

RADustin wrote:

gmtech825 wrote:I know this has been going for a while so maybe it was already suggested... but my truck had a max idle area setting in the ECM that I had to increase because it was overriding my other idle settings. no matter what I did it would not increase the throttle over that amount if app was 0%

yeah I've exhausted all tuning options within the PCM.

the only thing I'm not 100% sure on is if it is a TPS max or an area% max. I'll mess with that today and see.

actually I know it's a TPS limiter because the PCM is only sending the TAC a few status bits and a desired TPS. And when I log the coms during a fail, the TAC coms change and error first. So the error is coming from the tac, based on TPS from the PCM. The status bits on the PCM Side don't change until after the TAC message bits change.

if the comms is just serial and you understand them, could you replace the control logic hardware completely but keep the electronic throttle assembly? run from a pro micro or something? obviously would be safety considerations in the implementation and not for road use.

antus wrote:if the comms is just serial and you understand them, could you replace the control logic hardware completely but keep the electronic throttle assembly? run from a pro micro or something? obviously would be safety considerations in the implementation and not for road use.

definitely possible- and is essentially what some companies are doing... that are converting signals and splitting logic and what not. Me not being a hardware person I was on the assumption that a 'simple' retune would be best. I was hoping I would run across someone with experience in dumping and flashing these older chips. I have experience with JTAG but this is older than that. Also I'm only looking to make two changes to the programming, the max idle TPS and inverting one of the TPS ranges, so it just seems easier to reprogram vs all new.

I'd bet the process is super simple, just not well documented.

RADustin wrote:

antus wrote:if the comms is just serial and you understand them, could you replace the control logic hardware completely but keep the electronic throttle assembly? run from a pro micro or something? obviously would be safety considerations in the implementation and not for road use.

definitely possible- and is essentially what some companies are doing... that are converting signals and splitting logic and what not. Me not being a hardware person I was on the assumption that a 'simple' retune would be best. I was hoping I would run across someone with experience in dumping and flashing these older chips. I have experience with JTAG but this is older than that. Also I'm only looking to make two changes to the programming, the max idle TPS and inverting one of the TPS ranges, so it just seems easier to reprogram vs all new.

I'd bet the process is super simple, just not well documented.

Would inverting one of the TPS ranges allow the use of Gen4 throttle bodies without the $200+ adapter?