rusefi.com

I would not change firmware yet, not reason. Looks like I should try to reproduce same lock locally.

ZHoob2004 wrote:Can I get an explanation of how the ECU is determining that spark events have been missed?

I suspect this internal state validation could be broken in case of single coil spark mode. Trying to reproduce locally but hitting all kinds of unrelated issues

Fresh tunerstudio project on a clean firmware flash (same version, but I had to erase and reflash to get the board bootable again). Same result as soon as I enabled "only use rising edge"

russian wrote:I suspect this internal state validation could be broken in case of single coil spark mode.

Yes, it was a bug - just fixed, would take about an hour for the new binaries to be published.

ZHoob2004 wrote:Same result as soon as I enabled "only use rising edge"

Will look into this tomorrow - bed time for me. Sorry for all the drama and thank you for you patience.

No problem. I wasn't going to be trying anything else on it until tomorrow anyway. I can't expect it to be perfect when this is the 32nd engine to run.

I was able to reproduce this issue, see https://github.com/rusefi/rusefi/issues/363

I remember about #363 but have not made much progress so far, sorry. Spending another five minute chunk on it right now.

I'm eagerly awaiting your progress. If I understand correctly, the problem with how it's set now is it's looking for both rising and falling edges to trigger from, which is problematic with VRs because that falling edge will move around as the p2p voltage rises and falls. Close enough?

Yes, currently it's looking for perfect 50% duty cycle. Which actually looking at that log is not that far off.

ZHoob2004 wrote:I'm eagerly awaiting your progress.

I think I am pretty close to a fix - removing a bogus line line seems to resolve the unit test which is reproducing your problem.

But the rest of the test suite fails with this change, I want to play it safe so I need time to confirm that the test suite is broken and needs to be fixed as well.

Please download version 20170304 - https://github.com/rusefi/rusefi/issues/363 is fixed now! See the change log on the ticket, the fix was four lines but finding these lines took some time.

set engine_type 51
could be used to play to test

Awesome. I probably won't get to mess with it until next weekend, but I'll keep you posted.

I have a bad habit of working on this thing for a while, then getting distracted by life and other projects. I got the unit out again today, rebuilt a config using the latest firmware and latest version of tunerstudio and I can't get the motor to start. I don't have a timing light at the moment, but I think the trigger offset has something to do with it. The trigger offset was set to 102 degrees, but I've since changed the setting to use rising edge only and I imagine that shifted the offset required.

