Spec for uploading firmware to the BCM20732S via HCI UART?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

Hi,

I want to be able to upgrade the firmware on our BCM20732S through our separate MCU which is connected to the BLE's HCI UART. This way, we can ship out firmware upgrades that the user uploads via USB, and it will update both the MCU's firmware and the BLE's firmware at the same time.

Is there some kind of spec or document or source code describing exactly how this process works? So far I know that you have to reset the BCM20732S while the RX line on the HCI UART is pulled high. Then it will wait for the first programming commands and respond with verification bytes. However I have no idea what those commands and verification bytes actually are - I'm just trying to emulate what is happening over the serial port when I program it from the SDK.

Here's an example Arduino sketch I've been using to try to get the BCM20732S to at least respond to a programming request. I used a serial port monitor to capture what the SDK is sending over the FTDI programmer, and am sending those exact same bytes, but I can't seem to get it to respond:

Test Updating Firmware on the BCM20732S via HCI UART

Does anyone have any tips or advice on how to upload firmware to the BCM20732S? Are there timing considerations or extra signals sent that my serial port monitor wouldn't be capturing?

Thanks!

Tyler

0 Likes
1 Solution
MichaelF_56
Moderator
Moderator
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

Unfortunately, we can not provide a detailed electrical spec for this interface.

However, you may want to look at the chipload utility explained here: Programming the 20732S MODULE USING 2073xTAG Board

This is essentially the command line version of the same utility that the SDK uses to program the device.

View solution in original post

0 Likes
23 Replies
MichaelF_56
Moderator
Moderator
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

I'm checking with the apps team now to see if this is something we can provide.

MichaelF_56
Moderator
Moderator
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

Unfortunately, we can not provide a detailed electrical spec for this interface.

However, you may want to look at the chipload utility explained here: Programming the 20732S MODULE USING 2073xTAG Board

This is essentially the command line version of the same utility that the SDK uses to program the device.

0 Likes
Anonymous
Not applicable

Will there ever be documentation for programming other than from a PC?

I'm building a WiFi connected product and would like to be able to update the BLE firmware in the field from my WiFi MCU.  It seems pretty silly to require a PC hook up to program a few KB of data.  Most of your competitors have some sort of DFU mode or slave boot mode.  Is there a different way to accomplish the same thing rather than reverse engineering your serial data stream?

0 Likes

OTA is one option, but it would require a BT connection on the Wi-Fi side.

Could you perform the updates over the peripheral UART?  If so, there is a sample showing how to use peripheral UART to upgrade firmware within the SDK.

0 Likes
Anonymous
Not applicable

So I've been thinking about this a lot. Since our initial production run is at lower quantities than 100,000 (the minimum for pre-loaded custom firmware), we need an easy way to upload the firmware in our factory. Not having the spec for the HCI UART load definitely blocks the easiest way for us to do this, so I've been discussing other ways to accomplish this with some engineers at Broadcom.

One solution, which is extremely simple and also very helpful, is for Broadcom to pre-burn default firmware that allows OTA upgrades straight out of the factory. This means that at our factory, we can upload our specific firmware via Bluetooth without even needing a debug header or bed-of-nails or other suboptimal solutions.

It really makes a lot of sense to do this. It's not really hard on Broadcom's part - just swap out the default firmware - and it offers an easy way to upload new firmware at our factory. There's no security issue since everyone is going to be overwriting the default firmware anyway, but it makes it much easier for those of us with smaller runs who can't afford the 100,000 unit minimum for factory pre-burn, or don't want to add costs of a bed-of-nails. It would also make it easier to get started with the module for development and debugging.

Would love to see some movement on Broadcom's part to make this process easier for customers with smaller first runs.

0 Likes
Anonymous
Not applicable

Hello bbharris,

You can achieve the same result by communication over SPI by using the code from applications in the SDK.

You don't necessarily need to use HCI UART for field upgrades.

Our HCI method is generally used for Testing and Factory download.

Let us know if this answers your questions

Thanks

JT

0 Likes
Anonymous
Not applicable

Thanks for the suggestions JT/mwf_mmfae, OTA is not an option, but UART or SPI might be.

My understanding of your suggestion to use the peripheral UART is that basically you are including the ability to do the upgrade in your application code.  So at the factory you program your app code using the HCI tools and then in the field you simply activate your software with a command (over UART or SPI), but it requires your code to be running. One concern I have with that approach, is what happens if a in-field upgrade fails (ie power unplugged at the wrong time) or there is a bug in the upgrade image? How do guarantee that you can recover?  Is there a hardware bootloader other than the undocumented HCI interface?

Another approach we were looking at is that we have the ability to program an image directly into the EEPROM.  The idea would be to hold the BCM20736 in reset, re-write the EEPROM from our MCU, release reset and let it boot. Do you see any issues with this idea? Is the structure of the EEPROM documented (or documentable)? Is any of the application code stored outside the EEPROM?

Thanks,

Brandon

0 Likes

For what it's worth (i.e. it works, but may not be sanctioned by Broadcom), holding '73X in RESET causes it to tri-state its SPI output pins allowing an external device to program the flash (via bed of nails contact).  It's empirically found to be 'way' faster than programming via the SDK tools.

0 Likes
Anonymous
Not applicable

