Motor desync at spin-up→closed-loop handoff — regression from previous firmware

[NosTrain]

Setup: M0138-1 ESC

motor kV=650
running firmware `39.25`
spinup_type=1 (sinusoidal), spinup_bemf_comp=1, timing_advance=60, sense_advance=20, demag_timing=1

already set per the low-kv tuning guide.

Key finding: these same motors/ESCs/params run fine (no desync) on an older firmware version. Nothing in the mechanical setup or param file changed — only the firmware. That's why we don't think this is purely a spin-up/commutation tuning gap.

Reproduction (unloaded motor, bench):

Constant RPM step from rest to 1000–1500 RPM: clean, stable.

Constant RPM step from rest to 3000 RPM: desyncs right at the spin-up→closed-loop handoff (~1.5s in, ~1000 RPM actual), gets stuck oscillating around ~640 RPM with elevated current, does not recover.

Threshold is consistent:
clean below ~2400 RPM target, desyncs above ~2500 RPM target.
A sinusoidal power sweep through the same RPM range shows intermittent desync but does recover — likely because the commanded value keeps sweeping back down, unlike a fixed high target.

python3 voxl-esc-spin-step.py --id 2 \
    --power 20 --step-amplitude 10 --step-frequency 0.5 \
    --waveform-type sinusoidal --cmd-rate 500 \
    --temperature-limit 70 --timeout 5 \
    --skip-prompt true --enable-plot 1

We've reproduced this on 39.RC11, 39.25, and 39.26

python3 voxl-esc-spin.py --id 0 --rpm 2500 --timeout 2.5 --skip-prompt true --enable-plot 1

The same command on the same motor/ESC does not desync on an older firmware version:

Board      : version 42: ModalAi 4-in-1 ESC (M0138-1)
UID        : 0x2030303355465716005A003A
Firmware   : version  39.00, hash e4f576a0
Bootloader : version    184, hash e1c038de

Questions for you:

Is there a known change between 39.00 and 39.RC11+ affecting the spin-up→closed-loop handoff, feedforward power calculation, or commutation timing near low RPM?

Is there a known interaction between spinup_bemf_comp/spinup_power/spinup_time_ms and large commanded RPM steps arriving right as spin-up completes?

Could you provide the 39.00 firmware binary?
We can't find this version in the GitLab history and it's currently our fastest path to confirming this is a regression.

What's the best way to debug this desync event more directly on our end — is there a debug/verbose logging mode on the ESC itself (e.g. raw BEMF/zero-crossing timing) beyond what the voxl-esc-tools plots already show?

Happy to share full logs/plots if useful.

Thanks,
Finn