- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, we have a set of BCM20736 parts that all have different MAC address, however, every time we program them using the WICED Smart IDE, the MAC address gets overwritten and then they are all the same. Is there a way to program the firmware WITHOUT overwriting the MAC address?
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
I worked on the tag3 and have no issue with the following:
1) cgs.exe -I mysensor.hex -A 0xFF000000 -B 20737_EEPROM.btp -D . A_20736A1-hello_sensor-rom-ram-spar.cgs
2) chipload.exe -BLUETOOLMODE -BAUDRATE 115200nfc -PORT COM13 -MINIDRIVER uart_DISABLE_EEPROM_WP_PIN1.hex -CONFIG mysensor.hex -DLMINIDRIVERCHUNKSIZE 251 -BTP 20737_EEPROM.btp -LOGTO chipload.log
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Edit the download_using_chipload recipe in your <SDK>/Makefile and add two new parameters** to the call to chipload: -O DLConfigFixedHeader:0 -NOERASE
**Edited to include a second parameter. This method can be used only when the NV is an EEPROM and not for SPI Serial Flash (which will need to be programmed the way the SDK does right now).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Could you explain the difference for when the NV is an EEPROM and not for SPI Serial Flash? Can we program it multiple times?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You can program both multiple times (you should see the data sheet for the part you are using for what the manufacturer claims to be the max).
Serial flashes always need to be erased before writing (because you can flip 1 bits to 0 with a simple write, but to convert a 0 to a 1, the entire page/sector/block/chip needs to be erased first before the write). An EEPROM does not need this.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, I can program it if I leave out -O DLConfigFixedHeader:0, for example if the file has:
$(ECHO) Downloading application... && $(call CONV_SLASHES,$(CHIPLOAD_FULL_NAME)) -NOERASE -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 \ |
It will work. However if I put
$(ECHO) Downloading application... && $(call CONV_SLASHES,$(CHIPLOAD_FULL_NAME)) -O DLConfigFixedHeader:0 -NOERASE -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 \ |
The download will fail. Am I messing up the syntax here?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Argh, sorry, the -O DLConfigFixedHeader:0 parameter applies to cgs.exe, not chipload.exe. Change recipe convert_cgs_to_hex and add this to the call to cgs{.exe}. The -NOERASE parameter still applies to chipload.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Do you have any code example I could look at?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The syntax to use cgs.exe and chipload.exe are described in this blog:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think my board uses a serial flash instead of an EEPROM. Is there a different way to program this board without overwriting the MAC address?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I thought you were using a SIP module with onboard NVRAM (EEPROM). Do you have serial flash attached to the second SPI as well?
I agree with boont in the other debug thread that it may make sense to back up a few steps and confirm your application programs/runs on the TAG3 board using the SDK first (command line tools introduce alot of complexity), then slowly transition to debug on your custom board, using command line tools as custom designs inherantly introduce alot more variables, many of which I introduced at the beginning of this thread: Re: BCM20736S Download Failed
Note that this blog shows how to setup the serial flash on the TAG3 board if that is of interest (uses the SoC, not the SIP module): TAG3 Serial Flash Configuration
Related to your question about programming.
The BD_ADDR: Changing BCM20737 Board Address for Production contains instructions, syntax and a link to programming utilities that can be used for this purpose (script could automate what arvinds explained previously (-O DLConfigFixedHeader:0).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We just did an update with both -NOERASE option and -O DLConfigFixedHeader:0 and the MAC address is still being overwritten. Are we missing something? We edited the Makefile in the SDK with these two options in create_ota_image and download_using_chipload
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ethan
Let me check on this tomorrow
JT
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Ethan,
- We spoke to the developers and they informed us that you must have built your application successfully once in order for the option commands to work.
- Can you send us a picture of your make file and the option commands? They should work.
- We are a bit confused on your use of the Serial FLASH on the second SPI port?
- Before you build again, you should hit the clean Make Target.
Thanks
JT
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi j.t.
1. I can't build it over here but our guys in China can so I sent them the updated makefile
2. Here is a cut of the text from the Makefile:
create_ota_image:
$(QUIET)$(ECHO_BLANK_LINE)
$(QUIET)$(ECHO) Creating OTA images...
$(QUIET)$(call CONV_SLASHES,$(CGS_FULL_NAME)) -D $(SOURCE_ROOT)Platforms/$(PLATFORM_FULL) -O DLConfigFixedHeader:0 -B $(SOURCE_ROOT)Platforms/$(PLATFORM_FULL)/$(PLATFORM_BOOTP) -I build/$(OUTPUT_NAME)/$(OUTPUT_NAME).ota.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) **** Conversion failed ****
$(QUIET)$(call CONV_SLASHES,$(HEX_TO_BIN_FULL_NAME)) build/$(OUTPUT_NAME)/$(OUTPUT_NAME).ota.hex build/$(OUTPUT_NAME)/$(OUTPUT_NAME).ota.bin
$(QUIET)$(call CONV_SLASHES,$(PERL)) -e '$$s=-s "build/$(OUTPUT_NAME)/$(OUTPUT_NAME).ota.bin";printf "OTA image footprint in NV is %d bytes",$$s;'
$(QUIET)$(ECHO_BLANK_LINE)
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) -NOERASE -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) 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)
3. I was mistaken about the serial flash, sorry.
4. I will have them clean the target.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ethan,
Have you tried to do a recovery on the device using the SDK?
WICED Smart Quick Start Guide (SDK 2.1 and TAG3 Board) - Page 27 of 28
Thanks
JT
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi JT,
I can't do recovery at this time here. I get an error that HCI_RESET could not be executed.
Would recovery help my guys in China be able to program without overwriting the MAC address? I put those two options in the Makefile I posted above, I wonder why it still overwrites the MAC address?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can I check with you the following:
1) Are you using a flash or eeprom?
2) How did you download your apps onto the storage? by tag3 or a customized jig?
In parallel, are your China colleagues being currently supported by any Broadcom reps in their area?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Boont,
1) We are using the BCM29736 part from Broadcom, as I understand it, we are using the EEPROM on this part.
2) We use an FTDI board and cable to upload the firmware. It works fine to update the firmware.
3) We are not currently being supported by the Broadcom reps in China. Could you please put us in touch with the Shenzhen China reps and any reps in the Silicon Valley?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I do not have the right asset in ShenZhen right now. All the information related to downloading during production are documented in the below blog. I can only advise you to test out the downloading process on tag3 before migrating to your actual HW.
Who is supplying you the 20736?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks boont,
We are following the instructions found in BD_ADDR: Changing BCM20737 Board Address for Production
However, we are running into the problem described here:
Setting Random MAC address bricks board, why?
Could you please have a look?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can you furnish me a name, email and contact number of your Chinese colleague?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Ethan for the email. Actually I was hoping that someone could actually look at your HW in ShenZhen but your colleague is with you now in US. At the mean time, Andrew is still your best bet in your time zone.
I am going to migrate to the new SDK version and verify some of the process described in here.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi all,
I'm having issues with using these cgs and chipload options myself.
Starting with the .RAR archive posted to the blog on changing BD_ADDRs, I modified the batch file to use the following commands (with the intention of not over-writing the BD_ADDR stored in the EEPROM):
cgs.exe -D . -O DLConfigFixedHeader:0 -A 0xFF000000 -B 20737_EEPROM.btp -I output.hex --cgs-files A_20736A1-hello_sensor-rom-ram-spar.cgs
Chipload.exe -BLUETOOLMODE -PORT %1 -BAUDRATE 115200 -MINIDRIVER uart_DISABLE_EEPROM_WP_PIN1.hex -BTP 20737_EEPROM.btp -CONFIG output.hex -CHECKCRC -NOVERIFY -DLMINIDRIVERCHUNKSIZE 251 -NOERASE
Chipload successfully downloads the minidriver but after that it doesn't appear to actually program anything. The process happens very quickly, unlike the standard script where Chipload takes several seconds to download the new code. Here's the console output:
Note: I'm using a WICED Sense device for my hardware (BCM20737S SIP).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Please add -LOGTO chipload.log to your call to chipload.exe and try again. This will produce a more detailed log in chipload.log that you can attach to this discussion. You can also try to use Portmon to monitor data in either direction over the COM port you are using for the download.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I worked on the tag3 and have no issue with the following:
1) cgs.exe -I mysensor.hex -A 0xFF000000 -B 20737_EEPROM.btp -D . A_20736A1-hello_sensor-rom-ram-spar.cgs
2) chipload.exe -BLUETOOLMODE -BAUDRATE 115200nfc -PORT COM13 -MINIDRIVER uart_DISABLE_EEPROM_WP_PIN1.hex -CONFIG mysensor.hex -DLMINIDRIVERCHUNKSIZE 251 -BTP 20737_EEPROM.btp -LOGTO chipload.log