Fix esc init

[jirif]

This is workarround for issue #4257. It cannot be fixed by other way because during power up spurious pulse starting esc initialization (before any code is run, tested at OMNIBUS). Second initialization happen during motorDevInit call so the best way is initialize motors soon as posible what was done before db8698d whish showed/introduced this problem.

[mikeller]

Good finding and good fix!

[mikeller]

Looking at the changes done in #4218, I'd move the LED blinking to after the servo init, just to revert the timing back to how it was before #4218 (or as close as possible).

[jirif]

@mikeller Yes,this spurious pulse will affect servos too, i moved it after ..

[adrianmiriuta]

@jirif not working for FF_FORTINIF4

[mikeller]

@adrianmiriuta: 'not working' as in still 2 sets of startup tones? If so, can you please confirm that this isn't already the case in RC5 or earlier?

[adrianmiriuta]

@mikeller
i merged the PR into actual 3.3.0
and I still got 2x ESC init sound.

[mikeller]

@adrianmiriuta: That's awkward. I just tested with BLHeli_S 16.63, on a BEEROTORF4, and the double init was fixed with this patch. (I also tested with KISS and BLHeli32, but none of them showed the problem with 3.2.0, so there is nothing to fix.)

But then since the problem seems to be a timing issue, and the fix is shifting the motor initialisation to an earlier point in the initialisation, different boards with different peripherals that need to be initialised, and different timings required by different ESCs might mean that this does not fix it for all possible combinations. The initialisation process is a complicated dance already, with different parts being dependent on each other, and some of them having timing requirements. This is just a 'cosmetic' issue, so users might have to live with it, in return for getting all the other components on their board initialised properly.

[adrianmiriuta]

@mikeller
I have a FF_FORTINIF4 with blheli_s 16.67

I have done 2 Traces to get a clue

1. FF_FORTINIF4 3.3.0
2. NAZE3.1.7

they are quite different in the time the motor output is high after poweron.
but I do not know how this gets interpreted by blheli.

[mikeller]

I guess the difference there is that the FF_FORTINIF4 has got a lot more on board peripherals that need to be initialised first, pushing the motor init farther back. There should be a difference in the output high time between without and with this patch, but possibly not enough to stop your ESCs from booting up before they get a valid signal.

[martinbudden]

@jirif , well found.

In terms of initialisation, the motor initialisation depends on little else and it seems it should be done as early as possible. So I think the whole block:

    mixerInit(mixerConfig()->mixerMode);

    uint16_t idlePulse = motorConfig()->mincommand;
    if (feature(FEATURE_3D)) {
        idlePulse = flight3DConfig()->neutral3d;
    }
    if (motorConfig()->dev.motorPwmProtocol == PWM_TYPE_BRUSHED) {
        featureClear(FEATURE_3D);
        idlePulse = 0; // brushed motors
    }
    mixerConfigureOutput();
    motorDevInit(&motorConfig()->dev, idlePulse, getMotorCount());
    systemState |= SYSTEM_STATE_MOTORS_READY;

should be moved to just after the call to updateHardwareRevision. And for neatness I'd move the call to mixerConfigureOutput to just after mixerInit, so the block becomes:

    mixerInit(mixerConfig()->mixerMode);
    mixerConfigureOutput();

    uint16_t idlePulse = motorConfig()->mincommand;
    if (feature(FEATURE_3D)) {
        idlePulse = flight3DConfig()->neutral3d;
    }
    if (motorConfig()->dev.motorPwmProtocol == PWM_TYPE_BRUSHED) {
        featureClear(FEATURE_3D);
        idlePulse = 0; // brushed motors
    }
    motorDevInit(&motorConfig()->dev, idlePulse, getMotorCount());
    systemState |= SYSTEM_STATE_MOTORS_READY;

[adrianmiriuta]

@martinbudden
your ideea works

[martinbudden]

@jirif , just checked your latest version, and it seems you have accidentally deleted that block entirely.

[jirif]

@martinbudden here is one dependency left, ppmRxInit() need motors have initialized in ppmAvoidPWMTimerClash() so we should move it to its original location or whole

    if (0) {}
#if defined(USE_PPM)
    else if (feature(FEATURE_RX_PPM)) {
        ppmRxInit(ppmConfig());
    }
#endif
#if defined(USE_PWM)
    else if (feature(FEATURE_RX_PARALLEL_PWM)) {
        pwmRxInit(pwmConfig());
    }
#endif

after

latest revision moved led/beep block after servo init as @mikeller suggested

[martinbudden]

@jirif , well spotted. Yes, move the block back to its original location. I'd also add a comment stating that the motor initialisation needs to occur at that point, so that someone doesn't move it again.

[0crap]

Tested build 249 and this fix works on my Naze32.
Thx all involved!

[TimothyGold]

I just upgraded from a 3.2 RC to the full latest release of 3.2.1 on my Matek 405 AIO and am finding the double ESC init is happening. I didn't have this on the 3.2 RC.

[mikeller]

@TimothyGold: The problem causing the double ESC init is the delay between power being connected and the flight controller initialising the ESC outputs. A lot of peripherials (like OSD) are initialised before the ESC outputs, and in some cases this causes enough delay for the ESC to initialise on power up, and then again when they get a valid signal. This isn't a problem in itself, and there isn't really a fix for it (except to disable some of the peripherals), since a lot of the initialisation has to be done within a certain time frame after powering up.

[TimothyGold]

@mikeller Sounds good. Not a problem. Just thought I would mention this in case it indicated anything that was missed through the initial issues reported. Thanks for reply.