Anyone worked with the 16196397 yet?

[Xnke]

Here are the datalogs and details from today's work on things.

First off-shutting off everything in the ALDL scheduling table (at least the one we've found so far and implemented in the XDF) does NOT stop all the chatter. Something else (probably something on the T-side table) is still chattering away.

The E-side ADX does not get all the data once we start turning stuff off on the ALDL scheduling table. The important bits still seem to work, but RPM & TPS for example are not being received. Notice the Baro and MAP values...I think the patch is screwed up again. (had a bit where the patches would only partially apply, which is superweird.)

The T-side ADX (normal ADX) is still receiving all the data we want to see-and it is stable, good data now. I did have 6 data errors, but they were well defined short-duration events and the data stream recovered properly. I actually started and ran the engine with the 1-bar code, and have a decent length datalog. I didn't try with the 2-bar code, as the engine does not run with it so it's me flailing at the accelerator pedal to sustain a running engine, and the above E-side ADX showed issues with the baro updates and map updates.

I will be adding the Wideband O2 internal modification to the PCM in the truck this evening. Hopefully I can figure out the patch format to add the patch to the XDF and get it to apply correctly, as this greatly simplifies the checksumming process.

[Xnke]

Ok, so I have written the wideband O2 code for the E-side and added the input to the PCM. How do I get the code I wrote into the "patch" function on the XDF? Is there any documentation on this anywhere?

[dzidaV8]

In tuner pro, select 'Insert New XDF parameter' -> Patch.
Then in the opened window you can add multiple patch entries. You should add one for every 'continuous' change in binary.

Example:
You want to change the binary in two places:
1. starting at address 0x00FF from: 00 2D 6F 00 2B 11 to 30 85 F2 AA 20 00
2. starting at address 0x01A2 from: FF FF to A1 00

Then you should add two patch entries:
1.
Start address: 00FF
Patch data: 30 85 F2 AA 20 00
Base data: 00 2D 6F 00 2B 11

2.
Start address: 01A2
Patch data: A1 00
Base data: FF FF

And that's all.

You do not have to give "base data" but if you add it, it's possible to remove the patch.

[Xnke]

Excellent. I'll attempt that this evening.

[Xnke]

Still dont' have the hang of this XDF patching thing. I can patch it via hex editing and the wideband stuff *works*, I just need to get the value into the normal datastream instead of the E-side only datastream now. Once that's done, wideband support is in.

Boost code has possibly been fixed but since I can't get the XDF patching to work, I'm afraid to dive in and start hex-editing that many lines in so many places, especially with the wierdness in locations between the XDF patch and the patch notes.

[Xnke]

So here is the big issue right now. I have NO idea if the patch has different locations in it, or if the XDF needs offsets added/subtracted to make sense of the split-bin thing, but the locations that are edited in the XDF are VERY different than the locations being called for in the patch notes.

I have attached the new attempt at getting the data transferred across the from E-side to T-side, but when I go to edit the patch in the XDF, I find a LOT of things very different.

For example, the line that changes the spark table to 0-6400RPM:

Patch Notes:
4D5A:
$65 65 ;changes spark table to 0-6400RPM range

Actual XDF Patch:
4D5A:
New Data: 65 Old data: 61

That looks OK...

Then we get to the next few lines:

Patch Notes:

1BAR emulation

99D6:
JSR L9410			BD 94 10

9BC3:
JSR L9410			BD 94 10

BD10:
JSR L940D			BD 94 0D

CCA1:
JMP L942F			7E 94 2F


940D:
LDAA L1031			B6 10 31

But then looking at the locations in the XDF:

99D6 seems to line up with 19D6
9BC3 seems to line up with 1BC3
BD10 seems to line up with 3D10
CCA1 seems to line up with 4CA1
940D seems to line up with 140D

But I have no way to really know...and patching the wrong sections of code means certain death to another PCM. I'd really rather not go through the process of disassembling the PCM again and burning the FLASH chips and re-assembling the PCM again-it isn't all that reliable and so far none of the socketed PCMs work exactly the same as they used to. They *work*, but Winflash complains about wrong responses at the end of the flash, wheras the stock unsocketed PCMs never complain.

If I can get the boost patch to work, and figure out if there is an offset for E-side code or if the numbers are just a bit off, then I can go ahead and write in the patch for the wideband sensor and get that going in the XDF as well.

[kur4o]

You defenitely need to add offset at the xdf.
The e and t side are actually 64kb bins each at the dissasembly. They are shrinked to 32kb. The processor sees 32kb empty space + 32 kb data. The data starts at $8000.
I guess at the xdf you need to compare addresses and do proper offset.
The rule will be add +$8000 for the first side of the full bin and keep the address at the second part of the bin, since it is already offsetted by $8000.

You can check my dissasembly to get started with the offsets. E and T bins are with added empty space to make full 64kb.
The dissasembly is not full, I needed it only to hack to the PCM to drive PWM fuel gauge. Luckily there were one empty channel I could use. I think I identified all empty pins and corresponding software addresses.

For the tunercat flash I also got only troubles using it. It is almost imposiible to flash if the PCM is on car. In the bench it works almost all the time.
You can try different brand sockets and triple check all solder joints. Don`t push the chip all the way down in the socket. Put some plastic spacer and make sure the chip is flush with the edge of the socket.

So far I only flash on bench or remove chips and burn them with a programer

We should complaint with tunercat to make more stable flash version.

[RobertISaar]

So here is the big issue right now. I have NO idea if the patch has different locations in it, or if the XDF needs offsets added/subtracted to make sense of the split-bin thing, but the locations that are edited in the XDF are VERY different than the locations being called for in the patch notes.

yes, there is offsetting going on due to the E-side being packed into the first 32KB of the combined BIN. T-side doesn't have this issue and all addresses are accurate to their native location.