BC127 DFU from Embedded CPU


We plan on using the BC127 in our next project, and would like the ability to upgrade the module using the CPU on our PCB. It is a PowerPC based CPU running Linux.
Do you have any source code or an app note describing how to implement DFU in Linux? I have only been able to find the Windows based upgrade tool which will not work under Linux.




Normally people test and validate with a firmware version and order that forever. As you say we only have a Windows tool available for downloading new firmware and we do not have document describing the protocol plus the BC127 does not support FOTA, sorry.





This is disturbing to hear. Looking at the Melody Change Log (https://www.bluecreation.com/MelodyAudio6/docs/change_log.html), almost every firmware release is fixing bugs. I understand that for end products that have no update mechanism, it is required to pick a firmware and stick with it. But our product will have regular updates containing bug fixes and new features, and it is a requirement that we be able to field upgrade a module if necessary. We don’t plan to upgrade the BC127 often, but if we discover a bug that has been deployed then we will need a solution. Having customers return units for a firmware upgrade is not an option.

Any insight you could provide on the DFU protocol would be helpful. I have seen other manufacturers use DFU and mention that it is possible for a microcontroller to implement, but I have not been able to find a useful description of the protocol.

I am afraid that if we don’t find a way to field upgrade the modules, we will have to find another solution with that ability.



The ability to upgrade/modify Melody firmware in the field ( preferably with a wireless solution ) i.e. an App or via a BLE connection is something we would really like also…

Especially with the innovation and rate of bug fix and firmware enhancements BC/Sierra is putting out for the BC127 / BC127 HD

Our dilemma is also upgrading any new commands that come from our Micro that controls the BC127…

So updating firmware and any commands via an OTA process is the 1st step ( if there is a solution for this ) then programming our Micro to pass these new commands via our input request to the Micro and then onto the BC127 is another hopefully solvable problem.

At any rate any discussion on OTA updates to the BC127 is of great interest to us as well!!!

Perhaps we can help fund any solution anyone proposes or finds… Share the cost, share the knowledge… just throwing that out there!!

Shaun - Vehroot



The DFU loading protocol is covered by QC bullet proof legal, this is why there is no open documentation around it.

What is feasible is that you contact us through your commercial channels and we can let you have ‘as is’ the code for the loading tool which will enable you to incorporate it into your code.





I had a similar question as well and was excited to see your suggestion. We’d be willing to take source as-is and keep it quiet if we could get it as well. If I have my people contact your people, who (or what department) would have them contact?


Howard Eglowstein
Principal Engineer, Princeton Audio



Missed the you need to sign an NDA bit but that should not be a problem. When I say commercial channel I mean go back through your distributor who will have a commercial manager and apps engineer assigned to them, they will be able to sort it out.

Note the whole doing things the Sierra Wireless (I come from Sierra) way is a bit new so it might not be instantaneous as we are all finding our way around the two different companies as we merge.





We were finally able to receive some assistance through our distributor. Haven’t been able to test it yet, but it looks like what we need.



Hi @dcoryh192

Did you finally succeed to implement DFU on embedded platform ?



Shouldn’t it be possible to upgrade the BC127 via UART? I was going to handle this issue by putting the MCU in a mode where it echos everything coming in via UART to the BC127 over UART.


Better option would be to port uBCSP protocol (used by DFU update tool) to the MCU.


I would also like to be able to upgrade the BC127 from an embedded CPU. The Bluetooth LE has documented vulnerabilities (https://github.com/virtualabs/btlejack). It was listed under CVE 2018 7252 along with the source code to perform the hack, this has since "mysteriously " disappeared from the CVE web page but it was downloadable for a few days, so assume it is out there. Please confirm if this vulnerability applies to the BC127 module, if so we would need to apply a patch when it is released. Any future vulnerabilities will also need to be patched.

The idea that we can fit and forget a network communications device and have no facility to easily upgrade the firmware if the security is compromised would become a barrier against designing it into a product in the first place and in todays world seems rather archaic?



And yet you would be surprised how many people do design systems without upgrade capability in place.

Couple of points.

  • A lot of the systems that all of our modules are designed into do not have the capacity to be able to perform an upgrade i.e. too small memory, too little power to
  • The BC127 is quite old now and as a result it was never designed with FOTA capability in mind hence a host solution has to be in place and the only mechanism we have is the DFU command and the underlying QC/CSR protocol.
  • For a lot of BT systems they do not have an internet connection, be it wired or wireless, so unless someone is visiting and servicing them frequently there is no way to update them anyway.
  • All of the newer short range products such as the BX310x have self contained FOTA designed in as a basic product requirement now (as long as they have an internet connection). The WWAN products have all had this for several years. If you want BT and do not want audio then the BX is by far the better product given it is cheaper and has BLE/BT/WiFi.

I am asking around re the vulnerability to the hack you have pointed out.





Re the CVE 2018 7252 you were talking about. Some points about it.

  • It requires devices to be 4.2 and above to use the newer security and key generation algorithm, so BC127 is ok, but it will depend on the other side to be a 4.2 device and up
  • You need to be close to the device (<5m) to be able to do the hijacking properly
  • It affects peripherals only.
  • If the link is authenticated (so using pairing/bonding procedure with MITM protection) then the hack will not work.

To the last point the default for the BC127 is set to ‘just works’ (SSP_CAPS=3) which means it is not protected but the means are there to enable the protection and given the device is worked with by engineers (and not consumers) security should be part of the consideration for implementation of their design which need to be balanced off against ease of operation.

Hence technically the unit is not susceptible as the mechanisms are in place to allow people to protect themselves, whether they choose to use them or not is up to them.




Hi @er1c, I can confirm that we were able to implement DFU from an embedded Linux platform using the code received from BlueCreation/SierraWireless. I am a HW engineer and there is the NDA stuff so I can’t go into too much detail, but it does work over a standard 2 wire UART.
The update takes ~10 minutes so it is not something you want to do often, but it did work for us.
Hope that helps.


Hi @dcoryh192, thanks for your message.
I implemented DFU from an embedded platform as well (not linux).
Yes it takes around 5 min for me.