With a custom motor mix, the Motor test interface is broken and leads to motors spinning uncontrollably

Describe the bug

When configuring a custom layout of motors for an octocopter, the motor test interface is nonfunctional, as soon as motor test mode is enabled, some motors will often (but not always, as sometimes they remain unmoving) spin at full speed, even when all sliders are still set to zero. Furthermore, the motors don't respond to any of the sliders, and only the master slider isn't greyed out, reporting "R: NaN" as its speed. When turning off the test mode there is no effect, the motors continue spinning until battery power is removed or the controller reboots.

To Reproduce

configure an octocopter with the following mixer:

mixer CUSTOM
mmix reset
mmix 0  1.000  1.000  0.000 -1.000
mmix 1  1.000  0.000 -1.000 -1.000
mmix 2  1.000 -1.000  0.000 -1.000
mmix 3  1.000  0.000  1.000 -1.000
mmix 4  1.000  0.550 -0.550  1.000
mmix 5  1.000 -0.550 -0.550  1.000
mmix 6  1.000 -0.550  0.550  1.000
mmix 7  1.000  0.550  0.550  1.000
save

and attempt to test the motors from the motors tab of the betaflight configurator. Observe the erratic behavior described above.

Expected behavior

The interface continues to allow safe and reliable testing of the motors, just as it does in the OCTO FLAT + configuration.

Configurator version

10.10.0

Flight controller configuration

# diff

# version
# Betaflight / STM32F405 (S405) 4.5.1 Jul 30 2024 / 07:48:03 (77d01ba3b) MSP API: 1.46
# config rev: bc5da0e

# start the command batch
batch start

board_name SPEEDYBEEF405V4
manufacturer_id SPBE

# name: OctoBeast

# feature
feature -AIRMODE
feature GPS
feature TELEMETRY
feature LED_STRIP
feature OSD

# serial
serial 5 2 115200 57600 0 115200

# mixer
mixer CUSTOM
mmix 0  1.000  1.000  0.000 -1.000
mmix 1  1.000  0.000 -1.000 -1.000
mmix 2  1.000 -1.000  0.000 -1.000
mmix 3  1.000  0.000  1.000 -1.000
mmix 4  1.000  0.550 -0.550  1.000
mmix 5  1.000 -0.550 -0.550  1.000
mmix 6  1.000 -0.550  0.550  1.000
mmix 7  1.000  0.550  0.550  1.000

# beacon
beacon RX_SET

# aux
aux 0 0 0 1525 2100 0 0
aux 1 1 2 900 1275 0 0
aux 2 2 2 1275 1700 0 0
aux 3 13 1 1650 2100 0 0
aux 4 47 2 1700 2100 0 0

# rxfail
rxfail 5 s 1600

# master
set gyro_lpf1_static_hz = 187
set gyro_lpf2_static_hz = 375
set dyn_notch_count = 2
set dyn_notch_q = 500
set dyn_notch_min_hz = 60
set gyro_lpf1_dyn_min_hz = 187
set gyro_lpf1_dyn_max_hz = 375
set acc_calibration = -67,27,23,1
set blackbox_sample_rate = 1/2
set dshot_idle_value = 300
set dshot_bidir = ON
set motor_pwm_protocol = DSHOT300
set motor_output_reordering = 3,6,0,5,4,1,7,2
set bat_capacity = 8800
set vbat_max_cell_voltage = 420
set vbat_min_cell_voltage = 310
set vbat_warning_cell_voltage = 330
set force_battery_cell_count = 4
set ibata_scale = 193
set gps_ublox_use_galileo = ON
set pid_process_denom = 3
set simplified_gyro_filter_multiplier = 75
set osd_units = IMPERIAL
set osd_avg_cell_voltage_pos = 2150
set rpm_filter_min_hz = 60
set craft_name = OctoBeast
set pilot_name = Patrick L

profile 0

# profile 0
set profile_name = WIP TUNE
set iterm_relax_type = GYRO
set iterm_relax_cutoff = 4
set yaw_lowpass_hz = 65
set acro_trainer_angle_limit = 40
set i_pitch = 33
set d_pitch = 3
set f_pitch = 68
set i_roll = 31
set d_roll = 3
set f_roll = 66
set i_yaw = 31
set f_yaw = 66
set angle_p_gain = 60
set angle_limit = 40
set d_min_roll = 2
set d_min_pitch = 3
set dyn_idle_min_rpm = 15
set simplified_i_gain = 40
set simplified_d_gain = 10
set simplified_dmax_gain = 15
set simplified_feedforward_gain = 55
set tpa_rate = 0

rateprofile 0

# rateprofile 0
set roll_srate = 20
set pitch_srate = 23
set yaw_srate = 16

# end the command batch
batch end

Add any other context about the problem that you think might be relevant here

When manually testing the motors in the CLI using the commands of the form motor 1 1200, the motors do behave as expected.

As an additional test, I edited this line

betaflight-configurator/src/js/tabs/motors.js

Line 394 in 9816ea5

self.numberOfValidOutputs = motorCount;

to self.numberOfValidOutputs = 8; in src/js/tabs/motors.js and with that tweak the motor test in the configurator behaves properly. So the logic for determining the number of motors in a custom mixer seems to be the part that is specifically broken (though spinning any motors when none are believed to be present, and then not stopping them on command is also a terrifying bug).

I'm happy to do any additional tests or report values from the web inspector when running the PWA configurator, let me know if there's anything else I can do to help.

To update with the outcome of my testing and fix in the above PR, I found that the FC.MOTOR_DATA array is being checked for an entry set to zero to mark the end of a valid list of entries, but since the array is always of size 8, if the entire array is full (when 8 motors are configured), there's no 9th entry to contain a zero, so it returns a motor count of 0 instead of 8. The above PR resolves that by setting the motor count to the array's length if all entries are valid.

Fixed in #4213