Looking for some help with a modified program

For discussion and distribution of custom code and hacks
Posts: 26
Joined: Thu Sep 24, 2015 1:42 pm

Re: Looking for some help with a modified program

Postby Xnke » Mon May 01, 2017 3:12 pm

That is currently how the tables are done-for both spark and fuel. The issue that is currently happening is that the MAP is not being updated correctly. I have a feeling that I'll have to take all the boost parts off and go back N/A, at least until some kind of breakthrough gets made. I planned to drive this truck to the ocean in 5 months...

My last attempt at fixing the issues bricked the PCM, so I had to pull the chips and reflash them off-board to bring it back.

User avatar
Posts: 495
Joined: Thu Sep 17, 2009 2:00 pm
Location: Perth, WA

Re: Looking for some help with a modified program

Postby charlay86 » Tue May 09, 2017 11:11 am

are both of the MAP variables and any associated flags updated sequentially in the same section of code?
I found that you have to make sure the calc always updates all of the variables (i.e. don't branch over one of the calcs if below the threshold of needing to use that variable) otherwise you can end up the extended variable getting stuck at some non zero value.
Keeping them together also lowers the chance of an interrupt occurring between updating the initial and extended map variables.
If you post or PM me the patch notes etc. I can take a look when I have time.

Posts: 26
Joined: Thu Sep 24, 2015 1:42 pm

Re: Looking for some help with a modified program

Postby Xnke » Tue May 09, 2017 1:46 pm

Just saw your post here, Charlay, and Antus has forwarded the code and patch, and patch notes to you. If there is anything else you need, let me know and I will try to get Robert roped in too.

I believe the current patch and patch notes you have are relevant to this statement by Robert, and might be helpful?

"found some more interesting quirks along the way, like how the E-side doesn't bother generating a baro value, it just gets the value passed to it from the T-side. so now, when baro updates are allowed with the boost patch, they start with a MAP read on the E-side, get emulated into a 1BAR value, sent to the T-side, T-side uses the emulated 1BAR signal instead of the reading it would normally make of the MAP sensor and sends it back to the E-side. "

Posts: 26
Joined: Thu Sep 24, 2015 1:42 pm

Re: Looking for some help with a modified program

Postby Xnke » Fri May 12, 2017 10:43 am

Ok, so I've been asked for more detail and information on these units. Here's every detail I have:

PCM 16196397, manual transmission or no transmission control, transmission control parts not populated on board.
PCM 16194743, automatic 4L60E, or 4L80E with wiring modifications.

Above PCM's found in 1994-1995 3.1L FWD cars, or 3.4L RWD Camaro

Dual MC68HC11F1 processors with dual 28F256 FLASH memory

All the wiring diagrams (I have an F-body harness) are on this page:

http://www.gearhead-efi.com/Fuel-Inject ... ion-P66-V6

The above link also contains the standard XDF/ADX files for these units.

I have added a 0-5V input for the wideband O2 sensor to my computer, however the code doesn't even read that pin on the controller yet...it will come after the 2-bar patch. Basically I'll just insert an A/D read in one of the 10hz or 80hz loops and spit that value out in the datastream, there is lots of spots available in the datatstream already. Future project, gotta make the truck run before I worry about adding inputs...until it runs I can just use the Evaporator Temperature Sensor input.

User avatar
Posts: 495
Joined: Thu Sep 17, 2009 2:00 pm
Location: Perth, WA

Re: Looking for some help with a modified program

Postby charlay86 » Fri May 12, 2017 7:26 pm

so the serial scheduler table is:
Code: Select all
ROM:82D5 F9MST:          .word off_82F5          ; DATA XREF: ALDL_MSG_SCHEDULER:loc_EE88o
ROM:82D5                                         ; ALDL message schedule table
ROM:82D5                                         ; 0
ROM:82D7                 .word 0xFFFF            ; 1
ROM:82D9                 .word off_8304          ; 2
ROM:82DB                 .word 0xFFFF            ; 3
ROM:82DD                 .word off_82F5          ; 4
ROM:82DF                 .word 0xFFFF            ; 5
ROM:82E1                 .word word_95F2         ; 6
ROM:82E3                 .word 0xFFFF            ; 7
ROM:82E5                 .word off_82F5          ; 8
ROM:82E7                 .word 0xFFFF            ; 9
ROM:82E9                 .word 0xFFFF            ; A
ROM:82EB                 .word 0xFFFF            ; B
ROM:82ED                 .word off_82F5          ; C
ROM:82EF                 .word 0xFFFF            ; D
ROM:82F1                 .word 0xFFFF            ; E
ROM:82F3                 .word 0xFFFF            ; F


if you set the whole table to 0xFF that should make the ECM be quiet

Posts: 3143
Joined: Mon Aug 02, 2010 6:35 pm

Re: Looking for some help with a modified program

Postby Dylan » Fri May 12, 2017 7:45 pm

What's the crank signal trigger pattern on this engine? May be able to change to another ECU? Like a 1227165

Posts: 26
Joined: Thu Sep 24, 2015 1:42 pm

Re: Looking for some help with a modified program

Postby Xnke » Mon May 15, 2017 10:49 am

Because being flash based, there are no chips to burn in normal tuning operations, no extra equipment, and I only need the laptop and the ALDL cable.

Of course, during development I fully plan on having to reflash chips and use a socketed PCM, but there are *so* many 94/95 cars out there that use this PCM that got scrapped only because of not being able to use scan tools, or because the owner wanted a boosted engine but this PCM just "wasn't tunable" at the time.

Now it's becoming much more tunable, and that's always a good thing.

Posts: 26
Joined: Thu Sep 24, 2015 1:42 pm

Re: Looking for some help with a modified program

Postby Xnke » Tue May 16, 2017 7:09 am

OK, I have been working on the ALDL chatter issue-I shut off the E-side ALDL scheduling, and almost all the glitchy data was gone-the data was very good compared to what it was before. Of course the engine runs like shit so hard to say...more testing yet today.

The downside is that turning off the whole ALDL scheduling table also shut down a few important data points in the recieved data. I will have to be more selective in turning of the scheduled ALDL messages. Also, I ONLY turned off the E-side messages, so I did have a few glitches that seem to have been transmitted by the T-side ALDL table.

I should have more detailed data this evening.

Posts: 26
Joined: Thu Sep 24, 2015 1:42 pm

Re: Looking for some help with a modified program

Postby Xnke » Tue May 16, 2017 8:14 am

Here are the datalogs and details.

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.)

aldltest.xdl
E-side ADX with 2 bar code, and scheduling table cleared out.
(19.43 KiB) Downloaded 100 times


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.

FIXED1baraldl!.xdl
1-bar code with ALDL scheduling table cleared out
(63.37 KiB) Downloaded 94 times


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.

Posts: 26
Joined: Thu Sep 24, 2015 1:42 pm

Re: Looking for some help with a modified program

Postby Xnke » Wed May 31, 2017 8:50 am

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. The reason for doing it via the XDF is checksum calculations-Tunerpro handles that when using the patch function.

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:
1D5A:
New Data: 65 Old data: 61

That looks OK...

Then we get to the next few lines:

Patch Notes:
Code: Select all
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.
Attachments
new P66 V6 boost coderevision2.txt
new Boost patch draft
(5.77 KiB) Downloaded 87 times

PreviousNext

Return to Custom Code

Who is online

Users browsing this forum: No registered users and 1 guest