Betaflight-configurator: Cannot flash KissFCv2

[Tschingis]

Hello,

I have the new KissFCv2 which is now supported by betaflight 3.2.4, but i cannot get it flashed onto the fc with betaflight gui 10.1.0 (nor any other tool i know of).
I use the most recent version 10.1.0, selected KISSFCV2 as Board and 3.2.4 as FwImage. If i flash the image i always get the error "No response from the bootloader". I used different settings for noreboot sequence on/off and manual baudrate down to 57600. The other settings i left as default (off).
I tried to put the fc manually into bootloader by pressing the reset button during runtime. The blue leds starts to flash fast. In this state the Kiss GUI connects directly into fc firmware loader so i assume it is in bootloader mode (im not sure, did'nt find any documentation for bootloader behaviour).

I would appreciate any help on how to use bf gui correctly or any other tool to get bf fw flashed and running.

[mikeller]

@Tschingis: GitHub is for questions and discussion around the development of the firmware and tools. For questions around the configuration and use of Betaflight, please visit RCGroups.

[Tschingis]

I already asked in rcgroups in kiss fb group and got no answer, no one seems to use kissfc v2 with bf. Thanks for the help. Im pretty sure its a missing feature in bf gui to be able to communicate with kissfc v2 bootloader, but time will tell.

[Tschingis]

In this comment the contributor of kissfcv2 code clearly states that it does not work with bf gui flasher

https://github.com/betaflight/betaflight/pull/4752#issue-282081268

"it needs to be flashed with my flashloader or the GUI (press the reset button once before you connect to the GUI to get directly to the FC flasher tab)."

I thought all boards supported by betaflight should be flashable with betaflight gui, maybe i am wrong.

[AndersHoglund]

I thought all boards supported by betaflight should be flashable with betaflight gui, maybe i am wrong.

Of course all FCs supported are flashable. As long as the STM bootloader is up and running. But BF can NOT be held responsible for all different ways other kinds of firmware have implemented the way to get into the bootloader. Only if BF is already onboard, then BFC can order the FC into bootloader mode. With other firmware, or no running firmware, you have to do that manually. Using Boot button or Boot pads etc.

[jflyper]

@Tschingis BFC supports STMicro's built-in bootloader, while it looks like the KISSFCV2F7 has it's own boot loader running that is not compatible with BFC when some button is pressed, and the author of the #4752 is aware of this.

[Tschingis]

I pressed the bootloader button and i assume its in bootloader mode since it changed its behaviour (fast blinking blue led) and also the kiss gui behaves different after connection, but i cannot know if it is really in bootloader mode or some intermediate state.
Once i managed to get betaflight up and running, i will try again with bf gui flasher. I know that bf gui cannot implement all different commands for every fw to instruct the normal fc firmware to enter bootloader mode, but if its in bootloader mode it should be able to communicate, since bootloader will not get changed by any flashloader (except the stm programmer ...) . I tried also flashing with kiss gui but afterwards the controller did not react, maybe theres something else incorrect or not working.
I will have to ask maybe also the bf dev ...

[Tschingis]

@jflyper , yes i thought also in that direction since the kissfcv2 bootloader does activate those four ring leds, which is pretty unusual for a integrated bootloader.

[jflyper]

~I would probe the BOOT1.~ Sorry, there is no BOOT1 on F7.

[AndersHoglund]

Well, there are BOOT0 and NRST pins. I.e. KISSV2 has no "Boot"-button, but a "RST"-button. I have no idea how the BOOT0-pin is setup on KISSV2 and what boot address it points at. Probably not the built in STM bootloader... And that will cause difficulties. Still, do not blame BF/BFC for this.
Read section 4: www.st.com/resource/en/application_note/dm00164549.pdf
I think there is a typo in section 4.2, they show both BOOT0 and BOOT1 pins. Should probably be BOOT0 and NRST.

[Tschingis]

I got it somehow working. I was able to get a pre-release betaflight fw from someone of the kiss testing team and i was able to flash this fw with kiss gui and connect to that fw build. So i can confirm that just pressing the RST button at any point of time brings you into a kissonly bootloader indicated by a fast blinking blue led nearby the green power led which can be feed with any hex file from kiss gui. I think there is something wrong with the betaflight 3.2.4 firmware build. I tried again bfc flashing but as expected this keeps failing since there is the custom bootloader to which bfc cannot communicate. I also think its hw side impossible to communicate to the integrated stm bootloader since usb port is connected to uart4 with usb-serial bridge (see original kissfcv2 pullrequest, its meantioned there) and the integrated bootloader only works with uart1 and uart3 (see 4.3 table 3). So if bfc does not support at some point in time the kiss bootloader protocol there will be only the option of using the kiss gui to flash kissfcv2. I will create an issue for betaflight that build 3.2.4 for target KISSFCV2 does not startup.

[AndersHoglund]

Seems KISS has done quite some work to keep other FW away from their FC.... USB on UART4 was a nasty trick. But you can always connect an external USB-serial adapter to UART1 or UART3. Still needs to be able to boot into STM bootloader in some way. Is BOOT pin pull low? Needs to be high.
Maybe we need KBL (Kiss Boot Loader) support in a similar way we had (or still have?) OPBL support? Nah, would hate that.

[Tschingis]

I do not think that kiss want other FW away from their FC since the KissFCv2 bf target was made by felix, the creator of kissfc :) . I think is mainly so they can force you to activate your flight controller, a protection against chinese piracy . You would have to change the layout and make it incompatible to the original. The RST button pulls low, without button press its high, like in the application note advised :) .

