Some weeks ago I added a bootloader mode to my custom FrSky compatible firmware OpenSky for commercial or DIY receivers. This allows hassle free updating of the OpenSky receiver firmware using the STM32 bootloader protocol. For targets such as the D4R-ii or others using an STM32 processor with the factory programmed bootloader nothing special had to be done. The tricky part was to support targets using the CC2510 processor as well. In order to do this I implemented the STM32 bootloader protocol on the CC2510 processor. Ok, that was the technical part, if you are just interested in using it you can probably forget this. The important information is that you can use any STM32 bootloader flashing application you have at hands to flash the receiver — Neat, eh? And what is more obvious than using the one included in betaflight?!
The next steps assume that you have configured betaflight to use your receiver in the serial rx SBUS mode with port sharing for telemetry (for tinyFISH you will have a checked box for serial rx and frsky telemetry selected both on UART2).
Start by forcing the serial receiver into the bootloader mode:
- remove the power
- short the bootloader pads (on the tinyFISH FC those are labeled “BL”)
- with the pads shorted power up the receiver and start the betaflight configurator
Now we need to know on which serial port your receiver SBUS and telemetry signal is connected to (let’s assume it is UART2). Open up the CLI tab and enter the following to enter the serial passthrough mode:
Note that the receiver is on UART2 but you entered “1” for the port. This might look wrong but UART2 is actually the second “real” serial port. And if you start counting at “0” as all computer science nerds do, you will end up at “1”. So serialpassthrough 1 is correct for UART2.
Now click disconnect and change to the firmware flasher tab.
- enable “no reboot sequence” (slider to the right)
- enable “full chip erase” (slider to the right)
- click on “Load Firmware [Local]” and select opensky_…_update.hex
- click “Flash Firmware”
- when done, power cycle your flightcontroller and receiver
You might be wondering what is going on here and why it seems like you upload the receiver firmware to the flight controller. This is not the case, the activation of the serialpassthrough mode in the previous step enables a “redirect” of data packets to the serial receiver. And as the serial receiver is in its bootloader mode it will process the firmware update packets and update itself.
If something went terribly wrong or you did not enable the serialpassthrough properly you might have uploaded the receiver firmware to the processor of your flightcontroller. When this happened your flight controller will not show up as you are used to after step 5. Don’t worry, this can be fixed quite easily: bridge the BOOT pads of your flightcontroller while power cycling it and upload its firmware through the firmware flasher.
Do the receiver needs Telemetry ? I’am wondering if i can use this method with a XM+ frsky, which have no telemetry ?
No, telemetry is not needed. Should be easy to port (pin mapping). I think someone forked my code and started to work on a port. But I do not know the state of that work.
Hello fishpepper, I put the firmware in the processor and now my card does not recognize in Windows, says unrecognized device, does not work in dfu mode.
You probably left out the step where you put the fc in passthrough mode. This means you flashed the opensky receiver firmware into your flightcontroller!
It’s easy to fix: put your FC into bootloader mode by pressing (and holding) the boot button (or shorting the boot pads) and power cycle it.
Then go to the fw update tab and load the matching fc firmware into your board.
Which pads have to be shorted on the uSKY receiver to force the receiver into bootloader mode? Also, when compiled from source, OpenSky gives us two different .hex files – ‘full’ and ‘update’ one – I’m guessing update is used to update the firmware if newer source was used, but can the ‘full’ version be flashed as well, or will that interfere with bootloader communication? Thanks!
Short ISP_CLOCK to gnd to enter bootloader mode.
The _FULL has to be flashed the first time using a cc debugger.
For the following upgrades through the bootloader need to flash the _UPDATE hex file.
When using the cc_debugger always use the full version.
Nice, do you have any future plans for OpenSky FW (are there any bugs that need fixing, maybe support for more HW or some new features that could be added)?
Right now I do not know any open bugs. But keep in mind that it is not tested that much yet. To be safe use it for small (<100g) copters for now 🙂