7060 PCM - - DRAC is Current Sensor

[b65cuda]

Thanks for the info 1project2many! Where did you find this? What you said seems to check with what I could see in one of the bins I found, but I'm not sure how I make the changes just yet. I did order a programmer and a couple of chips, but I don't think it'll be arriving until next week. The problem is intermittent, but so far every time I have the scope hooked up it has been selecting the drac. VSS and drac output have so far always matched in frequency. The flag to set the source happens right after you start moving, so I need to catch it "glitching" in that short selection time.

What is interesting is that when it selects the VSS, why does the computer calculate the vehicle speed to be 1/2 and think the transmission is slipping? First I thought it was a bad setting in the aftermarket AXXZ chip, but after removing it and running the stock memcal with AWBP it does the same. I think I would be perfectly happy with programming it to just select the drac, but the curiosity in me still needs to figure out the 1/2 speed issue. One thing that is difficult is the speed sensor data is in the A150.adx, and the speed sensor selected and drac is current sensor are in the A138.adx, so I cannot monitor or log both that the same time. At least I don't know how if there is a way.

One other thing I noticed is there is another flag for loop exceeded 6.25mS that goes on and off constantly and I can't find any information on what that is.

[1project2many]

You're very welcome. There are disassemblies on the page linked above. here. As Dave W noted, the filenames that start with B are actually $D8.

DRAC produces a 2000 Pulse Per Mile signal. Possibly trucks using a magnetic sensor produce a 4000 ppm signal?

Hmm... when a sensor doesn't produce a signal at low speed but seems to work at high speed, the issue could be that the sensor is too far from the toothed wheel. Maybe you can jack up one rear wheel then use a scope or DVOM to watch speed signal while you turn tire by hand? VSS is usually able to produce a signal at very low speed.

[b65cuda]

My eeprom reader/burner came in. I read both the stock AWBP(in the memcal) and the aftermarket AXXZ on the adapter and got some interesting results. The AXXZ matched up pretty well with all of the other $85/$D8 bins with some table tweaks.... but that AWBP is 100% different. Mask ID says $8f instead of $85 and everywhere that should be 00 in the blank spaces is 0A instead. Anyone seen anything like that before? The suburban seems to run with it.

[dave w]

My eeprom reader/burner came in. I read both the stock AWBP(in the memcal) and the aftermarket AXXZ on the adapter and got some interesting results. The AXXZ matched up pretty well with all of the other $85/$D8 bins with some table tweaks.... but that AWBP is 100% different. Mask ID says $8f instead of $85 and everywhere that should be 00 in the blank spaces is 0A instead. Anyone seen anything like that before? The suburban seems to run with it.

The AWBP.bin read I have.

85.JPG

[1project2many]

Anyone seen anything like that before? The suburban seems to run with it.

Maybe, yes. Check the size / number on the chip. At times GM used larger chips and burned the file into the highest addresses. Try changing the start address for reading to $8000. The file you uploaded is not a valid calibration.

[b65cuda]

I did end up reading the chip again as a 64kb and getting the valid results in the other half.

When I attempt to change $900A from $80 to $10 the SES light doesn't do the quick flash on key on, TunerproRT wont communicate, and it save a 51 PROM error. I have confirmed I am burning correctly by burning two chips, one stock, one with just $900A modified. Is there something I am not doing correct? I am just opening the bin in a hex editor, changing the value, and saving.

[b65cuda]

I did finally manage to burn a bin that worked. Just editing the hex did not work. I had to create the flags in the tunerpro xdf, make the change, then save. This updated the checksum and then it worked.