- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi all,
Per the discussion here on preserving the BD_ADDR on each subsequent programming of the part: How to program BCM20736 without changing MAC Address
I'm sorry to jump in late into this discussion. I'm using Mac OS X, and the BCM920737TAG board. I mainly use the command line:
./make <app>-BCM920737TAG_Q32 download
to download code to the board, and don't use the IDE. Following this thread, I added a new target to the Makefile for download, and included the -NOERASE flag to it:
download_using_chipload_no_erase:
$(QUIET)$(ECHO_BLANK_LINE)
$(QUIET)$(eval UART:=$(shell $(CAT) < com_port.txt))
$(QUIET)$(if $(UART), \
$(ECHO) Downloading application leaving EEPROM intact... && $(call CONV_SLASHES,$(CHIPLOAD_FULL_NAME)) -BLUETOOLMODE -PORT $(UART) -BAUDRATE $(PLATFORM_BAUDRATE) -MINIDRIVER $(SOURCE_ROOT)Platforms/$(PLATFORM_FULL)/$(PLATFORM_MINIDRIVER) -NOERASE -BTP $(SOURCE_ROOT)Platforms/$(PLATFORM_FULL)/$(PLATFORM_BOOTP) -CONFIG build/$(OUTPUT_NAME)/$(OUTPUT_NAME).hex -CHECKCRC -NOVERIFY -DLMINIDRIVERCHUNKSIZE 251 > build/$(OUTPUT_NAME)/download.log 2>&1 \
&& $(ECHO) Download complete && $(ECHO_BLANK_LINE) && $(ECHO) $(QUOTES_FOR_ECHO)Application running$(QUOTES_FOR_ECHO) \
|| $(ECHO) $(QUOTES_FOR_ECHO)****Download failed - Press the reset button on the device and retry ****$(QUOTES_FOR_ECHO), \
$(ECHO) Download failed. This version of the SDK only supports download to BCM20736A1 and BCM20737A1 devices)
Note that the other change suggested by arvinds (adding -O DLConfigFixedHeader:0 to create_ota_image) is already in the Makefile.
However, when I change the line
DLConfigBD_ADDRBase = "20737A000002" |
in the 20737_EEPROM.btp file, it does indeed erase the old value and replace it with the new value. So, it doesn't work as suggested in this thread. Any help is greatly appreciated. I would like to find a way to download code to different boards without having to change the .btp file each time.
Thanks,
Arvind
Solved! Go to Solution.
- Labels:
-
Manufacturing and Test
-
SDK 2.X
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
To explain a little on my approach. I changed the base address when I carried out the cgs conversion to hex. In doing so, I make sure that those sectors where the BD address is stored are not touched during the re-write. In fact, if you opened up the HEX files (one with -O DLConfigFixedHeader:0 and the other without) and compared them, you will understand what I meant. For your thoughts.
Did you manage to sort it out? arvindraghavan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I used the cgs-and-chipload method in Windows though. I did the following without changing the btp file.
cgs.exe -I mysensor.hex -O DLConfigBD_ADDRBase:207777****** -A 0xFF000000 -B 20736_EEPROM.btp -D . A_20736A1-hello_sensor-rom-ram-spar.cgs
On the entry for the bd address, you may either specify a known address, or partial-random, like above.
Is this what you are looking for?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for your response, but this is not exactly what I want. I apologize, I was a little imprecise in my post. Here is my situation. I have about half a dozen boards that I'm testing. As I make changes to the firmware, I want to be able to download the new code to all these boards without having to keep track of the MAC ID on each board. The "-NOERASE" option, and the original question in the other thread How to program BCM20736 without changing MAC Address seemed to be on the right track.
Note that on MAC OS X, it is possible to simply use a flag BT_DEVICE_ADDRESS=xxxxxxxxxxxx with the make command to achieve what you suggest in your post-- no changes necessary, this is already available. Example usage (from the Makefile):
$> make proximity-BCM920737TAG_Q32 download UART=COMx BT_DEVICE_ADDRESS=20736A1C0FFE
However, use of this option requires that we type in the MAC address for each board we want to program. When simply updating the firmware, there should be a simpler option to leave the MAC address unchanged. What does the "-NOERASE" option do?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The -NOERASE is needed to tell chipload not to erase the EEPROM, or it will wipe out the BD_ADDR you already programmed. What you need is to tell the cgs conversion utility to do is to not generate a new BD_ADDR entry when converting it to a hex. So, when invoking cgs, you should add -O DLConfigFixedHeader:0 not only to the ota image recipe but even to your convert_cgs_to_hex recipe in the makefile. Of course, this assumes that you successfully programmed the device without these changes to the makefile at least once (with the BD_ADDR).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks, arvinds. I updated the Makefile so that the convert_cgs_to_hex also has the -O DLConfigFixedHeader:0 option. In addition, download_using_chipload has the -NOERASE option. Note that create_ota_image already had the -O DLConfigFixedHeader:0 option.
However, something seems seriously wrong with this Makefile. The first time I tried to download my code, it seemed to succeed, but my application did not come up as expected. Next, I removed this option and went back to the original Makefile, and I'm not able to download code anymore-- either with or without these modifications. Any idea what went wrong? Here is what I see:
--------------------------------------------------------------------------------
Patches start at 0x00204568 (RAM address)
Patches end at 0x0020537C (RAM address)
Application starts at 0x00204FD0 (RAM address)
Application ends at 0x00205BB8 (RAM address)
Patch size (including reused RAM) 3604 bytes
Patch size 2664 bytes
Application size 3048 bytes
------
Total RAM footprint 5712 bytes (5.6kiB)
--------------------------------------------------------------------------------
Converting CGS to HEX...
Conversion complete
Creating OTA images...
Conversion complete
OTA image footprint in NV is 7711 bytes
Detecting device...
Device found
Downloading application leaving EEPROM intact...
****Download failed - Press the reset button on the device and retry ****
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Arvind,
You may have corrupted the EEPROM and may need to do a recover:
WICED Smart Quick Start Guide (SDK 2.x and TAG3 Board)
Page 25
Thanks
JT
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I suspected I'd have to do an EEPROM recovery, but it was the end of a long day, so I was planning to do it tomorrow. It is pretty much the only option when all else fails 🙂
I'll go back and double check my Makefile one more time to see if I applied the flags suggested by arvinds correctly. Can anyone else verify the suggested solution works on their end?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sorry j.t, but I think I have the Makefile exactly as suggested by arvinds, but it corrupts the EEPROM for some reason. The suggestion is essentially to update 3 targets:
convert_cgs_to_hex: add the option -O DLConfigFixedHeader:0
create_ota_imate: add the option -O DLConfigFixedHeader:0
download_using_chipload: add the option -NOERASE
To be completely certain, I made these changes this time in the most straighforward way by directly adding them to the targets. Note that create_ota_image already has this option, so no change needed. However, this STILL corrupts the EEPROM. So I think we still don't have a solution to this problem. Also BTW, boont I think the topic of this thread should be reverted to the original-- "How to program without changing MAC address".
Here are my specific changes to the Makefile for your reference:
diff --git a/WICED-Smart-SDK-2.2.0/Makefile b/WICED-Smart-SDK-2.2.0/Makefile
index 1a8c1d6..74edc71 100644
--- a/WICED-Smart-SDK-2.2.0/Makefile
+++ b/WICED-Smart-SDK-2.2.0/Makefile
@@ -147,7 +147,7 @@ find_com_port:
convert_cgs_to_hex:
$(QUIET)$(ECHO_BLANK_LINE)
$(QUIET)$(ECHO) Converting CGS to HEX...
- $(QUIET)$(call CONV_SLASHES,$(CGS_FULL_NAME)) -D $(SOURCE_ROOT)Platforms/$(PLATFORM_FULL) $(BT_DEVICE_ADDRESS_OVERRIDE) -A $(PLATFORM_STORAGE_BASE_ADDR) -B $(SOURCE_ROOT)Platforms/$(PLATFORM_FULL)/$(PLATFORM_BOOTP) -I build/$(OUTPUT_NAME)/$(OUTPUT_NAME).hex --cgs-files build/$(OUTPUT_NAME)/$(BLD)-$(APP)-$(BASE_LOC)-$(SPAR_LOC)-spar.cgs > build/$(OUTPUT_NAME)/cgs2hex.log 2>&1 && $(ECHO) Conversion complete || $(ECHO) $(QUOTES_FOR_ECHO)**** Conversion failed ****$(QUOTES_FOR_ECHO)
+ $(QUIET)$(call CONV_SLASHES,$(CGS_FULL_NAME)) -D $(SOURCE_ROOT)Platforms/$(PLATFORM_FULL) $(BT_DEVICE_ADDRESS_OVERRIDE) -A $(PLATFORM_STORAGE_BASE_ADDR) -B $(SOURCE_ROOT)Platforms/$(PLATFORM_FULL)/$(PLATFORM_BOOTP) -O DLConfigFixedHeader:0 -I build/$(OUTPUT_NAME)/$(OUTPUT_NAME).hex --cgs-files build/$(OUTPUT_NAME)/$(BLD)-$(APP)-$(BASE_LOC)-$(SPAR_LOC)-spar.cgs > build/$(OUTPUT_NAME)/cgs2hex.log 2>&1 && $(ECHO) Conversion complete || $(ECHO) $(QUOTES_FOR_ECHO)**** Conversion failed ****$(QUOTES_FOR_ECHO)
convert_cgs_to_hex_for_direct_load:
$(QUIET)$(ECHO_BLANK_LINE)
@@ -166,7 +166,7 @@ download_using_chipload:
$(QUIET)$(ECHO_BLANK_LINE)
$(QUIET)$(eval UART:=$(shell $(CAT) < com_port.txt))
$(QUIET)$(if $(UART), \
- $(ECHO) Downloading application... && $(call CONV_SLASHES,$(CHIPLOAD_FULL_NAME)) -BLUETOOLMODE -PORT $(UART) -BAUDRATE $(PLATFORM_BAUDRATE) -MINIDRIVER $(SOURCE_ROOT)Platforms/$(PLATFORM_FULL)/$(PLATFORM_MINIDRIVER) -BTP $(SOURCE_ROOT)Platforms/$(PLATFORM_FULL)/$(PLATFORM_BOOTP) -CONFIG build/$(OUTPUT_NAME)/$(OUTPUT_NAME).hex -CHECKCRC -NOVERIFY -DLMINIDRIVERCHUNKSIZE 251 > build/$(OUTPUT_NAME)/download.log 2>&1 \
+ $(ECHO) Downloading application... && $(call CONV_SLASHES,$(CHIPLOAD_FULL_NAME)) -BLUETOOLMODE -PORT $(UART) -BAUDRATE $(PLATFORM_BAUDRATE) -MINIDRIVER $(SOURCE_ROOT)Platforms/$(PLATFORM_FULL)/$(PLATFORM_MINIDRIVER) -BTP $(SOURCE_ROOT)Platforms/$(PLATFORM_FULL)/$(PLATFORM_BOOTP) -NOERASE -CONFIG build/$(OUTPUT_NAME)/$(OUTPUT_NAME).hex -CHECKCRC -NOVERIFY -DLMINIDRIVERCHUNKSIZE 251 > build/$(OUTPUT_NAME)/download.log 2>&1 \
&& $(ECHO) Download complete && $(ECHO_BLANK_LINE) && $(ECHO) $(QUOTES_FOR_ECHO)Application running$(QUOTES_FOR_ECHO) \
|| $(ECHO) $(QUOTES_FOR_ECHO)****Download failed - Press the reset button on the device and retry ****$(QUOTES_FOR_ECHO), \
$(ECHO) Download failed. This version of the SDK only supports download to BCM20736A1 and BCM20737A1 devices)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
i'm doing this in Windows using the cgs-and-chipload method on a tag3.
1) I used the recovery method to clear my tag3 with a new bd address.
proximity-BCM920737TAG_Q32 BT_DEVICE_ADDRESS=AAAAAAAAAAAA recover UART=com13
The app is up and running and I can verify it via "wiced explorer" on my phone.
2) I built the hello_sensor app in my SDK and extract the cgs and btp file into a working folder. I did the following
cgs.exe -I mysensor.hex -O DLConfigFixedHeader:0 -A 0xFF000580 -B 20736_EEPROM.btp --cgs-files A_20736A1-hello_sensor-rom-ram-spar.cgs
3) I then use the chipload to download the hex file.
chipload.exe -BLUETOOLMODE -BAUDRATE 115200nfc -PORT COM13 -MINIDRIVER uart_DISABLE_EEPROM_WP_PIN1.hex -NOERASE -CONFIG mysensor.hex -DLMINIDRIVERCHUNKSIZE 251 -BTP 20736_EEPROM.btp
4) I now have a working hello_sensor app running with the original address.
Check it out.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks, but we can't switch to Windows. It looks like there may be some issue with the utilities used on OS X.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
To explain a little on my approach. I changed the base address when I carried out the cgs conversion to hex. In doing so, I make sure that those sectors where the BD address is stored are not touched during the re-write. In fact, if you opened up the HEX files (one with -O DLConfigFixedHeader:0 and the other without) and compared them, you will understand what I meant. For your thoughts.
Did you manage to sort it out? arvindraghavan