Is there anyway for Broadcom to recompile the ChipLoad utilities to a ARM target like BeagleBone?  I have an BCM20732S connected to a BeagleBone and it would be really helpful to use the ChipLoad utilities directly to perform an upgrade.  It would also be a more reliable way to upgrade (i.e. won't brick) than using the firmware app to do the upgrade.

0 Likes

Unfortunately, the resources are not available internally to recompile the chipload utilities to a Texas Instruments development platform.

0 Likes
Anonymous
Not applicable

So I actually solved this problem in a way, by programming my main MCU's firmware with a USB-to-UART bridge. Since my main MCU (an Atmel SAM3X) was connected to the BCM20736S via the HCI UART, I was able to use ChipLoad to upload to my MCU's USB and it would pipe the commands straight over to the BCM20736S, just like it was a FTDI USB chip.

If you have an Atmel ARM chip, look in Atmel Studio for the "USB Host CDC Example". That will create a USB-to-UART bridge that you will need. Other ARM chips like the Beagleboard may have similar firmwares...

Anonymous
Not applicable

Hi odbol,

Thanks for the suggestion.  Unfortunately I need perform a field upgrade without a PC using the ARM / Beaglebone, not just at the factory.

-Howard

0 Likes

Note that the solution Tyler proposed is not using a PC. What he's essentially saying is that he figured out a means by which he could host our proprietary chipload utility inside of his main MCU environment, then use it to program the BLE device over the HCI UART. This appears to be exactly what you need.  Another method would be to use an OTA update mechanism.  However, the only peerapp we supply is a windows client, so that would need to be re-written for your target platform, but the functionality is all there and included within the SDK.

0 Likes
Anonymous
Not applicable

Hi mwf_mmfae,

Thanks for the comment.  However its my impression that he was using the Atmel SAM3X as a pass-through for a PC-Host.  The Atmel SAM3X is a ARM Cortex-M3 so I'm not sure how he would be able to run the x86 compiled ChipLoad utility from the Atmel SAM3X to the BCM2073x device.  Unless he is using some x86 to ARM emulator? Or I'm completely missing the point, in which case please correct me  

0 Likes

You could be correct.  What you are trying to accomplish is outside of what we typically support inside the WICED Smart environment, so I'm struggling to figure out what's possible outside of rebuilding our toolset inside your environment. I know for certain that I cannot release the binaries/source for our proprietary chipload tool.

I know that your team has an internal CSP account.  Can you enter a new case into this tool and assign it to the apps team that you normally work with on these custom types of requests.

79rpm arvinds

0 Likes
Anonymous
Not applicable

Thanks, I'll enter a new case for it.  However, from what I've read on this community forum, this does seems to be a pretty popular request so I hope Broadcom can come up with something that will benefit the users of this great device

0 Likes
Anonymous
Not applicable

I also have an interest about ChipLoad for prototype.

Of cource, we can use OTA/PUART upgrade with external MCU/smartphone after production.

But in prototyping phase, it's a good option to use ChipLoad on external MCU.

Is it possible to invite me to related CSP project?

0 Likes

The project referenced is for the customer asking above.  They have a project setup for their company already.

I'm still not sure who is going to port chipload over as this is a task we are not staffed to support at the current time.

0 Likes
Anonymous
Not applicable

I really like the idea of incorporating OTA support into the default firmware that the BCM2073xS is shipped with. It makes production so much simpler, and I'll bet it's easy to do at Broadcom. We already know that some version of the hello app is programmed into the part for testing.

It's one of those things that will help drive the adoption of the part by smaller developers, because it reduces their costs. Broadcom may be a big company, but to get big in the BLE space, it's wise to make it as easy as possible for all customers, especially, as in this instance, the invested effort is really small.

0 Likes

We have discussed internally and it seems that the uart_firmware_upgrade would  be better suited since OTA will be non-secure OTA. Not sure if customers will be ok with that, and OTA is generally slower than UART programming especially on iOS side.

The good news is that this is being considered internally.

nsankar

0 Likes
Anonymous
Not applicable

I'm glad it's being considered.

If the uart_firmware_upgrade method were used, would that require that the peripheral UART pins be used for production programming, or could this be done using the HCI pins? It's much more convenient to make one board that uses HCI for all programming, since that's already required for the development environment, and it also frees the peripheral UART pins for other uses.

My personal feeling is that we have to do OTA firmware updates anyway, so it is really simpler and less development effort to use OTA, even though it might be slower. Eventually, if we need to produce lots of chips, UART programming would be beneficial, but if that's the only method, it's harder for small developers to get started, and you complicate the hardware design.

0 Likes
Anonymous
Not applicable

You will need to have two test points on your system with the PUART and then perhaps use pogo pins or some other mechanism to connect and program the boards. PUART does not need to be dedicated to the programming. You can use this for other use cases. If you already have HCI then you don't need uart mode since you can program over HCI anyway. What we are talking about is adding a second option to program over the PUART. It does not remove the HCI programming option.

OTA is acceptable for initial development - but usually most folks will use UART to USB for development anyway.

OTA is not fast enough to be used for any form of manufacturing - unless you only ever plan to produce a few 100. This is especially true in iOS which limits the max BLE throughput.

0 Likes
Anonymous
Not applicable

To give you an idea of how slow OTA could be on iOS due to the OS limiting the maximum BLE data rate from the phone side - the approximate 14Kbyte of the WICED SENSE firmware takes around 5 to 7 minutes to update.

Using the PUART or HCI UART this would be matter of seconds.

While we agree that the OTA feature is a nice feature to have - the usability of this feature for actual production line manufacturing for any use case will be limited - unless most developers only intend to use Android 4.4 or new based devices for manufacturing which can do the OTA update with similar performance to the UART update.