Using pass through to flash escs with 3.1.6

[Rups63]

I ran across a couple of forum posts with this same issue that I'm having. I flashed 3.1.6 onto my f3 board and was having trouble reading esc firmware and flashing esc firmware using pass through. I flashed back to 3.1.5 onto the f3 board and the escs were read and I was able to flash firmware without a problem. The difference was night and day.

[antonzolotukhin]

BLheli configurator doesn't see the ESC at PWM output No. 1 on my airbot f4 clone with bf 3.1.6. All three other ESC are visible and programmable.
To ensure that's not the ESC problem i soldered this ESC to other PWM output and it worked.
No one resource/output was redefined by me all resources/outputs is default.

Problem only with blheli passthrough. In flight all ESCs are running well with multishot at 32 KHz.

[RipperDrone]

Maybe related to 32kHz mode? Have you tried switching it off and check BLHeli flashthru again? Just to narrow it down...

[antonzolotukhin]

I'm not using 32KHz pid/gyro loop. I run 8/8/32.

[antonzolotukhin]

This what blheli shows after i click check button:

---------------------------
Information
---------------------------
Found Multiple ESC configuration in SiLabs mode:

ESC# 1 : Erased or unknown firmware
	(BLHeli Bootloader c)

ESC# 2 : DYS_XM20A - Rev. 14.85 - Multi
	[MASTER]
	(BLHeli Bootloader c)

ESC# 3 : DYS_XM20A - Rev. 14.85 - Multi
	[SLAVE]
	(BLHeli Bootloader c)

ESC# 4 : DYS_XM20A - Rev. 14.85 - Multi
	[SLAVE]
	Motor Direction: Reversed
	(BLHeli Bootloader c)
---------------------------
OK   <   
---------------------------

When i try to flash #1 esc:

---------------------------
Error
---------------------------
Write Setup Section Failed!
Retry?
---------------------------
Abort   Retry   <   
---------------------------

my diff:

# diff

# version
# Betaflight / AIRBOTF4 3.1.6 Feb 21 2017 / 14:10:50 (1fd502c)

# name

# resources

# mixer

# servo

# servo mix


# feature
feature VBAT
feature MOTOR_STOP

# beeper
beeper -ON_USB

# map

# serial
serial 2 64 115200 57600 0 115200
serial 5 1 115200 57600 0 115200

# led

# color

# mode_color

# aux
aux 0 0 0 1800 2100
aux 1 27 2 1775 2100
aux 2 1 1 900 1150
aux 3 12 0 1375 1625

# adjrange

# rxrange

# rxfail
rxfail 5 s 1000
rxfail 6 s 1000

# master
set min_check = 1030
set debug_mode = NOTCH
set min_throttle = 1035
set use_unsynced_pwm = ON
set motor_pwm_protocol = MULTISHOT
set motor_pwm_rate = 32000
set small_angle = 180
set serialrx_provider = IBUS
set vbat_scale = 109
set vbat_max_cell_voltage = 42
set vbat_min_cell_voltage = 34
set align_board_yaw = 90
set deadband = 2
set yaw_deadband = 2
set pid_process_denom = 1
set blackbox_device = SPIFLASH

# profile
profile 0

set vbat_pid_gain = ON
set p_pitch = 63
set i_pitch = 52
set d_pitch = 35
set p_roll = 55
set i_roll = 42
set d_roll = 32
rateprofile 0

# rateprofile
rateprofile 0

set rc_expo = 10
set rc_yaw_expo = 10
set thr_mid = 36
set thr_expo = 40
set roll_srate = 67
set pitch_srate = 67
set yaw_srate = 67

# resource
resource BEEPER 1 B04
resource MOTOR 1 B00
resource MOTOR 2 B01
resource MOTOR 3 A03
resource MOTOR 4 A02
resource MOTOR 5 A01
resource MOTOR 6 A08
resource PPM 1 B14
resource PWM 1 B14
resource PWM 2 B15
resource PWM 3 C06
resource PWM 4 C07
resource PWM 5 C08
resource PWM 6 C09
resource LED_STRIP 1 A01
resource SERIAL_TX 1 A09
resource SERIAL_TX 3 B10
resource SERIAL_TX 6 C06
resource SERIAL_RX 1 A10
resource SERIAL_RX 3 B11
resource SERIAL_RX 6 C07

# status
System Uptime: 317 seconds
Voltage: 122 * 0.1V (3S battery - OK)
CPU Clock=168MHz, GYRO=MPU6000, ACC=MPU6000
Stack size: 2048, Stack address: 0x10010000
I2C Errors: 1, config size: 1636
CPU:4%, cycle time: 126, GYRO rate: 7936, RX rate: 49, System rate: 9

# version
# Betaflight / AIRBOTF4 3.1.6 Feb 21 2017 / 14:10:50 (1fd502c)

[man-deli]

I've experienced this as well on Betaflight 3.1.7, downgraded to 2.9.1 and was able to use the BLHeli pass-through mode. I was using a NAZE32 with DYS SN20A based ESC (RMRC 4-in-1).

[spuder]

Possibly related to #2319

[mikeller]

@spuder: #2319 looks very much like it's a problem with a badly cloned board.

[Buster51873]

I have the official Betaflight F3 Omnibus board (two of them actually) and I am still having this exact same problem. Downgrade to older Betaflight and everything works just fine. Its definitely a software issue not a hardware issue. Can we please have this fixed?

[DieHertz]

No, unfortunately we can't reproduce it and as a result can't fix it.

What software you're using, is it BLHeliSuite or BLHeli Configurator for Chrome? If it's Chrome, which Chrome version do you have, which drivers you're using for your FC and maybe other details you could provide?
So far there's no clear pattern in how this issue occurs, except it appeared somewhere in 3.1.x. Even F1 are affected by at least 1 report, probably because F1 aren't the most popular option with BetaFlight anymore.

[Buster51873]

Using BLHeliSuite, I dont know the drivers. But hey at least we know where it started 3.1.x

Is there no way to revert the code for the pass though to the old version of that section to see if that fixes the problem. Then the code can be analyzed to see where it all went wrong?

[Buster51873]

Id love to help.

If it happens again what can I do to give you the information you need?

[DieHertz]

Passthrough code has not changed :-)
Lots of other parts have :-(
Unfortunately there's not much you can do without a logic analyzer and/or hardware debugger.
Something fishy is going on, BLHeliSuite logs just contain a protocol error message which is useless.

[spuder]

I can reproduce this consistently.
Looking at the diffs between October 18th 2016 (3.0.1) and January 25th 2017 (3.1.0) returns 30 pull requests where the code change is most likely. 8 of them reference esc passthrough.

30 merge requests related to esc's

https://github.com/betaflight/betaflight/issues?utf8=%E2%9C%93&q=%20is%3Amerged%20esc%20merged%3A2016-10-18..2017-01-25%20

8 merge requests related to esc passthrough

https://github.com/betaflight/betaflight/issues?utf8=%E2%9C%93&q=%20is%3Amerged%20passthrough%20merged%3A2016-10-18..2017-01-25%20

21 reference SPRACINGF3 specifically

https://github.com/betaflight/betaflight/issues?utf8=%E2%9C%93&q=%20is%3Amerged%20SPRACINGF3%20merged%3A2016-10-18..2017-01-25%20

I've looked though these diffs multiple times for something obvious, but I'm not a C developer. Hopefully someone more experienced can spot what change would cause this regression.

[DieHertz]

Looks like you haven't browsed through your search results :-) Searching by PR name is generally useless, you have to perform code search on the files of interest.