Anyone worked with the 16196397 yet?

[RobertISaar]

Any update on the E-side-only ADX? I have been *very* slowly stepping through the disassembly and while I've not made any profound insights, I have found two typographical bugs that may or may not actually matter, according to my friend who knows about these kinds of things. I haven't even started to try and make sense of the patch yet.

Basically, I sit down with a pencil and paper and start at the top of the loop, writing out the commands to try and get them to tell me what it's doing-combined with the comments it seems to help me make better sense of it.

How goes the KLDE repair and modification?

E-side ALDL info: look at the E-side disassembly around 91D5 and you'll see the E-side M1m0 response, changing the RAM/ROM/register addresses will allow for nearly any value to be watched. it's a 63 byte payload and modifying what is being spit into the stream doesn't effect any kind of module or the comms ability with the T-side, so pretty much all of it could be scrapped if desired. I keep some fairly constant stuff in there just to errorcheck the stream, but otherwise, most of it is free game. the ADX I'm attaching still has T-side stuff in it, but it's more or less hidden from view and isn't setup to communicate with T-side by default. with this ADX, it looks like I was monitoring EGR% and some knock stuff when I was last using it. I don't think some of those values are there in factory calibrations, so they would show up incorrectly in something that hasn't been patched to transmit them.

to get around having to make patch every time a value I want to monitor comes around, I just made an address inside tunerpro. "Mode 1, Message 0 ALDL Response", that should only exist in the E-side table list, I never made a table for the T-side since that more or less stayed constant. the offset value in the ADX and table location value in the XDF differ by 1, though I should probably change that at some point in the future. just something to keep in mind. starting at 9235(position 49 in the XDF, position 48 in the ADX), there's a lot of 2A5, which as far as I can tell, is a completely unused value. it's easy to add items there for monitoring since it won't have to replace anything. because of that, I've setup the ADX to read the raw 2/3BAR MAP value and the above 100kPa values from there. just need to open the table and change position 49 to 0369 and position 50 to 036A. the E-side baro and emulated 1BAR MAP values are already in the stream, so all 4 values can be compared simultaneously to see if something funky is going on.

so, ADX work is done, just need to change two values in the BIN to match and the E-side ADX will function well enough for the values we need to keep track of.

typographical bugs? maybe issues, maybe not, I do things in a bit of a non-traditional manner with a lot of success, especially when it comes to labeling, but it has burned me before.

the domestic Mazda rides again, turns out one plug wires failing will cause a rapid demise of something in the distributor, after replacing the distributor, still had an issue with cylinder 4, so i quit messing with it until new plug wires came in. replaced those and it once again sings happily up to its rev limiter in the 7400 range.

Shit's goin' down now...Half price books, dollar and 50 cents!

when i started cutting my teeth on 6811s, it was the GM P4 variant, which that book wouldn't have been entirely appropriate for, but with a P6/P66 application, it would have been beyond monumental. it probably explains why i have somewhat quirky methods of getting things to work and testing methods in general. it's also why i can't really hook into high level languages either, about the only original programming I've ever been successful with has been at assembly level. Trying to make anything beyond simple Android tutorial apps felt like a drill to the temple. Arduino has been an okay-ish experience though.

[Xnke]

I bought this book for it's chapters on assembly, but it is MOSTLY about using C and assembling it down-they give you the assembly primer so you can fix bugs that crop up in the assembled code, and so you can "optimize" certain routines to a higher degree than the C assembler can do for you. I've always used C to fumble through things, but this book has given some good insight as to why I should have learned assembly prior. I'll see if I can grab another copy if you'd like-they were a buck fifty and there was a whole pallet of them when I bought that one. They do not come with the CD-ROM that had the example programs and windows C assembler-but they do go over setting up the GNU toolchain. (Also, Arduino is just C, with some specially named commands and macros!)

So to make sure I understand what needs to change in the BIN:

I would open tunerpro and edit the Table "Mode 1, Message 0 ALDL Response"
Scroll down to row 49 and replace the 02A5 with 0369
Scroll down to row 50 and replace the 02A5 with 036A

Save BIN As (new filename) and then upload it to the PCM.

Once that has been sent to the PCM, I would fire up the new E-Side ADX and it should show some different items in the list view-namely I should see:

E-side Baro ($Value)
E-side Emulated MAP ($Value)
E-Side Raw 2/3BAR MAP ($Value)
E-side MAP-Above-100kPa value (flag denoting code branch? Or $Value?)