[mikeller]

@Tschingis:

I thought all boards supported by betaflight should be flashable with betaflight gui, maybe i am wrong.

No, that is correct. The only condition for this is that for this to happen (at least initially), the board will have to be brought into the built in, non-destroyable STM bootloader. From there, a flash with 'full chip erase' should be performed, to make sure all settings are properly reset to the way that Betaflight expects them.

You have to understand that it is not possible for Betaflight to support running in an environment where flash and settings are shared with a proprietary custom boot loader - we simply do not have access to the information to make this work reliably. If KISS wants to do that, and release their own version of Betaflight that is custom built to work with their boot loader, that is fine, but we can provide only limited support for this. (Also, they have to release their modifications to Betaflight back under the GPLv3.)

I do not think that kiss want other FW away from their FC since the KissFCv2 bf target was made by felix, the creator of kissfc :)

You might be wrong there - It was Felix (@ronlix) who got the Betaflight target for the KISSFCV2 added: #4752. :wink:

[Tschingis]

I know felix (ronlix) added the kissfcv2 target and because of that i would doubt that kiss wants other fw stay away from their fc. Did i wrote something else ?

At the point of writing my initial statement about if bfc should support kissfcv2 flashing, i didn't know that its hw side impossible (without modifications) to use the non-destroyable stm bootloader.

[ronlix]

Hi,

we wanted BF to run on the V2. i made the support myself and pushed it for that reason.

i tried the hex from https://github.com/betaflight/betaflight/releases (betaflight_3.2.4_KISSFCV2F7.hex) and it is not working. not sure why.
i just build the latest master (1 feb 14:59 8738e7d62) here and it workes again.

if you enable the readoutprotection on the ST's, the st hard coded bootloader dont workes well. thats the reson i use my own bootloder. also the CP2102 is used to be able to reset the MCU without windows driver drama..

the boot pin is "hard" grounded so it should not be accessed. i also dont recommend to erase the KISS bootloader as the only way to bring it back would be to send us the FC.

the way the KISS bootloader gets used is open (in the KISS GUI here on github). feel free to add it to BF GUI if you like.

[edit]
just as it might matter i used
$ arm-none-eabi-gcc --version
arm-none-eabi-gcc.exe (GNU Tools for ARM Embedded Processors 6-2017-q2-update) 6.3.1 20170620 (release) [ARM/embedded-6-branch revision 249437]
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

but runned the gcc-arm-none-eabi-7-2017-q4-major update process before i build it
[/edit]

regards

Felix

[mikeller]

@ronlix: The fact that the KISSFCV2 is not designed to support flashing with the built in STM boot loader is a bit regrettable - there are plenty of other boards that use the same setup (CP2102) and flash with the STM boot loader, and it works just fine. We used to support custom boot loaders in the past (OPBL), and it often led to non-working builds for these targets, and essentially requires extra release testing to make sure these special firmware versions work.

Since the KISSFCV2 target cannot be released without specific testing (as we've seen with 3.2.4), and since the Betaflight configurator is not capable of flashing this target as it is, I think the best course of action is if we remove this target from the official Betaflight release for now. We can still have it as a supported target, and build it as part of the CI process, but not adding the hex file to the official release will at least stop people from trying to flash it with the Betaflight configurator with no chance of success. It makes more sense if you distribute tested versions of the Betaflight firmware together with the KISS flashing tool.

If you (or anybody else) wants to add support for the boot loader used on the KISSFCV2 to the Betaflight configurator, feel free to open a pull request. Once we got this, we can look into re-adding the KISSFCV2 target to the release.

[mikeller]

@ronlix: I just realised: If a user was to use the KISS flashing tool to flash Betaflight onto a KISSFCV2, and then used bl to put the MCU into STM boot loader mode, and then flashed another firmware using the 'Full Chip Erase' option in Betaflight configurator, this would essentially wipe the custom boot loader. If the firmware that was flashed was non functional, or did not have an option to put the MCU into the STM boot loader again, this would essentially hard brick the board, according to your statement above.

I have removed the hex file for KISSFCV2 from 3.2.4, and I will not be releasing any firmware for it until we have clarified this and identified a fix for it. I don't think handing users the tools to irrevocably break their hardware is in the best interest of any of us.

[ronlix]

Hi,

right, didnt thought abaut that. will have a look.

regards

Felix

[AndersHoglund]

Please, user selectable solder pads on BOOT pin. Low for Kiss bootloader, high for STM bootloader.
But I guess that would mean a V3 board.