processor crashing?

[vwnut8392]

does anyone know what exactly happens when the processor crashes or is having trouble keeping up? what going on is when doing a full pull its like i hit the load limiter and hard fuel cut happens. the thing is i have the load limiter set to max and im nowhere near it. i noticed when this happens the lambda control seems to reset in a sense, normally when i lift throttle it goes back to targeting 14.7 but after this happens it seems to take the usual 20+ second till lambda control starts functioning. The other thing thats seemed to develop from this issue is that on WOT pulls the car hesitiates very bad. under normal driving its perfect. im thinking the hesitation is something ignition related but im not sure. i have 07K coils and NGK BKR7EIX plugs gapped to .026, this combo has never let me down before. i';ve been chasing this problem for a few weeks and im pretty puzzled. though timing was too aggressive so i made it almost as conservative as the knock timing map, added fuel to thinking it may have been a lean issue but that didnt fix it. i tried putting the stock coil dwell mapping back in because i realized the dwell table has been modified for modern coils and that did not work either. the strangest part is you cant see anything in the logs during this hesitiation issue. im puzzled and any help is appreciated, thanks guys.

Attached is a log. from a 1-2 pull on the highway. i cant see anything. wrong here.

[vwnut8392]

i forgot to mention the changes i made to the code too that may or may not have added load to the processor. what i have done at the moment is i changed the clutch switching to activate through coding plug pin 1 (ECU pin 38) instead of an analog input (ECU pin 43), wideband is input for logging on AN6 (ECU pin 46), MAP switching is activated on ECU pin 42. other than that i have not changed or added anything else.

[Acki]

May you should remove your changes and test it again?
What happens during normal shifting with your function?

[vwnut8392]

May you should remove your changes and test it again?
What happens during normal shifting with your function?

I will try that. using the other inputs for clutch switch and map switching actually uses less code than the original configuration although the stuff that wasnt used is just 00 to NOP it. in my mind the code steps the processor has to go through didnt change at all just what is referenced.

normal shifting and driving is perfectly normal. i had what i thought was a processor crash a few times than this misfire at WOT under boost showed up after that. i guess i could up the speed of the data logging output to make it crash on purpose to see exactly how it acts so i know if thats what im really up against or if its something else.


This is what i changed for the clutch switch.
Original code.

0000862E code_862E:                              ; CODE XREF: code_8610+Fj
code:0000862E                 mov     A, ADDAT        ; A/D Converter Data Register
code:00008630                 cjne    A, #0xFF, code_8644 ; Compare Operands and JNE

Coding plug input 1

code:0000862E code_862E:                              ; CODE XREF: code_8610+Fj
code:0000862E                 jnb     RAM_21.0, code_8644 ; Jump if Bit is clear
code:00008631                 nop                     ; No operation
code:00008632                 nop                     ; No operation

and nop this to disable coding plug pin 1 default input.

code:00004F7A                 nop                     ; No operation
code:00004F7B                 nop                     ; No operation

actually clutch switch is the only change running at the moment. i didnt patch it with the other map switching code because i have no use for it. i made that just in case i need it in the future.

[prj]

If CPU crashes fast diag is instantly dropped, tacho needle hits zero for a moment and then jumps back up.
Load has no effect on processor crashing or not, only RPM if it's out of time.

Fuel processor never crashes unless you do stupid things in time-sensitive interrupts, because it is a loop that runs best-effort.
Boost processor crashes hard... and my fast logging code is not the best in the boost processor type, ideally it would need to be modified to be more similar to the fuel processor (map lookup routine+static sending), try to keep it at 4hz max if you want to rev over 7400 rpm.

[d_anev]

I had the same issue 3 years ago and again few weeks for first test of Dimirti's modifications when I did some change of connections on AN 4/6 and Coding plug 1. After measurements of command signals on this ports found that unstable ground makes this problem. Every difference between ECU ground and command line to ANs or coding plug or etc. (in my case floating 0.1 to 1.8 volts - may be more, but the multimeter is not so fast) somehow force partial reset of ecu some time to time, especially if this "ground" is changing for unknown reasons.

Problem was solved with relay and hard ground from ecu to ecu port in case of set port and one diode to prevent high voltage from command line if you have relay i.e. coils in current loop, which transfer high voltages to the ECU port when is not grounded. I sagest to remove any active/passive elements in command line in current loop. Hard ground from Battery or ECU ground direct to port, through relay contact / or mechanical switch. Diode is optional.

[Acki]

Should be visible with a direct ADC of the ANx or I'm wrong?
Regarding the AFR malfunction, during WOT shifting with ignition cut the fuel can cool down the O2 sensor too much and the controller gets into failure mode until sensor is heated again.

[vwnut8392]

Very good information gentleman! i have a few hella micro relays that i could put on the connection like you said d_anev and go over grounds. i've been busy with a mess of cars with busted timing belts as of lately so i have not had time to mess with it anymore, when it rains it pours if you know what i mean.

[vwnut8392]

well i did the relay and i thought it was fixed but it isnt. what i discovered is when i take power off the ECU by unplugging it from the car than put it back in it starts doing it all over again. i managed to grab another log of it doing it multiple times. it's doing it around 6800-7000RPM. In the log attached it does it between 92 and 94 seconds, again between 187 and 180 seconds, and a 3rd time between 199 and 201 seconds. it seems as i keep pushing the ECU through it more and more it will eventually stop doing it. i am still running on only the clutch switch input change and i have since disabled it as well and it still does it. this log is with coding plug 1 enabled for clutch switch. even though i dont want to slow down the logging i was wondering if i could test turning down the logging frequency on the boost chip and see if the problem changes or stops. i really dont want to disable the logging completely so i can keep track and diagnose the problem.

[prj]

Trigger error or ECU crash.
Either your log rate is too high or you messed some code up.

[prj]

Btw, that's fuel processor crashing most likely, so you screwed up somewhere

[vwnut8392]

Trigger error or ECU crash.
Either your log rate is too high or you messed some code up.

i never adjusted the log rate from what you set it as at default so it must be something i did. there are no faults for any of the engine position sensors so i'll rule them out too. its so strange that it will eventually iron itself out and act normal though on its own but when the ECU is powered off and reset it goes right back to it. only reason i took my ECU out was because a friend wanted to borrow my ostrich so i pulled it out and put the data from it on an SST27SF512 chip and put my car back together.