I assume that they'll show up as unlabled values in the list view?

I will try this out tomorrow and get some info back to you. I've not heard anything back on PCMHacking, although I only posted the commented assembly and not the .idb's or the patch. Looks like someone has had a look at them, but I haven't heard any update yet. Not even a "wow, what the hell is this?" comment!

Also-GM used C to write this or the 68HC11-to-C disassembler my friend used to get a better understanding of it is REALLY good! There are very few places that the disassembler got lost and needed help, and the code is surprisingly readable. I have been looking over that, but he's told me it's very unlikely we'll be able to modify the code and get it to assemble into a usable BIN file working from C. Said he could re-write the whole thing from essentially scratch, but he's of the opinion that trying to patch/modify/do anything in C will cause enough change in the assembled code to make it not fit the 32kb BIN size properly.

[RobertISaar]

BIN changes look correct.

item list in the new ADX omits the viewing of anything that would be coming from the T-side, though the commands to have both E and T side sent are present and could be configured to do so.

you'll have like 15 items coming across from the E-side in the list view, I didn't want to put just bare minimums in there if for nothing other than packet error checking. some are useful to look at, others not as much. MAP above 100 is a value, it's an offset and scaled MAP value that is only really used for the boost VE and boost main spark tables. should show 0 at all times until the MAP sensor reaches the 100kPa calibration value, then it should start showing non-0 results. scaled at X*0.78125, though I don't think I put the scaling into the ADX yet. with an initial value of 100, that gives it a 100-300 range.

GM using C is not surprising.... considering the number of different masks that came and went in the 86-95 timeframe(where P4 and eventually P6/P66 became dominant), punching it all out in assembly would be hell. even just small patches(50 bytes or so) in a single mask are trying at times. I've never actually considered the existence of 6811->C assembler, I assumed going from low-level to high would be problematic at best. playing with the code in C does seem like it would balloon out of our size constraint pretty easily.

[Xnke]

It's much faster to write in C than assembly-but C is low-enough level to be usable. It was actually designed to do this kind of work, things that needed to be assembled for compactness and speed as well as being able to be used for other things. I do not know the name of the decompiler, but I'll get it.

Testing to commence in a few minutes, I should have another video of the current patch's behavior.

[Xnke]

Well Robert, I figure it's time to abandon ship here until Tunerpro gets a bugfix release to correct the erratic data problem, I can't give you any kind of usable data.

Spent two hours fighting the issue I was having with data being fine until the engine is started-whatever I did a few months back to fix it hasn't actually worked-it was just a fluke that the problem went away when I was talking to Mark about it. There's still five or six posts on the Tunerpro forum with reports of the same thing, so until someone can actually take a tunerpro install to Mark with the problem, I doubt I'll get anywhere with this.

Supposedly there's nothing he can do about it without being able to reproduce it locally or have some serial port monitoring, so I guess the next thing I need to do is get some serial port monitoring in place and try again.

[Xnke]

Ok, so I was collecting data for Mark to work on Tunerpro with, and actually got a few shots of "usable" data for this.

This is E-Side ADX, and the logs are done with the Tunerpro Debug output open for Mark, but hopefully there's some data for you to use too, Robert.

[RobertISaar]

looked at all 3 logs, yes, there is usable data here!

particularly log7, ECMMAP and ECMRaw 2BAR are both updating when the engine is spinning.... and both agree with each other in most samples as well(the ones that don't, I chalk up to additional a/d reads that occur between sending the two items(with one being item 16 and the other being item 48 in the stream, there's 32 other bytes of data that get updated first. at 8192 baud, that's .03125 seconds, almost enough time for 3 80Hz loops to complete, let alone the MAP updates that can be done based on the 24X crank sensor signal).

but then.....

after your first cranking, your MAP sensor settles from 100.76kPa as a barometric-looking value down to 95.22. after the second cranking, it maxes out at 60.... all while the actual baro value was sitting at 104.45(expected, since we have to pretty much disable baro updates with a boost application). log4 has something similar, though MAP and baro more or less agree before first crank at 100, then MAP tops out at 97, while baro still sits at 100.

I'm not sure why the MAP sensor's value would "stick" at progressively lower values after cranking.... if you're able to replicate it, can you take a voltmeter to the MAP sensor's 5V, ground and signal lines while the ECM is reporting those odd low values?