My apologies for the delay, but it took me a little time to look into this and either validate and/or cancel some of my previous assumptions related to programming the part for the first time outside of the WICED SDK/Loader.exe environments.
So essentially, there are two scenarios. For the benefit of others that may find this post using the search function, I will attempt to describe both.
You program the part over the HCI UART using our SDK, or the Loader.exe (used for mass production) application which operates from the command line and is described here in this blog: http://community.broadcom.com/community/wiced-smart/wiced-smart-forums/blog/2014/04/23/factory-programming-example-programming-the-20732s-module-using-2073xtag-board
Specifically, the HCI UART on the part will come up in a programming mode based on the state of the HCI UART Rx line at reset:
- HCI UART Rx = High (Programming mode)
- HCI UART Rx = Low (Application mode, or debugging)
Once determined the Rx line is in programing mode, the application will be automatically loaded to EEPROM initially, then to internal RAM on boot up for execution.
To do this, the SDK downloads our minidriver to RAM and then runs it, then pushes the code over HCI uart to the minidriver which will then write to EEPROM.
Since the part ships with core firmware + embedded stack + profiles preloaded in ROM, everything works and this is the most common scenario for development and mass production.
The factory download is done using an external MCU as you've described.
According to the team, the initial factory download/programming always has to occur over the HCI uart using either our chipload.exe or a similar tool if you were to write your own.
As it turns out, the only way to execute the example uart_firmware_upgrade option (peripherhal UART option) at the factory is if there is uart_firmware_upgrade on the 2073x side and the corresponding (custom) application that implements the protocol required by uart_firmware_upgrade on the other side (MCU).
As for what is required on the MCU, that depends on the MCU. In general, a driver (which is specific to your MCU) for your UART, and firmware/application that implements the WICED Smart UART upgrade protocol (the message exchange to achieve the upgrade). The SDK comes with a sample for Windows, so you could use it for reference, but this would be the more difficult path of the two.
is number 1 an option, or must the device be programmed by your external MCU?
While option #1 is certainly do-able, it seems to require a technician at production to connect each board in turn to the PC, and run loader.exe. This would add a production step for us, due to the nature of our other production line.
I'd like to explore #2 more, as it will allow more automated download from the master MCU (which is pre-programmed), and not add a production step. You say the SDK has an example implementation of the "WICED Smart UART upgrade protocol" that runs over the HCI uart. Could you direct me to that? I'll then use that as a reference for implementing the HCI uart protocol in our master MCU.
I researched this some more this morning with the firmware team and it appears that I mixed some things up in my initial post regarding items related to number 2.
For one, the HCI UART must be used to program the part for the first time. The only way then for you to accomplish this on your Micro is to attach to that port while running the upgrade protocol on the micro. Then, you would need a means of disconnecting the micro from the port once programmed (put these lines into high-Z), otherwise, the part will see the micro attached each time it resets and think it's ready to be programmed again.
The second issue is the upgrade protocol for the initial load. uart_firmware_upgrade obviously helps you once the part is programmed and the PUART is being used for firmware updates, but for the initial load over HCI, the upgrade protocol would need to be deconstructed from either the loader.exe app, or from our mini-driver then installed onto your micro. According to the firmware team, this is not a trivial task and support to reconstruct the code on your micro would be nonexistent.
I'm sorry that I don't have a better solution than this, but this is all that's available today.
Thanks for that information. It seems that Option #1 is the only option so far, unless Broadcom were willing to publish it's internal protocol document for the HCI port?
Unfortunately, that seems to be the only option.