How to program BCM20736 without changing MAC Address

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

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?

1 Solution

andrew997

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

View solution in original post

0 Likes
25 Replies
asridharan
Employee
Employee
10 comments on KBA 5 comments on KBA First comment on KBA

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).

Anonymous
Not applicable

Could you explain the difference for when the NV is an EEPROM and not for SPI Serial Flash? Can we program it multiple times?

0 Likes

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.

Anonymous
Not applicable

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?

0 Likes

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.

0 Likes
Anonymous
Not applicable

Do you have any code example I could look at?

0 Likes

The syntax to use cgs.exe and chipload.exe are described in this blog:

BD_ADDR: Changing BCM20737 Board Address for Production

0 Likes
Anonymous
Not applicable

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?

0 Likes

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).

andrew997


Anonymous
Not applicable

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

0 Likes
Anonymous
Not applicable

Ethan

Let me check on this tomorrow

JT

0 Likes
Anonymous
Not applicable

Hello Ethan,

  1. 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.
  2. Can you send us a picture of your make file and the option commands?  They should work.
  3. We are a bit confused on your use of the Serial FLASH on the second SPI port?
  4. Before you build again, you should hit the clean Make Target.

Thanks

JT

0 Likes
Anonymous
Not applicable

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.

0 Likes
Anonymous
Not applicable

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

pastedImage_1.png

Thanks

JT

0 Likes
Anonymous
Not applicable

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?

0 Likes

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?

0 Likes
Anonymous
Not applicable

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?

0 Likes

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?

BD_ADDR: Changing BCM20737 Board Address for Production

andrew997

0 Likes
Anonymous
Not applicable

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?

andrew997

0 Likes

Can you furnish me a name, email and contact number of your Chinese colleague?

0 Likes
Anonymous
Not applicable

boont

I sent to your inbox

0 Likes

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.

0 Likes
Anonymous
Not applicable

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:

pastedImage_6.png

Note:  I'm using a WICED Sense device for my hardware (BCM20737S SIP).

0 Likes

andrew997

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.

0 Likes

andrew997

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

0 Likes