I'm checking with the apps team now to see if this is something we can provide.
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.
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?
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.
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 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?
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.
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.
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.
Unfortunately, the resources are not available internally to recompile the chipload utilities to a Texas Instruments development platform.
1 of 1 people found this helpful
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...
Thanks for the suggestion. Unfortunately I need perform a field upgrade without a PC using the ARM / Beaglebone, not just at the factory.
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.
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