Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
The BCM2073x chip (SoC) has 40 logical GPIOs (P0-P39).The GPIOs themselves are broken out into three separate ports (meaningful when you start program...
The BCM2073x chip (SoC) has 40 logical GPIOs (P0-P39).
The GPIOs themselves are broken out into three separate ports (meaningful when you start programming):
• P0 through P15 on port0
• P16 through P31 on port1
• P32 through P39 on port2
The 32 pin package (i.e. the SoC - BCM20736 and BCM20737 *without* the S) only brings out 14 of the 40 logical GPIOs. The System in Package/SIP (the BCM20736S and BCM20737S modules) follows the SoC closely with regards to which pins are brought out (but there is a slight difference) and these are what you see in the SIP module datasheets.
Since the 32 pin package (SoC) and the modules are pin-limited, some of the logical GPIOs within the SoC are multi-bonded before bringing them out on the balls on the chip.
For the 32 pin package, the following pins are bonded in this manner:
P8 and P33 (only one of two is available)
P11 and P27 (only one of two is available)
P12 and P26 (only one of two is available)
P13 and P28 (only one of two is available)
P14 and P38 (only one of two is available)
Very Important Note: The SOC packaged part described above is not used for the SIP module. The SIP uses the raw die and wirebonds it differently than the DFN part, so the IOs described above for the SoC are not bonded together from the die - they are bonded together on the DFN wirebond package.
When leveraging the WICED™ Smart Hardware Interfaces for your development, you will run across several GPIO mapping tables in the document that look like this one:
Note here that you can use only one of the GPIOs (noted in black) from each of the vertical rows above. This is what is referenced in the WICED™ Smart Hardware Interfaces as a "group" (all signals must be selected from the same group, which is essentially the table).
All options may not be available in the package used within the SIP module (shown in red). Combinations shown in red text are also not generally available on the BCM20732 TAG. Additional options may be unavailable if they are being used for the peripheral UART interface.
All GPIOs support programmable pull-up and pull-down resistors, along with a 2 mA drive strength except P26, P27, and P28, which provide a 16 mA drive strength at 3.3V supply (this will change as the supply drops and the GPIO pins will sink less current).
The GPIOs are all capable of waking the device from sleep or deep sleep and the application can configure interrupts (both/either edges, level), pull-up/pull-down High-Z, etc.
The following GPIOs are available on the BCM2073XS based SIP Modules (remember, only 14 are brought out on the SIP module):
P8/P33 (Dual bonded, only one of two is available) Change per information received on 4/28/15: our packaging facility confirmed that P8 and P33 are both available and that on the SIP they are not dual-bonded
P13/P28 (Dual bonded, only one of two is available)
P14/P38 (Dual bonded, only one of two is available)
P12/P26 (Dual bonded, only one of two is available) Change per information received on 4/28/15: our packaging facility confirmed that P12 and P26 are both available and that on the SIP they are not dual-bonded - P12 if not used as P26 or external 32KHz LPO; If used as 32KHz LPO, then P12 and P26 are unavailable - If external 32KHz OSC is used then P12 is not available, but P26 is available
P11/P27 (Dual bonded, only one of two is available) -P11 if not used as P27 or external 32KHz LPO; If used as 32KHz LPO, then P11 and P27 are unavailable - If external 32KHz OSC is used then P11 is not available, but P27 is available
For unused dual bonded pins, the unused GPIO should be input/output disabled (especially when it is an input).
From the perspective of writing software against the GPIO mappings defined above, it's important to keep in mind that the GPIO is physically mapped to a BCM2073XS device within the platform.h file which is custom to the TAG development board by default.
However, this mapping in platform.h can be reconfigured for a custom design.
The values in platform.h then map to definitions and function prototypes in bleprofile.h
Note that the specific values in the bleprofile.h bitmasks themselves are not intended to be exposed as the code beneath these bitmasks is proprietary and cannot be released for reasons outside the scope of this discussion.
In addition to reconfiguring the mappings of your custom board within the bleprofile.h, GPIO can also be assigned within BLE_PROFILE_GPIO_CFG within the .c file for each application. This is also where you allocate/initialize the GPIO within your application. The bleprofile_xxx() routines are then how you use/access what you have configured above.
With this said, I realize there is some ambiguity in this message as we have documents like WICED™ Smart Hardware Interfaces which clearly states that the BCM2073X (note that this guide was written for the SoC, then modified slightly for the SIP module) includes two sets of APIs that are available for the application: the low-level driver API and the high-level profile API.
So yes, the Low Level API is there and in some cases ok to use, but we are not consistent in exposing everything a developer needs to actually use it effectively on a consistent basis.
Hopefully you guys find this helpful. I know many of you have tidbits to add, so feel free to comment (please stay on topic). I would love to see some examples and code snippets showing usage of the bleprofile_xxx() routines.
If you are having problems with your installer, check that the download size of the installer is roughly 260MB, installer problems are typically caused by incomplete downloads.
The picture below shows a very common error message. Our SDK utilizes a 32-bit version of an Eclipse based IDE which requires a 32-bit version of JRE to be installed. If you already have the 64-bit JRE installed, you will also need to install the 32-bit version as well. The JRE is designed to allow both 32 and 64 bit variants to be installed on the system.
The WICED Sense kit uses a Silicon Labs USB to Serial Device. The TAG3 board uses an FTDI USB to Serial Device. Both should be installed as part of the SDK 2.2.1 installation process. If not, the FTDI drivers for the TAG3 reinstall them using the file /WICED-Smart-SDK/Drivers/dpinst.exe (make sure you access from the command line). The Silicon Labs USB Drivers can be foundWICED Sense Table of Contents
Everything we have for the WICED Sense, such as schematics, drivers, and Android application source code, can be accessed through theWICED Sense Table of Contents. A great post for the WICED Sense is theWICED SENSE Kit BLOGwhich is like a WICED Sense quick start guide.
Some Android devices appear to have issues pairing to the WICED Sense Tag from inside the app, linked is a work-around that should allow you to connect to your Android device:WICED Sense Android Pairing Work-Around
b. This enables the programming of the BCM2073x devices without the need for a JTAG Interface
c. Note that Serial Wire Debug (SWD) debug/trace messages can also be output through the HCI UART port that’s onboard.
d. The SWD pins are muxed with HCI UART and are used in such a manner that the hardware and firmware can auto-detect the presence of SWD or the HCI host
e. This means that HCI based download (programming) and SWD (debugging) are mutually exclusive of one another.
3. In order to use the onboard UART header and a TTL-232RG-VREG3V3-WE USB to Serial cable to program your custom board, you would need to do the following:
a. With the BCM20732S board powered down, connect the TTL-232RG-VREG3V3-WE USB to Serial Cable to your PC (USB) then to the UART header on your board: RXD, TXD, VBAT and GND respectively.
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
c. Program the board using the Broadcom IDE just as you would if a BCM20732S Tag board were connected.
4. As an example, the BCM2073xTAG board has been enumerated as COM16 as shown below:
Figure 12: Sample COM AFTER 2073xTAG USB Insertion – COM16 Enumerated
If you’re not familiar with the installation of the drivers for your TAG board, refer to the WICED Smart™ Quick Start Guide found in the ~Docs folder of the SDK.
Section 5: Programming
Section 5.1: Software Programming Setup
Broadcom BCM20732x devices are be programmed using either the SDK Developer’s Tools or by using a command line tool called loader.exe.
The Loader directory of files to download can be found as an attachment at the bottom of this BLOG.
The SDK combined with the BCM2073xTAG Board provide the developer a convenient methodology for programming the BCM2073x or BCM2073xS Modules discussed below or for the developer’s Pre-Production Board.
To prepare the Production Board for Mass Production programming, the Loader command line tools provide a convenient process to automate the programming at a contract manufacturing facility or at a distribution programming center.
You will also need the ChipLoad.exe file attached at the bottom of this BLOG.
Section 5.2 System Programming Tools Setup:
The programming ecosystem of the BCM2073x/BCM2073xS devices involves the use of executable files both compile and produce necessary files for use in programming the modules.
The first file needed is the cgs.exe file to enable the board address (BD_ADDR) programming at the time of production.
The cgs.exe file is included in the SDK Directory (WICED\WICED-Smart-SDK-x.x.x\WICED-Smart-SDK\Tools\CGS\Win32) as shown below but can also be extracted from the loader.zip file located on the WICED SMART Community Forums download page located at the bottom of this BLOG.
Figure 13: Location of cgs.exe
The second file needed is the chipload.exe file to download the programming file to the programmer at the time of production.
The Chipload.exe file is included in the SDK Directory (WICED\WICED-Smart-SDK-x.x.x\WICED-Smart-SDK\Tools\ChipLoad\Win32) as shown below but can also be extracted from the loader.zip file located on the WICED SMART Community Forums download page located at the bottom of this BLOG.
Figure 14: Location of ChipLoad.exe
The cgs file can also be edited in the SDK Build window as shown below:
The third file needing editing for programming is the EEPROM file BCM2073xAx.cgs file. The cgs file is located in the SDK Directory (WICED\WICED-Smart-SDK-x.x.x/build/hello_sensor-BCM*_Q32-rom-ram-Wiced-release/A_*-hello_sensor-rom-ram-spar.cgsas shown below.
This is the file uses to program the EEPROM with the customer application.
Figure 15: Location of 20737_EEPROM.cgs file
The fourth file needing editing for programming is the EEPROM file 2073x_EEPROM.btp file.
The btp file is located in the SDK Directory (WICED\WICED-Smart-SDK-x.x.x\WICED-Smart-SDK\Platforms\BCM2073xTAG_Q32) as shown below.
This is the file uses to program the EEPROM with the customer application.
Figure 16: Location of 2073x_EEPROM.btp file
Section 6: Command Line Programming Procedure using the Loader.exe
Using the Loader Software Command Line Tools
The Loader Software tool utilizes a Command Line Tool to call the appropriate programming files to program the same BD_ADDR programming as the SDK Tool Chain, but in used in the volume programming environment.
Programming Procedure using Cygwin utility
The Cygwin Utility can be found at: http://www.cygwin.com/install.html is used to execute the Loader commands and accesses the appropriate configuration files used in the programming procedure.
NOTE: Cygwin is a 32GB file that takes time to download and install
Below is an example of using Cygwin to execute the Loader command line utilities.
Please observe the highlighted files described previously:
Figure 17: Contents of Loader.zip file at bottom of BLOG
Figure 18: Cygwin BCM2073x File Location
NOTE: You need to move the files highlighted above into the cygwin\home\<your name>\ directory under Cygwin.
Section 6.1 Converting cgs file to hex file
The following procedure converts the cgs file to a hex file:
1. Using Cygwin Tools installed above, type the following command:
a. ./cgs.exe -I <output_file_name.hex> –A 0xFF000000 –B <btp_file.btp> -D <file.hdf>
a. output_file_name.hex – will be the converted hex file. b. btp_file.btp – btp file for the 2073x_TAG board. c. input_file.cgs – built cgs file for the application from the SDK d. 0xFF000000 – base address for the EEPROM e. File.hdf - directories for hdf file
Results of the successful command execution:
Figure 19: Converting cgs file to hex file success
Section 6.2 Downloading the hex file
The following procedure downloads the hex file:
1. Run chipload.exe using the following command:
a. ./Chipload.exe –BLUETOOLMODE –PORT COM16 –BAUDRATE 115200nfc –MINIDRIVER <minidriver.hex> -CONFIG <output_file_name.hex> -BTP <btp_file.btp> -NODLMINIDRIVER b. Example Below:
A total of 2 contiguous memory areas were filled: [FF000000..FF000027] DATA (40 bytes) [FF0004C0..FF004BFE] DATA (18239 bytes)
Section 6.3 Hex File and BD_ADDR and Descriptions in Development
The WICED SMART SDK build process allows the programming of the BD_ADDR.
Below are the following steps:
1. The SDK is able to program some of the BD_ADDR bytes with random values or
2. The user can edit Platforms/BCM920736ATAG_Q32/20732_EEPROM.btp file and set DLConfigBD_ADDRBase to the desired value.
3. To use random address set DLConfigBD_ADDRBase = "20736A0*****" where every “*” will be replaced with a random value.
Section 6.4 SDK 2.0 HDF File Changes
The WICED SMART SDK 2.2 .hdf file is now in binary form.
Figure 22: Binary Form of .hdf file
Section 7 Hex File and BD_ADDR Configurations in Development and Mass Production
BCM2073x Design: Using the BCM20736 in SDK 2.2 from the Platforms Directory
Figure 23: Binary Form of .hdf file
Ex: DLConfigBD_ADDRBase = “20736A1*****”
1. Previously in SDK 1.1 this was the same Random Address on all computers. 2. Now, in SDK 2.2 it is random per computer that you use. 3. If you have 2 computers, it will generate 2 different Random addresses. 4. Everyone in your development team downloads on different computers, everyone will get different addresses. 5. However, in Development, the same bluetooth address when you reload the application. 6. Programing multiple boards on the same computer you will get the same address. 7. In the BUILD target say Device BD_ADDR = BD_ADDR or 8. Device BD_ADDR = Random and Make will generate a random number. 9. Each “*” is a random nibble – so you can place the “*” in the middle and have *1234. 10. Example:
a. Programming 4 devices on the same PC.
11. BD_ADDR goes into a file that the application does not have access. 12. It is loaded into a completely different sector 13. We can include it in one of the build targets to show users the option is there.
Figure 24: BT_DEVICE_ADDRESS in the Makefile
14. You want your board to have a specific BD_ADDR:
a. You can modify the Make Target:
b. For instance in i2c_temperature_sensor-BCM920736TAG_Q32 download:
Figure 25: _i2c_temperature_sensor selected
c. You can assign 6 bytes in Hex to the Target Name:
Figure 26: 6 Bytes assigned to Target Name
e. Here we did BT_DEVICE_ADDRESS=20736A112345
f. This is in the Quick Start Guide on the Make Target
g. Or you can put BT_DEVICE_ADDRESS=random
h. This will be random every time we do a build.
i. So this may be a good option for the user INSTEAD of the cgs.exe
j. The *.btp file parameters that you can change:
- ConfigDSLocation – Dynamic Section – This is where the code and the Config is stored - DLConfigVSLocation = is where your Link Keys are stored - We need 1K for at least 5 devices paired at the same time – Takes up 600 bytes. And this is all in EPROM Layout
Section 7.1 Hex File and BD_ADDR and Descriptions in Production
1. The WICED SMART SDK build process produces 2 hex files.
2. What is downloaded in the factory during mass production is the factory <app_name>-<platform>-rom-ram-Wiced-release.hex
3. This is the factory image and includes the BD_ADDR.
4. The SDK and will program some of the BD_ADDR bytes with random values or
5. The user can edit Platforms/BCM920732ATAG_Q32/20732_EEPROM.btp file and set DLConfigBD_ADDRBase to the desired value.
6. To use random address set DLConfigBD_ADDRBase = "20732A0*****" where every “*” will be replaced with a random value.
1. ChipLoad.exe loads the hex file into EEPROM or SFLASH depending on your configuration.
2. Once you generate the .hex file, you know were the BD_ADDR is going to be: Byte 21 offset
3. Jump to 21 Byte location and then generate the next 6 Bytes for the BD_ADDR and then you are done!
Please feel free to add comments and questions and I will update appropriately.