BD_ADDR: Changing BCM20737 Board Address for Production
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
Revision | Description | Date |
---|---|---|
Revision 1 | Part 1: Added Perl Script for Manufacturing Process - Attached file below | 10/22/14 |
Revision 2 | Changed Title and cleaned up text for BCM20737. | 10/31/14 |
PART 1: Process for BD_ADDR Manufacturing Programming - NO SDK
Contents of the WICED_Smart_Programming Download attached file at the bottom of this BLOG:
Perl Script Definitions - See file attached below:
- mac.pl:
$$r=int(rand(20480));
rand(20480):
1. 20480 is the maximum number you want to generate
2. Rand will generate a number between 0 and 20480
3. Upper 24 bits are the OUI numbers (Broadcom Corporation Assigned) - Please see BD_ADDR - how do you get one?
4. The lower 12 bits are unique for each device
5. If you have several production test stations operating in parallel it may be easier to generate random numbers.
6. A more elegant script may be written to generate a serialization for inventory purposes.
7. You can choose how to generate the lower 12 bits - either random or from a structured database.
2. printf "00101801%04X",$$r;
00101801%04X - Lower 12 bits are programmed to a Random Value
System Programming Tools Setup:
The programming ecosystem of the BCM2073x 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 LINK
Figure 22: 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 LINK
Figure 23: 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\WICED-Smart-SDK\Platforms\BCM20737TAG_Q32) as shown below.
This is the file uses to program the EEPROM with the customer application.
Figure 24: Location of 20737_EEPROM.cgs file
The fourth file needed is the EEPROM.btp file can also be edited in the SDK Build window as shown below:
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\BCM20737TAG_Q32) as shown below.
This is the file uses to program the EEPROM with the customer application.
Figure 25: Location of 20737_EEPROM.btp file
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.
Below is an example of using Cygwin to execute the Loader command line utilities.
Please observe the highlighted files described previously, but change :
Figure 26: Cygwin BCM2073x File Location
Converting cgs file to hex file
The following procedure converts the cgs file to a hex file:
1. Using command-line interface (e.g. Cygwin, cmd.exe), run cgs.exe.
2. Use the following command
a. ./cgs.exe -I <output_file_name.hex> –A 0xFF000000 –B <btp_file.btp> -D <file.hdf>
b. Example below: ./cgs.exe –I output.hex –A 0xFF000000 –B 20737_EEPROM.btp –D . A_20737A1-bleprox_mod-rom-rom-spar.cgs
3. Definitions of parameters:
a. output_file_name.hex – will be the converted hex file.
b. btp_file.btp – btp file for the 20737_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 27: Converting cgs file to hex file success
Downloading the hex file
The following procedure downloads the hex file:
1. Using command-line interface, run chipload.exe.
2. Use 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: ./chipload.exe –BLUETOOLMODE –BAUDRATE 11520nfc –PORT COM16 –MINIDRIVER uart_64bytes_DISABLE_EEPROM_WP_PIN1.hex –CONFIG output.hex –NODLMINIDRIVER –BTP 20737_EEPROM.btp
3. Definitions of parameters:
a. COM16 – connected port as connected thru enumeration
b. btp_file.btp – btp file for the TAG Board
c. Output_file_name.hex – converted hex file.
d. btp_file.btp – btp file for the TAG
- minidriver - Loads the Hex file into EEPROM or SFLASH image.
- The MiniDriver uses P1 as the Write Protect Pin
- If you use a different pin for Write Protect, then the MiniDriver will NOT work.
- MiniDriver is specific to the P1 Write Protect Pin because it is driven LOW before Writing begins.
- f. Chipload.exe - Runs the MiniDriver and does the CheckSum
- Chipload loads the image and does the CRC
- If it returns "0", it PASSES
- If it returns "1", it will PRINT the errors that were encountered
Results of the successful command execution:
Figure 28: Hex File Command Success
Results of the successful hex file download execution:
Figure 29: Download is completed successfully
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:
- The SDK is able to program some of the BD_ADDR bytes with random values or
- The user can edit Platforms/BCM920737ATAG_Q32/20737_EEPROM.btp file and set DLConfigBD_ADDRBase to the desired value.
- To use random address set DLConfigBD_ADDRBase = "20737A1*****" where every “*” will be replaced with a random value.
SDK 2.0 HDF File Changes
The WICED SMART SDK 2.0 .hdf file is now in binary form.
This is a departure from the SDK 1.1 hdf that supported a superset of features that do not apply to the current device enhancements.
PART 2: Process for BD_ADDR Manufacturing Programming - Using SDK
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/BCM920737ATAG_Q32/20737_EEPROM.btp file and set DLConfigBD_ADDRBase to the desired value.
3. To use random address set DLConfigBD_ADDRBase = "20737A1*****" where every “*” will be replaced with a random value.
Ex: DLConfigBD_ADDRBase = “20737A1*****”
1. Previously in 1.1 this was the same Random Address on all computers.
2. Now 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.
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-BCM920737TAG_Q32 download:
c. You can assign 6 bytes in Hex to the Target Name - In this case we used 20736 instead of 20737:
e. Here we did BT_DEVICE_ADDRESS=20736A112345
f. This is in the Quick Start Guide WICED Smart Quick Start Guide (SDK 2.x and TAG3 Board) 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 paramters 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
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. The SDK uses this when your target, in our case the BCM20737S SPIL Module, uses ‘download’ or ‘recover’ in the make file.
4. This is the factory image and includes the BD_ADDR.
5. The SDK and will program some of the BD_ADDR bytes with random values or
6. The user can edit Platforms/BCM920736ATAG_Q32/20736_EEPROM.btp file and set DLConfigBD_ADDRBase to the desired value.
7. To use random address set DLConfigBD_ADDRBase = "20736A1*****" where every “*” will be replaced with a random value.
Please feel free to post comments and questions.
JT
- Subscribe to RSS Feed
- Mark Article as New
- Mark Article as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
JT, as following your guide, I can set my BT addr to random value.
Is there method to set different BT addr without building image?
- Subscribe to RSS Feed
- Mark Article as New
- Mark Article as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
Hello Brian,
Please let me know the purpose or use case of your question.
Do you wish to change the BD_ADDR after your have built your .hex file?
Here are some related comments:
- The BD_ADDR goes into a file that the application does not have access to and is loaded in to a different sector of On-Chip Memory.
- You can always generate the .hex file from the .cgs file using cgs.exe and then download that image using chipload.exe, all from the command line.
- Or if there are no code changes, then use the usual method from the IDE (it will only relink).
- In any of the examples in the SDK, add BT_DEVICE_ADDRESS=AAAAAAAAAAAA for a specific address or BT_DEVICE_ADDRESS=random if you want true random address every time you download an image.
- In a future SDK version, we may include the provision to modify the BT addr after the image has been built.
I hope this answers your question
J.T
- Subscribe to RSS Feed
- Mark Article as New
- Mark Article as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
Thanks JT,
I buid code on one computer, then load to 8 BLE modules for deploying and working in an office environment. Everyone needs their unified addr. I think cgs.exe is enough for my current usage.
Brian
- Subscribe to RSS Feed
- Mark Article as New
- Mark Article as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
Thank you for this useful post. I wonder if there is a way to update the BD address using OTA?
- Subscribe to RSS Feed
- Mark Article as New
- Mark Article as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
There is no way to update the BD_ADDR over the air and this is deliberate because BD_ADDRs are generally assigned by IEEE and have a specific format. If BD_ADDR is allowed to be updated over the air, then there is a very good possibility that you will have clones in the filed which is not allowed. Since BD_ADDRs are allowed to be assigned/written to NV only in the factory, you will have a lot more control over what address ranges are used during manufacturing.
- Subscribe to RSS Feed
- Mark Article as New
- Mark Article as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
Thank you very much, I think this is the right approach.
Just wanted to see because I have two units with the same BD address, but no programming interface to them.
- Subscribe to RSS Feed
- Mark Article as New
- Mark Article as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
under PART 2: Process for BD_ADDR Manufacturing Programming - Using SDK
Step 14C, procedure is not working, it does not seem to be obeying the command line. Are these directions only valid for SDK 2.x or will they work for SDK 1.5 which is what I have? Can I get the Makefile to enable this command line switch to work?
- Subscribe to RSS Feed
- Mark Article as New
- Mark Article as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
On SDK 1.1 (there is no 1.5), you may want to look at the instructions here: Programming the 20732S MODULE USING 2073xTAG Board
I believe on this SDK, there are just the two options:
1.
Edit Platforms/BCM920732ATAG_Q32/20732_EEPROM.btp file and set DLConfigBD_ADDRBase to the desired value
OR
2.
Set DLConfigBD_ADDRBase = "20732A0*****" where every “*” will be replaced with a random value, which unfortunately will be the same random address on all computers used for development (changed in SDK 2.X to random address per computer that you use for development).
I'll let j.t respond as to whether the Makefile used in 14c. can be used with SDK 1.1
- Subscribe to RSS Feed
- Mark Article as New
- Mark Article as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
hi Jt,
could I use this cgs.exe for 20738 to convert a hex ?
- Subscribe to RSS Feed
- Mark Article as New
- Mark Article as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
@arvinds
How about changing the address during runtime? Is that possible?
Some applications require changing BDADDR to address privacy concerns.
Thanks!
- Subscribe to RSS Feed
- Mark Article as New
- Mark Article as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
Per arvinds here: BD_ADDR: Changing BCM20737 Board Address for Production
And in another thread I am having a hard time locating, my understanding is that BD_ADDRs are not designed to be changed once programmed in production.
"There is no way to update the BD_ADDR over the air and this is deliberate because BD_ADDRs are generally assigned by IEEE and have a specific format. If BD_ADDR is allowed to be updated over the air, then there is a very good possibility that you will have clones in the filed which is not allowed. Since BD_ADDRs are allowed to be assigned/written to NV only in the factory, you will have a lot more control over what address ranges are used during manufacturing"
- Subscribe to RSS Feed
- Mark Article as New
- Mark Article as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
Hi mwf_mmfae,
Thanks for following up.
Yes, one could easily shoot himself on the foot by doing over-the-air BD_ADDR changes. But careful changes by the application during runtime are sometimes necessary for privacy reasons. I don't want to be indelicate by mentioning your direct competitors, but Qualcomm's Gimbal supports that. In fact Qualcomm Gimbal beacons spit out a new MAC address every 0.8 seconds (source Radius Networks, and also, we have a few of those and can provide traffic captures if needed).
So, can you definitely confirm that changing the BD_ADDR by the application is not supported on the BCM2073x?
Thanks!
Javier
- Subscribe to RSS Feed
- Mark Article as New
- Mark Article as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
Thanks for sharing. I was not aware of this.
- Subscribe to RSS Feed
- Mark Article as New
- Mark Article as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
Hi mwf_mmfae,
So, is that final? Can you definitely confirm that changing the BD_ADDR by the application is not supported on the BCM2073x? Do you know if it might be supported in future SDK releases?
Javier
- Subscribe to RSS Feed
- Mark Article as New
- Mark Article as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
I think what you are referring to is called a resolvable private address (RPA).
RPA is a feature that allows your device to change it's BD_ADDR such that a paired device can still understand it's the same device. I believe that an iOS device supports RPA and changes the BD_ADDR every 15 minutes. It can do this because during the pairing process a special key is distributed to the peer. Therefore, when a peer sees the advertisement from the iPhone, it can decode the BD_ADDR and understand that it is the same device that it was paired with initially.
The BCM20736/7 supports connections from devices that change BD_ADDRs in this manner, however, these devices do not have logic built in to change their own BD_ADDR.
There are a couple of threads already on the website pertaining to this topic.
Do a search on "resolvable private address" and you will see a couple of the main ones.
-
This widget could not be displayed.Anonymous