Unable to (re) program BCM20736

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

cross mob
Anonymous
Not applicable

I have two boards containing 736 sips that I am unable to program.  I'm pretty sure that hardware is not the problem as I've been working with these for some time now and have always been able to flash them without incident.  I think it is entirely due to firmware as they stopped responding after I flashed a 737 image onto them this morning (I updated to the 2.1.1 sdk and when I created new targets I didn't update the platform string).  The firmware had not been previously tested and I am not confident that it was bug-free.

In any event, would a bad image and/or firmware cause a sip to suddenly stop responding to programming attempts (normal and recovery)?  The rx line is high at power up and it looks like the process is trying to start but the chip never responds.  I am not seeing any advertisements from the board.  We are running the SIP at 1.8V and the chip has power and the reset line is not pulled.

I programmed both boards using the exact same setup so I know they were detected and were accepting commands.

image16177.png

image6326.png

1 Solution

OK, try this sequence:

0. Remove UART connection to PC

1. Short SDA to GND

2. Power up the chip and wait for a couple of seconds or so.

3. Remove SDA to GND short.

4. Connect HCI UART for programming.

5. Try downloading with -NODLMINIDRIVER

View solution in original post

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

Recovery should always work, even if you programmed the wrong FW image into it. Do you have the download log file (should be in the application's build folder, and must be called download.log). You may also want to try getting a more detailed download log. Edit Makefile, look for the recipe 'recover_using_chipload' and then in the command that involes the downloader, add -LOGTO some_file.log. It should now look like this:

$(QUIET)$(call CONV_SLASHES,$(CHIPLOAD_FULL_NAME)) -BLUETOOLMODE -PORT $(UART) -BAUDRATE $(PLATFORM_BAUDRATE) -NODLMINIDRIVER -MINIDRIVER $(SOURCE_ROOT)Platforms/$(PLATFORM_FULL)/$(PLATFORM_MINIDRIVER) -BTP $(SOURCE_ROOT)Platforms/$(PLATFORM_FULL)/$(PLATFORM_BOOTP) -CONFIG build/$(OUTPUT_NAME)/$(OUTPUT_NAME).hex -LOGTO build/$(OUTPUT_NAME)/$(OUTPUT_NAME).log -CHECKCRC -NOVERIFY -DLMINIDRIVERCHUNKSIZE 251 > build/$(OUTPUT_NAME)/download.log 2>&1 && $(ECHO) Recovery complete && $(ECHO_BLANK_LINE) && $(ECHO) $(QUOTES_FOR_ECHO)Application running$(QUOTES_FOR_ECHO) || $(ECHO) $(QUOTES_FOR_ECHO)**** Recovery failed - retry ****$(QUOTES_FOR_ECHO)

And then use the recovery steps from the quick start guide.

Anonymous
Not applicable

No luck.  There something wrong with the serial port as you can see from the traces I included.  The logs confirm this:


2014-09-15@12:44:41.902  Will be downloading 0 bytes of code and 11236 bytes of data using minidriver Platforms/BCM920736TAG_Q32/uart_DISABLE_EEPROM_WP_PIN1.hex

2014-09-15@12:44:41.902  BTP file: Platforms/BCM920736TAG_Q32/20736_EEPROM.btp

2014-09-15@12:44:41.902  The config data is coming from the following files

2014-09-15@12:44:41.902  build/test-BCM920736TAG_Q32-rom-ram-Wiced-release/test-BCM920736TAG_Q32-rom-ram-Wiced-release.hex

2014-09-15@12:44:41.902 Sending bytes to HW:

4 bytes:  01 03 0C 00

2014-09-15@12:44:42.152 ERROR: Failed to execute HCI Reset

I programmed another board with older firmware (using my chipload script) and it went without a hitch.  Tried to program one of the dead boards with the same result. Serial lines responded as expected on working board:

image11044.png

0 Likes

I'd like to see the command line parameters used by chipload. Can you set VERBOSE=1 in your make target and then copy-paste how chipload is being invoked?

0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Attached is folder for my non-ide loader.  test.bat calls chipload:

ChipLoad.exe -BLUETOOLMODE -PORT COM35 -BAUDRATE 115200 -MINIDRIVER uart_DISABLE_EEPROM_WP_PIN1.hex -BTP 20736_EEPROM.btp -CONFIG test-BCM920736TAG_Q32-rom-ram-Wiced-release.hex -LOGTO program.log -CHECKCRC -NOVERIFY -DLMINIDRIVERCHUNKSIZE 251

output is the same:

2014-09-15@13:44:48.221  About to execute DownloadMinidriver command

2014-09-15@13:44:48.221 Sending bytes to HW:

4 bytes:  01 2E FC 00

2014-09-15@13:44:48.471 ERROR:  BluetoolDownloadMinidriver failed!

I don't think the problem is on the PC side.  The chip is just plain 'ol not responding.  This same script/fw works on a non-borked board.

0 Likes

Hmmm.. then its really not in recovery mode. Also try adding add -NODLMINIDRIVER to this command:

ChipLoad.exe -BLUETOOLMODE -PORT COM35 -BAUDRATE 115200 -MINIDRIVER uart_DISABLE_EEPROM_WP_PIN1.hex -BTP 20736_EEPROM.btp -CONFIG test-BCM920736TAG_Q32-rom-ram-Wiced-release.hex -LOGTO program.log -CHECKCRC -NOVERIFY -DLMINIDRIVERCHUNKSIZE 251 -NODLMINIDRIVER

0 Likes
Anonymous
Not applicable

Same result with NODLMINIDRIVER:

2014-09-15@14:23:41.439  Will be downloading 0 bytes of code and 10547 bytes of data using minidriver uart_DISABLE_EEPROM_WP_PIN1.hex

2014-09-15@14:23:41.439  BTP file: 20736_EEPROM.btp

2014-09-15@14:23:41.439  The config data is coming from the following files

2014-09-15@14:23:41.439  test-BCM920736TAG_Q32-rom-ram-Wiced-release.hex

2014-09-15@14:23:41.439 Sending bytes to HW:

4 bytes:  01 03 0C 00

2014-09-15@14:23:41.689 ERROR: Failed to execute HCI Reset

I agree, it appears that either it's not in recovery mode or that recovery mode was somehow compromised.

0 Likes

OK, try this sequence:

0. Remove UART connection to PC

1. Short SDA to GND

2. Power up the chip and wait for a couple of seconds or so.

3. Remove SDA to GND short.

4. Connect HCI UART for programming.

5. Try downloading with -NODLMINIDRIVER

0 Likes
Anonymous
Not applicable

I had put this problem aside but ran into it again yesterday.  Thought I had killed 3 boards but then remembered I had started this thread and hadn't followed up.  Tried above procedure and was able to recover all 3 boards.  Not sure what happened to my original but I'm confident that when I find it I'll be able to recover it as well.  I did not need to program with -NODLMINIDRIVER.  Just updating from the IDE was sufficient.

0 Likes
Anonymous
Not applicable

One more data point...

I got impatient and I flashed a third unit with the same firmware as the first two but with the correct platform in the target name.  Board was found, flashed and booted up just fine (whew!).  Repeated with same board after cycling power and again was able to flash and run the firmware.  Board is from same batch as the first two so there should be no hardware differences.

Having the wrong platform name seems to be the culprit.  I'm still interested in this as I'd like to recover the 2 borked boards if at all possible.