Would it be easier to split the MAP voltage input for Baro on the T-side and MAP from the E-side? Does the T-side pull the MAP value from the E-side ADC for the Baro, or does it use it's own ADC to do the baro update?
If it uses its own ADC for baro updates, it would be possible to lift the ADC pin, route it out to an unused pin, and just tie in a second 1-bar sensor and mount it in the airbox or something. That would also allow baro updates at any time.
MAP skew is odd.... there's no reason the MAP value should be any different than baro with engine-off, especially with them being calculated using the exact same code. even if the scalars were way off-base, they should still show the same value. is the emulated 1BAR matching the raw 2BAR or raw 3BAR value in the stream? I'm wondering if the 98kPa value is a default? but then you've mentioned being able to simulate it with a pot, so that seems less likely.
the fact that it still doesn't update after cranking is bizarre. I have to wonder if I slipped it into an SPI transfer slot that is only transmitted before cranking? it would still be being updated on the E-side if so, i'll have to pull up my E-side only ADX for that.
T-side has its own A/D channel for MAP and it uses it regularly, it also creates its own baro value. E-side having its own A/D channel for the MAP sensor as well, for whatever reason does not generate a baro value, it just gets the baro value from T-side passed to it over the SPI link. so, in the end the T-side is entirely responsible for making and maintaining the baro value.
I would think if we were to dig into the PCM(which is something I've been desperately trying to avoid since it raises the entry barrier for a good portion of people), it feels like the same issue would be present now that my code just isn't accounting for somewhere. using it exclusively as a baro device would require some recoding on both sides as well. would allow to watch for stuff like filter restriction too...
i'll send you a dropbox link via PM in a bit with what I've got so far, I don't want dysfunctional raw code out in the public with my name on it.
1995 Chevrolet Monte Carlo LS 3100 + 4T60E
Sure thing. I'm also starting a thread on PCMhacking to try and teach myself IDAPro, so that I can try to brick my spare PCM's till they catch on fire. I've always been interested but I've also always done 68HC11 in C, through a "sanitized" IDE. 99% of my embedded development stuff (what little I've really done) has been Atmel based and so this is a whole new world.
As far as splitting the T side and E side MAP stuff, it'd be a lot of coding work-basically would be splitting the codebase off like $58 and $59 are split, at that point. I'd consider that a last-ditch effort if it's gonna require that much work.
Hopefully QuadStar87 is able to help out with it-although I am not sure that the P66 or other dual processor 68HC11 PCM's ever made it to the other side of the pacific. PCMhacking seems to be based in AU, but who knows. At this point, the only thing stopping me from driving it is the 2-bar map support, and even at that I've subbed in a 1-bar sensor and driven the truck (with the blower bypass locked in bypass mode!) to make sure all the mechanicals are in good order.
The T5 transmission was not pleased with the boost-bypassed engine doing a burnout on clean, dry pavement. I feel a transmission swap coming into play soon...I'll have to make jigs to do bellhousing conversions from Atlas-family to Small-Corporate family bellhousings.
Last edited by Xnke; 03-26-2017 at 01:32 AM.
More testing of the new patch-the MAP value skews were just me mistyping stuff in the 2-bar configuration stuff. I re-did all that and tried again-MAP and Baro are within 1kpA, although as before-MAP never updates.
Unlike the version 1 patch, though, MAP and 2-bar MAP actually agree with each other very closely, so that part of the patch works. If we can get it updating the MAP value, it ought to be the trick!
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?
Shit's goin' down now...Half price books, dollar and 50 cents!
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.Originally Posted by Xnke
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.
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.Shit's goin' down now...Half price books, dollar and 50 cents!
1995 Chevrolet Monte Carlo LS 3100 + 4T60E
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.
Posting Permissions
Reply With Quote
Bookmarks