rusefi.com

During a normal drive in an NB2 with H72d, the tach dropped out and engine stalled. Tuner Studio showed critical error below. TS was connected but only for monitoring of VVT position. This critical error would cycle between PD12, 13 and 14. Only one would show at a time. PD14 being the most common.

reflashed firmware- no change
turned off the three pins and after a power cycling the car was able to run again.

Pic of error(excuse the phone pic, user was broken down)

Matt I see https://github.com/rusefi/rusefi/pull/3450 is this by any chance related?

here I see "driving" while https://github.com/rusefi/rusefi/pull/3450 seems to be about init please clarify?

I am the owner in question....

Finally got the vvt to work and now this, my luck isn't the greatest I guess.

It happened while I was driving on the highway. I had the laptop out monitoring how the vvt reacts and when I got to my exit, the tach died. I pulled over to a parking lot and the car died shortly after.


Here was the tune that was on the car when it occurred: https://rusefi.com/online/view.php?msq=707

I would really like to be 800% sure that we are not mixing two or more different issues together.

Please explicitly confirm one of the following two options:
1) error on the screen is the error as shown after FIRST engine stall, after driving the car for a bit
2) error on the screen appears on cranking attempt prior to engine running within specific power-on cycle

I see how we might have anywhere between one and three unrelated issues. It would be ineffective to discuss more than one issue per forum thread. For this forum thread let's focus on the "startup pin state" and exact scenario of when does it happen.

order of things that happened:

1. tach stops working
2. engine dies
3. error on next power cycle (the error happens immediately at power on)

We already know a firmware reload didn't fix it. I think this is a hardware failure. I'd love to inspect the hardware.

mck1117 wrote: ↑

Wed Nov 03, 2021 9:14 pm

We already know a firmware reload didn't fix it.

Let's clarify "firmware reload"

a) re-flashing with same version or more recent rusEFI master snapshot
b) some custom firmware version maybe related to https://github.com/rusefi/rusefi/pull/3450

AndreyB wrote: ↑

Wed Nov 03, 2021 9:20 pm

mck1117 wrote: ↑

Wed Nov 03, 2021 9:14 pm

We already know a firmware reload didn't fix it.

Let's clarify "firmware reload"

a) re-flashing with same version or more recent rusEFI master snapshot
b) some custom firmware version maybe related to https://github.com/rusefi/rusefi/pull/3450

a

mck1117 wrote: ↑

Wed Nov 03, 2021 9:14 pm

I'd love to inspect the hardware.

While majority of the boards come to US with "Q1, Q2, Q310, Q309, Q308, Q307, Q306, Q305, Q311, Q312" I recall at least some batch of some boards did not have those.

First step could be a picture of that area.

Because the pin error is happening on a few unrelated pins that are physically next to each other on the STM32, I kind of suspect that there's been a failure inside the STM32. This *smells* like some unexpected voltage found its way to one of the STM32 pins, which shorted the clamping diodes for those pins to vcc, hence why we read 1 even while writing 0.

AndreyB wrote: ↑

Wed Nov 03, 2021 9:36 pm

mck1117 wrote: ↑

Wed Nov 03, 2021 9:14 pm

I'd love to inspect the hardware.

While majority of the boards come to US with "Q1, Q2, Q310, Q309, Q308, Q307, Q306, Q305, Q311, Q312" I recall at least some batch of some boards did not have those.

First step could be a picture of that area.

image.png

This batch came with them populated and did not require manual installation. they do come missing L420. These also had the issue with CAN chip in place of LIN chip.

Sending replacement H72d on 11/4/2021 pic below. NightKnight45 will return his to me.