BCM20737S (SIP) programming interface

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

cross mob
Anonymous
Not applicable

Hello,

From the BCM20737S documentation I cannot figure out how the device is programmed. I've learned, that there is HCI/DFU firmware update capability provided. But how are the modules programmed in the first place?

Is there a programming guide available somewhere? How does the SiP come out of the factory, is it pre-programmed with some HCI/DFU bootloader inside? What happens if errors occur during programming, is there a possiblity to program/flash the device from external?

Thanks,

Janos

0 Likes
1 Solution

The Embedded  stack (HOST and Controller functions) is built into ROM: L2CAP, GAP, GATT (attribute profile and protocol), SMP, HCI and below

ROM has built in drivers for I2C EEPROM, SPI EEPROM, SPI Serial flash, both UARTs, etc.


There's also many sample configurable applications that are also included in ROM: wireless charging, automation IO, blood pressure monitor, cycling/running speed cadence, glucose meter, master/slave, temp sensor, beacon, long characteristic, OTA, PWM, speed test, time, proximity and others

So in summary, Core firmware + embedded stack + profiles + peripheral drivers come preloaded in ROM (total 320 KB)


In addition to storing the application code, the EEPROM (NVRAM) includes BD ADDR (Bluetooth Device Address), Patches and Bonding/Pairing information;

Application code then links against ROM and patches.

Lastly, there is roughly 27K of RAM available.  As mentioned earlier, the Minidriver itself will manage RAM allocation for you during the programming process.

View solution in original post

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

The minidriver is the brains of the download process (contains the protocol used to talk to the BLE device) as it exists within the SDK as hex code and is uploaded to your board during the programming process.

Specifically, the SDK triggers the process which downloads the minidriver to RAM (on your board) and then runs it.  The SDK then pushes the code over the HCI uart to the minidriver, which will then write to EEPROM.

The SIP comes programmed from the factory with an application installed as this is used for testing.

There is no bootloader, the minidriver handles the memory map itself and knows where to place your application within the 27K of available RAM.

You cannot program the NVRAM directly.  You must program the device using either the SDK or the Command Line tools described here: Programming the TAG2/TAG3 Board using command line tools

0 Likes
Anonymous
Not applicable

mwf_mmfae schrieb:

The minidriver is the brains of the download process (contains the protocol used to talk to the BLE device) as it exists within the SDK as hex code and is uploaded to your board during the programming process.

What programming process are you referring to? Is this minidriver programmed prior to shipping, and can it never be removed?

I'm hearing the term minidriver for the first time, is there any documentation available on this?

mwf_mmfae schrieb:

The SIP comes programmed from the factory with an application installed as this is used for testing.

Do you have any information on the application, which the SIP comes programmed with?

0 Likes

The minidriver is provided in hex format inside of the SDK: \WICED\WICED-Smart-SDK-2.2.1\WICED-Smart-SDK\Platforms\BCM920737TAG_Q32\uart_DISABLE_EEPROM_WP_PIN1.hex

Both the Eclipse IDE and the command line tools described here on the website use this tool to program the part as it contains the programming protocol.

This tool must be used to program the device.  There are no other alternatives.

The program that is flashed on to the device is a simple one that is used for testing.

david_armour

0 Likes
Anonymous
Not applicable

Thanks for explaining, but this throws me back in understanding the update mechanism.

Without having a JTAG interface, and by only having a serial UART interface: What instance in the raw BCM2073xS receives the firmware update?

You wrote "Specifically, the SDK triggers the process which downloads the minidriver to RAM (on your board) and then runs it.". How does it do that triggering, what is the mechanism and where is it documented? As I have understood so far, there is no bootloader waiting to be triggered.

You also wrote "The SDK then pushes the code over the HCI uart to the minidriver, which will then write to EEPROM.". This leads to the question: where is the HCI implemented, if not in the minidriver, when the SIP comes out of the factory?

For me this still looks like the chicken-and-egg-problem. Which it certainly is not, but where is all this documented so that I can go and read it myself?

0 Likes

Assuming you are referring to the user program/application and not the ROM based firmware, profiles, peripheral drivers, etc. (all of these are built into ROM)

The module is assembled at our packaging house and is then programmed with an application after assembly over the HCI UART (HCI UART is in 'programming' mode as indicated by the state of the Rx line) using the command line programming procedure described here on the forum.  They have created a custom programming jig which allows them to program/test a number of these devices in parallel.

During this process, the minidriver (external, and then loaded during the programming process into RAM)  itself knows the memory map of the device along with where in RAM to write the user program - a bootloader is not needed.

None of these user application details are exposed externally to the user.

0 Likes
Anonymous
Not applicable

mwf_mmfae schrieb:

Assuming you are referring to the user program/application and not the ROM based firmware, profiles, peripheral drivers, etc. (all of these are built into ROM)

May it be possible, that "all of these are built into ROM" answers all my questions? More precisely, is the HCI interface also built into ROM? Or more general: What "all" is built into ROM - and where is it documented?

For clafification, in my question I was regarding to how the HCI interface is programmed into the SIP in the first place. I have learned, that user application can be programmed via HCI. The crucial question however is, how does the HCI interface/driver itself get into the SIP. If it is already in ROM, this would be the answer. Except I am so surprised that you guys don't seem to have documentation for this (from my point of view) very important topic.

mwf_mmfae schrieb:

The module is assembled at our packaging house and is then programmed with an application after assembly over the HCI UART (HCI UART is in 'programming' mode as indicated by the state of the Rx line) using the command line programming procedure described here on the forum.

In Programming the TAG2/TAG3 Board using command line tools I read at Section 4.3.b: "Power your board up while making sure that RXD is held high during power up. Note that by default this pin is pulled low through an internal 10k ohm resistor". Again I have to ask, where is this behaviour documented?

In my opinion, this forum page is clearly not a documentation of the systems behaviour, as it gives no clue on how to customize or implement the update procedure for e.g. an embedded system.

0 Likes

The Embedded  stack (HOST and Controller functions) is built into ROM: L2CAP, GAP, GATT (attribute profile and protocol), SMP, HCI and below

ROM has built in drivers for I2C EEPROM, SPI EEPROM, SPI Serial flash, both UARTs, etc.


There's also many sample configurable applications that are also included in ROM: wireless charging, automation IO, blood pressure monitor, cycling/running speed cadence, glucose meter, master/slave, temp sensor, beacon, long characteristic, OTA, PWM, speed test, time, proximity and others

So in summary, Core firmware + embedded stack + profiles + peripheral drivers come preloaded in ROM (total 320 KB)


In addition to storing the application code, the EEPROM (NVRAM) includes BD ADDR (Bluetooth Device Address), Patches and Bonding/Pairing information;

Application code then links against ROM and patches.

Lastly, there is roughly 27K of RAM available.  As mentioned earlier, the Minidriver itself will manage RAM allocation for you during the programming process.