Bringing TBI and Multi Port Fuel Injection to a New Level.     EFI Conversions and Tuning! Seattle to Portland! E-mail Tuning Consultant!
Page 19 of 20 FirstFirst ... 914151617181920 LastLast
Results 271 to 285 of 287

Thread: Anyone worked with the 16196397 yet?

  1. #271
    Fuel Injected!
    Join Date
    Jun 2015
    Age
    29
    Posts
    240
    Things aren't looking too good. The baro value comes up properly, but the other MAP values are skewed pretty badly and the MAP value does not update while the engine is running still. I think the MAP value being skewed (Baro is 98kPa, but MAP is only 84kPa? with the engine off?) is just some of the constants, I'll play with that some more in the next few days.

    Could be a poor FLASH as there have been times in the past I flashed the exact same BIN file to the PCM and it worked better/differently, so I'll give it some more work this week.

    Have a guy interested over on PCMhacking.net as well-he says he's able to help if we can get him the disassembly and patch notes. Quadstar87 is his forum handle-here's a link to the thread where I was looking for help.

    https://www.pcmhacking.net/forums/vi...hp?f=27&t=5166
    Last edited by Xnke; 4 Weeks Ago at 10:25 PM.

  2. #272
    Fuel Injected!
    Join Date
    Jun 2015
    Age
    29
    Posts
    240
    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.

  3. #273
    Super Moderator
    Join Date
    Mar 2011
    Location
    Camden, MI
    Age
    28
    Posts
    3,013
    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


  4. #274
    Fuel Injected!
    Join Date
    Jun 2015
    Age
    29
    Posts
    240
    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; 4 Weeks Ago at 03:32 PM.

  5. #275
    Fuel Injected!
    Join Date
    Jun 2015
    Age
    29
    Posts
    240
    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!

  6. #276
    Fuel Injected!
    Join Date
    Jun 2015
    Age
    29
    Posts
    240
    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?

  7. #277
    Fuel Injected!
    Join Date
    Jun 2015
    Age
    29
    Posts
    240
    Shit's goin' down now...Half price books, dollar and 50 cents!


  8. #278
    Super Moderator
    Join Date
    Mar 2011
    Location
    Camden, MI
    Age
    28
    Posts
    3,013
    Quote Originally Posted by Xnke View Post
    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.

    Quote Originally Posted by Xnke View Post
    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.
    Attached Files Attached Files
    1995 Chevrolet Monte Carlo LS 3100 + 4T60E


  9. #279
    Fuel Injected!
    Join Date
    Jun 2015
    Age
    29
    Posts
    240
    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.

  10. #280
    Super Moderator
    Join Date
    Mar 2011
    Location
    Camden, MI
    Age
    28
    Posts
    3,013
    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.
    1995 Chevrolet Monte Carlo LS 3100 + 4T60E


  11. #281
    Fuel Injected!
    Join Date
    Jun 2015
    Age
    29
    Posts
    240
    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.

  12. #282
    Fuel Injected!
    Join Date
    Jun 2015
    Age
    29
    Posts
    240
    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.
    Last edited by Xnke; 3 Weeks Ago at 10:05 PM.

  13. #283
    Fuel Injected!
    Join Date
    Jun 2015
    Age
    29
    Posts
    240
    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.
    Attached Files Attached Files

  14. #284
    Super Moderator
    Join Date
    Mar 2011
    Location
    Camden, MI
    Age
    28
    Posts
    3,013
    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?
    1995 Chevrolet Monte Carlo LS 3100 + 4T60E


  15. #285
    Fuel Injected!
    Join Date
    Jun 2015
    Age
    29
    Posts
    240
    Can't find anything wrong in the wiring or voltage checks-and remember, if I flash the 1 bar tune and put in a 1 bar sensor, it's absolutely perfect. Smooth idle, revs like a rocket ship straight to 100kpA, blower is still in full bypass mode so will only make 108kpA max.

    Don't get hung up on the MAP going lower after cranking-it's not totally predictable and given enough key-on, start, key-off, key-on events, you'll see it run the gamut from 50kpA all the way to 99kpA. I rarely see 100kpA here for baro so *usually* you'll see it at 98.5 or so. I can pull the vacuum line off the MAP sensor, key the engine on so the PCM starts to report sensor values, and manually pull a vacuum on it and it wasn't updating before-I need to check and see if the raw value updates with the engine not running...stock 1 bar code does and I think that may have something to do with the issue. Prior to running the E-side only ADX, the 2-bar code did NOT update the sensor if the engine was not running, but TPS/coolant temp/air temp all updated fine.

    I've got to send some stuff along to Mark tonight, and he's working on the data corruption issue.

Similar Threads

  1. 16172693 16184164 16184737 16196397 PCM Information P66 V6
    By RobertISaar in forum GM ECM - Bins - TunerPro Definition Files - Wiring Diagrams - Tuner Info!
    Replies: 5
    Last Post: 04-18-2014, 07:49 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •