7 Replies Latest reply on Feb 28, 2014 10:08 AM by ArvindS_76

    Two dev boards have same MAC address

    legic_1490776

      We have two of the 20732 dev boards and they appear to have the same mac address: 20732A0C0FFE

      This may be confusing things when we run them at the same time. 

      Is there a way to configure the MAC address on these boards?

        • 1. Re: Two dev boards have same MAC address
          ArvindS_76

          You can upgrade to the new 1.1 SDK and it will program some of the BD_ADDR bytes with random values. Or you can edit Platforms/BCM920732ATAG_Q32/20732_EEPROM.btp file and set DLConfigBD_ADDRBase to the value you want. To use random address instead:

           

          DLConfigBD_ADDRBase = "20732A0*****"

           

          where every * will be replaced with a random value.

          • 2. Re: Two dev boards have same MAC address
            legic_1490776

            What is the recommended way to configure the MAC address in a production line?  Does this need to be coded into the eeprom image, or can it be set at runtime during a manufacture test process?

            • 3. Re: Re: Two dev boards have same MAC address

              hdf_file.PNG Hello Idgirod,

               

              The cgs.exe in the SDK can enable the same BD_ADDR programming mentioned above but in the manufacturing process.

               

              Here is the locationof the cgs.exe file:

              cgs_exe_location.PNG

               

              You will also need the ChipLoad.exe file located here:

              WICED\WICED-Smart-SDK-1.1.0\WICED-Smart-SDK\Tools\ChipLoad\Win32

               

              ChipLoad_exe_location.PNG

               

              Here are the set of instructions for now - I will post an App note on the forum and send you the link.

               

              2. Downloading the FW:


              I. Required tools and files:
                     1. Cgs.exe
                     2. Chipload.exe
                     3. Cgs file of the build application.
                     4. btp file.

              20732_EEPROM_btp_file.PNG
                     5. hdf file.

              hdf_file.PNG
                     6. Minidriver - The minidriver file is in the SDK @Platforms/BCM920732TAG_Q32/uart_DISABLE…hex

               

              II. Converting cgs file to hex file:
                     1. Using command-line interface(eg. Cygwin, cmd.exe), run cgs.exe
                     2. Use the following command:

                           ./cgs.exe -I <output_file_name.hex> –A 0xFF000000 –B <btp_file.btp> -D <file.hdf> <input_file.cgs>

                            output_file_name.hex – will be the converted hex file.
                            btp_file.btp – btp file for the TAG.
                            input_file.cgs – built cgs file for the application.
                            0xFF000000 – base address for the EEPROM.
                            File.hdf - directories for hdf file

              Converting_cgs_to_hex_file.jpg


              III. Downloading the hex file:
                     1. Using command-line interface, run chipload.exe
                     2. Use the following command:

                      ./Chipload.exe –BLUETOOLMODE –PORT COM16 –BAUDRATE 115200nfc –MINIDRIVER
                      <minidriver.hex> -CONFIG <output_file_name.hex> -BTP <btp_file.btp> -NODLMINIDRIVER

                       COM16 – connected port
                       Minidriver.hex – minidriver for the TAG
                       Output_file_name.hex – converted hex file.
                       btp_file.btp – btp file for the TAG

              ChipLoad_exe_Output.jpg

              And then you can see the success:

               

              Converting_cgs_to_hex_file_Success.jpg

              Again, I will post a link to an App note.

              • 4. Re: Two dev boards have same MAC address
                legic_1490776

                Hi JT,

                 

                Thank you for the detailed explanation.

                 

                Three further questions:

                 

                1. Our sales rep thought it was possible to get the modules pre-loaded with firmware so as to avoid having to load the firmware during manufacturing.  However it would seem that programming the MAC requires essentially generating a custom .hex file, so maybe the rep was just confused?

                 

                2. If we implement OTA upgrade, can a new FW be loaded without blowing away the previously configured MAC address or does the FW image need to be customized?

                 

                3. How are MAC addresses allocated - are there address spaces for these parts or do we get them from some global authority? 

                 

                Thanks!

                • 5. Re: Two dev boards have same MAC address

                  1. Our sales rep thought it was possible to get the modules pre-loaded with firmware so as to avoid having to load the firmware during manufacturing.  However it would seem that programming the MAC requires essentially generating a custom .hex file, so maybe the rep was just confused?

                   

                  [JT] - When you build using the SDK, you will see two hex files.  However, what you download in the factory is <app_name>-<platform>-rom-ram-Wiced-release.hex (and this is what the SDK does when your target is ‘download’ or ‘recover’).

                   

                  So this is called the factory image and this includes the BD_ADDR.

                   

                  During mass production, you should use the .cgs file + cgs.exe to generate one unique hex file per device and then use chipload.exe to download this to the NV memory.

                   

                  The reason you need to do it this way is because each device needs a unique BD_ADDR and the BD_ADDR is embedded in the hex file by cgs.exe when the .hex is generated from the .cgs.

                   

                  2. If we implement OTA upgrade, can a new FW be loaded without blowing away the previously configured MAC address or does the FW image need to be customized?

                   

                  [JT] - OTA updates always preserve the BD_ADDR and pairing keys – only the FW/App and patch code will be replaced.

                   

                  The SDK always generates a separate set of files (.ota.hex and .ota.bin) that are to be used for the OTA update (the Windows OTA update peer app expects this .bin file) – this of course assumes that you already included the code in ws_upgrade.c and implemented the hooks for it in the app, without which the .ota.* files are of no use.

                   

                  3. How are MAC addresses allocated - are there address spaces for these parts or do we get them from some global authority? 

                   

                  [JT] - The assignment of the MAC Addresses is done by the Bluetooth SIG - Bluetooth Site Maintenance (But they are doing maintenance today) - Please visit the site tomorrow when it's up.

                   

                  JT

                  • 6. Re: Two dev boards have same MAC address
                    legic_1490776

                    Thank you, JT - I appreciate the support!

                    • 7. Re: Two dev boards have same MAC address
                      ArvindS_76

                      You don't have to edit the .btp file to change BD_ADDR when generating unique .hex files during mass production. cgs.exe also accepts an override option that can override any configuration in the .btp file, including the BD_ADDR configuration.

                       

                      So, from JT's step II Converting cgs file to hex file:

                             1. Using command-line interface(eg. Cygwin, cmd.exe), run cgs.exe

                             2. Use the following command:

                                   ./cgs.exe -I <output_file_name.hex> -O DLConfigBD_ADDRBase:207321234567 –A 0xFF000000 –B <btp_file.btp> -D <file.hdf> <input_file.cgs>

                       

                      will set the device address to 207321234567 regardless of what is there in the .btp file. Downloading to different devices during mass production will then need two steps:

                       

                      1. Generate the .hex for the device from the .cgs, override the device address using the -O option

                      2. Use chipload.exe to load the .hex generated in step 1.