1 of 2 people found this helpful
The answer to: 3. How do we assign unique BD_ADDR to our parts at production stage ?
is: It is assigned automatically.
The answer to 2: Not correct.
The answer to 1: resolve OUI******. Is it at compile time or runtime?
is: There are many methods for doing that. One method is to have code that checks after power-up for an existing BD_ADDR and if there is none it can be generated at this point. Some vendors elect to store this BD_ADDR in flash so it does not need to be created again.
Advice: try reading BD_ADDR and report results here.
Could you clarify which device you are using, SoC (external EEPROM) or SiP module (Internal EEPROM).
Most of the instructions on the community relate to programming the internal EEPROM of the SiP module.
For the external EEPROM, they should be able to be programmed independent of the BCM2073X. Avnet should be able to handle programming the unique BD_ADDRs you purchase/allocate per the instructions here: BD_ADDR - how do you get one?
We are using BCM20736, and external EEPROM is Microchip 24FC512-I/ST 512Kbit EEPROM.
Avnet is able to program the binary that we share with them.
My question is about the binary itself.
We generate the binary using WICED SDK. When compiling our source, we set btp file with following option
DLConfigBD_ADDRBase = "OUI******"
We share the .hex file generated as output of make command with Avnet.
My questions specifically are:
1. When is wildchar in BD_ADDRBase resolved to random numbers? Is it done at .hex file generation stage?
2. When I open up .hex file, I see that there is a complete 6 byte BD_ADDR embedded in it. This leads me to believe that programming this hex file onto multiple parts will end up programming the same BD_ADDR to all parts. Can you confirm if this is true?
3. We are NOT using blecm_set_static_random_bd_addr() call in our application. We are ONLY relying on btp file to generate random BD_ADDR within our OUI. I want to understand if this .hex file is programmed on multiple parts, will this approach work to give us random BD_ADDR within our OUI? Or will all parts end up with the same BD_ADDR ?
2 of 2 people found this helpful
The Help Article here explains the process of combining .btp and .cgs files to create a hex file that is then programmed onto the part using either the SDK or the Command Line tools: Programming the TAG2/TAG3 Board using command line tools
Answers to questions:
2. It will remain random based on the computer you use for programming. Take a look at part 2 here, this is answered as one of the bullet points: BD_ADDR: Changing BCM20737 Board Address for Production
3. If programmed on the same computer, the same BD_ADDR will result. See above.
Note that none of this matters if Avnet is mass programming the devices for you as you provide them your Hex file (firmware) with the block of BD_ADDRs you pruchased and they can modify the BD_ADDR within the Hex file directly as part of the process they have developed.
3 of 3 people found this helpful
You're correct in that the .hex file contains the 6 bytes that comprise the full BD_ADDR. They're always located at the same offset. Avnet's programming service has an auto-increment / serialization option you can use to serialize each EEPROM. Your Avnet counterpart will send you something called a Serialization Information Worksheet. You can use this form to indicate which bytes you want to hold static (ie, the 3 MSBs of your OUI) and which you want to auto-increment/serialize (ie, the 3 LSBs).
Although it doesn't apply in this case, Avnet can also perform this service on the BCM2073xS SIP modules where the EEPROM is internal to the module and thus trickier to program in-system.
I'll get in touch with your Avnet FAE (Adam) to make sure you're set.