The other issue I'm having is it seems like my coil is firing a lot more than it should. I haven't been able to capture it in the sniffer, but after the engine dies (it cranks and tries to start, but won't idle) I see the trigger LEDs blink rapidly, hear my coil sparking rapidly and the tach climbs up to around 4k before dropping to 0 again.

Physically, I think the configuration I ended up with on the triggers was the normal VR config with a 2.2k resistor bridging the two terminals at the ecu.

Any new ideas or suggestions about noise reduction on the VR inputs?

I tested the ecu with a timing light and the problem is either with the trigger circuit or the firmware. I tried to set the offset but the coil is firing a lot more than it should so it was impossible. Spark works exactly as it's supposed to when using the io test, but the sniffer looks fine so I'm not sure what's going on.

Last time the engine ran on rusefi was with chibios 2 before the rising edge bug was fixed.

how can I reproduce this locally? can we reproduce the issue on a bench?

logs & tune please?

Sorry for not coming back immediately with a reply. I ended up wiping and reinstalling my laptop for various reasons, then have been procrastinating this issue ever since. I still have the logs, but I wasn't deliberately trying to get logs of the issue so they aren't very targeted. I'll try and get a chance to get some proper logs of it.

What exactly should my troubleshooting process be on this? I have a timing light, multimeter and analog scope. I'm not super confident in the trigger circuit, but I don't have a good idea of how to isolate and test it by itself aside from the basic battery test.

The ignition setup I ended up with is using the factory ignition module (which charges the coil when pulled low, fires spark when let float) connected to a low side driver and then ignition configured as default in tunerstudio, which in my mind says the stm should send a high signal out to the low-side driver, bringing it low causing the coil to charge, and I might have just found my problem? Maybe I've misunderstood how the icm works and that's why it doesn't behave as I think it should. It's been too long since I had really figured out the ICM operation so many months ago, so I'm at work using this for reference ATM https://www.diyautotune.com/support/tech/install/honda/megasquirt-your-honda/

The low side drive with pull up resistor works, but you would likely get a better more accurate signal using the hi / lo driver on the Frankenso. This driver prevents rounding of the control signal.

Cool to hear you are getting back into it.

So I should hook it back up to the high/low driver? Then I assume I just connect the jumper to ground to set it low? Where does the driver hold the signal when it's not being activated?

I understand the stock ecu to have a pullup to 5v on the ICM control pin which it then pulls low to charge, then lets float for ignition (This is basic inductors, right? I'm a little shaky on this right now)

To be sure I understand what rusefi is doing with ignition, rusefi activates the ICM x milliseconds before an ignition event where x is the dwell, and then lets it float when the spark is supposed to happen, correct?

I'll see what I can do about getting my scope or something hooked up to make sure everything is moving in sync as it's supposed to. I might pick up a bus pirate or equivalent to work as a crude logic analyzer and that might help me shed more light on everything. If I can see the input and output signals as they come and go from the board I might understand where I'm going wrong.

ZHoob2004 wrote:To be sure I understand what rusefi is doing with ignition, rusefi activates the ICM x milliseconds before an ignition event where x is the dwell, and then lets it float when the spark is supposed to happen, correct?

rusEfi firmware turns pin on "dwell" milliseconds before and turns off at the moment of the ignition. What the hardware pin does depends on the board and pin mode.

Probably what you said, just wanted to be more precise.

That's more or less what I meant to say, and I appreciate the clarity.

So how I have it configured right now is the pin goes high, activating the low side driver and pulling the ignition pin low. After the dwell time has elapsed, the STM pin goes low, and the low side driver shuts off, and the ignition pin does what? Does it stay low, or is there a pullup in the circuit somewhere? I think this may be a part of my problem if the ICM doesn't have anything pulling it back high it could be picking up all sorts of noise and triggering repeatedly, which may match my symptoms.

Alternatively, I can switch back to the high/low outputs, but I'm not 100% on how to configure those to pull the pin low. Do I simply connect the "VP" pin on the TC4426 to GND? What will the output do when it's not being triggered?

ZHoob2004 wrote:Alternatively, I can switch back to the high/low outputs, but I'm not 100% on how to configure those to pull the pin low. Do I simply connect the "VP" pin on the TC4426 to GND? What will the output do when it's not being triggered?

I would not use the TC4426 in GND mode - one the one hand it's kind of an option, on the other hand the dedicated low-sides are doing the job in a much more predictable way.

Did some probing today, and got some odd results.

First, seems the Honda ICM does internally pull up to 12v, so that's not a problem. Ignition output is working exactly as intended.

On the other hand, the LEDs on the TC4426 are all going pretty crazy. I only have jumpers connected to two of them, but in both cases the LEDs are either solid or blinking randomly whenever the F1001 jumper is in place (I think F is supposed to mean fuse ). I'm checking now for any frayed wires, because it does this even when I power from an external 5v supply, but stops as soon as I remove the jumper.

Yes F1001 is a place where a fuse could have been populated

As for funny LEDs, check the "all pins" tab and see if you have something funny like MIL assigned to any of these HL chips?

I checked through all the firmware settings, but it's not that (MIL is on one of the low-sides). I even removed the discovery board completely and the problem persists, so it's definitely something hardware.

I did some testing with the HL drivers and when I send 5v to one of the inputs, the other output eventually comes on too (or at least the LEDs are lighting up). I'm not even using the HL drivers, but with the problem existing on all 4 of them, I'm suspicious something pretty significant is wrong with my hardware. I did notice I have 2.2k resistors in place all around the HL drivers instead of the 2.7k that I believe are called for, but I wouldn't think that could cause this sort of behavior. I'm suspecting a cold joint or a solder bridge somewhere, but I'm not really sure where to look. I guess I'll start by removing the drivers one by one and see if the problem goes away.

I recall R0.4 does not have a pull down resistor on the MCU pin. If the software is not configured correctly, then the MCU pin is floating, and it does not take much noise to trigger a high or low. Is there a way to verify if the STM is driving high or low, and not floating? If you remove the STM, this situation would still exist, as the pin would be floating at that point. However with the discovery installed, it should be able to drive the MCU pin high or low and not float.

I should measure exactly 0v to ground on that pin if the stm is pulling it low, so I'll check that. I also plan to connect one input on the tc to gnd and the other to 5v and see what kind of output I get. I should get one output off and the other on, but I have a feeling they're both going to come on.

Keep in mind that the chip TC chip has a thermal protection, so even if you turn it on and if you are shorted or over current, it can still turn off. Also keep in mind I expect it will get to hot if you draw more than about 1/8 amp.

I think I've got it figured out.

I had a spare distributor around so I refurbished it (needed a new center bearing) and I hooked it up to my scope and rusefi and spun it with a drill. After some adjusting, I had the ecu reliably reporting ~1800rpm, and with the drill claiming 850rpm I think it's working.

Unfortunately, this result does not a running engine make because I lent out my timing light and I haven't got it back yet...

Edit: forgot to account for cam speed

That's good news about the crank decoding, but bad news about the timing gun. Sounds like your making good progress.

Wiring of 1993 must be similar to your 1991 Crx,right?