Skystars F7 Mini HDPro + cli command "set looptime = 125" = FC Crash and have to recover from DFU

[IgnacioHR]

Hi,

The problem is even more serious. Here are the steps to reproduce.

1. Open CLI
2. type set looptime = 125
3. then type save

And the FC crash.
The procedure can be repeated, you just need to flash the firmware again.

How to recover.

You need to flash from DFU. The problem is that the USB port might remain in an inconsistent state and USB errors raise so you don't see DFU mode and the chip doesn't boot in DFU mode even if you press the BOOT button. The USB raises internally Error 43 in my case.

I purchased a new unit and desolder the old one. Once desoldered I tried again to plug it to the USB and, BOOM! at that time, the FC boot in DFU mode (pressing boot) so I flashed iNav 7.1.2 and tested the cli command just to confirm the issue.

Skystarts support is NON EXISTENT, I went to the web site and there is no way to send an email to them so I don't think they will fix anything.

Hope this information helps others and, in case set looptime = 125 breaks other FCs at lease you have the steps I did!

If you ask why I tried to set looptime to 125 that's because I'm using DSHOT 600 and it is stated in multiple places that 8K is the right loop time for that. This means, the loop time must be 125.

[Jetrell]

You may want to have a read through this discussion.

I had a similar issue some time ago. When setting the looptime by a none divisible value of the PID loop frequency. But I could still recover it after a re-flash.

[IgnacioHR]

Thank you for your confirmation this is not happening only to me

I'll be happy if someone with deeper knowledge of the code can review why some values of the looptime cause the FC to crash. I've spend about 2 hours digging the code but can't come up to any conclusion. It would require some simulators and some debug session and I'm not in a position to do it.

[sensei-hacker]

I purchased a new unit and desolder the old one. Once desoldered I tried again to plug it to the USB and, BOOM!

As you may know, on STM chips the DFU tries to load firmware over UART1, UART3 and USB. So if you have a receiver or GPS connected on UART1 or UART3, that can interfere with flashing. That's why desoldering everything worked - unplugging the GPS or receiver would be the same.

Commonly, people connect those two peripherals to UART2 and UART 6 to avoid that problem. 1 and 3 are used for things not powered by USB. If you need to use 1 or 3 for something powered by USB, unplug it while flashing.

[IgnacioHR]

Thank you!

This is, indeed, very good information! I'd the receiver in UART1 and the ESC is using UART3.
From now on, I'll try to avoid using UART1 for anything

Regards
Ignacio

[sensei-hacker]

Note it's fine to use UART1 for things like VTX control - anything that is powered by the battery but not powered by the USB.

Typically, USB-powered pads are labeled 4v5, while battery-powered ones are labeled 5V. Most often, people want their GPS and Receiver to power up from USB.