Can't reprogram BCM20736s

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

cross mob
JaJo_1331951
Level 1
Level 1
First like received

My company is currently having an issues with quite a few of our devices that use the BCM20736s BLE controller. The controller on each device was programmed one time successfully. After we discovered that the radios were not communicating, wireless or UART via traces, we attempted to reprogram the controller and failed.

These devices were programmed via the WICED IDE. The make target used was mistakenly for the 20737 platform instead of the 20736 platform. The crystal warm up time of the 20737 platform was left at the default value of 2800.

I have attempted to recover the radios using the following procedure with no success:

Power off the device

Short SDA to GND

Connect the HCI UART to the PC

Power up the device

Reset the controller for ~3s

Disconnect SDA from GND

Attempt to program by replacing 'download' with 'recover' in the make target. (I've also tried using Chipload.exe using -nodlminidriver)

All of these devices appear to function when made with the 20736 platform with the crystal warm up time set to 5000.

Is there anyway I may be able to salvage these chips?

0 Likes
1 Solution

The key point here was to disable the eeprom so that the controller can boot from its ROM. You may

tweak a little by doing the following:

1) short the SDA to ground

2) power up and wait 3s

3) remove the short

4) hooked up HCI connection and perform recovery

As to the termination during the DL process, that's another story...

Can you provide the download log with VERBOSE=1 turn on?

Just so we are on the right page, are you doing all these using the FTDI cable connected directly between your

product board and PC, without the tag3 board anywhere?

View solution in original post

5 Replies
BoonT_56
Employee
Employee
500 likes received 250 likes received 100 likes received

I see that you did a reset after you power up. I'm not sure whether will it have any effect. Previously

I recommended the following:

0. Connect HCI UART connection to PC.

1. Short SDA to GND

2. Power up the chip and wait for 3s

3. Remove SDA to GND

4. Try downloading with -NODLMINIDRIVER.

The above will disable the eeprom upon power-up and the module will continue to boot its defaults from ROM. Let me know how the above fan out.

What is your programming cable? Is it a 3.3V or 1.8V type?

I'm currently using a 3.3V FTDI cable (TTL-232R-3V3).

Recovery is getting further now. It no longer fails immediately but instead the DL terminates with an error during the erasing process. This behavior is similar to what happens if the SDA line is shorted to ground during programming.

0 Likes

The key point here was to disable the eeprom so that the controller can boot from its ROM. You may

tweak a little by doing the following:

1) short the SDA to ground

2) power up and wait 3s

3) remove the short

4) hooked up HCI connection and perform recovery

As to the termination during the DL process, that's another story...

Can you provide the download log with VERBOSE=1 turn on?

Just so we are on the right page, are you doing all these using the FTDI cable connected directly between your

product board and PC, without the tag3 board anywhere?

The method you described in your first response worked. Recovery was successful if I programmed the chip through WICED instead of using the setup described in:

Programming the TAG2/TAG3 Board using command line tools

I'll have to check that setup for mistakes. Would the verbose download log still be of any use to you?

Glad to hear that. Verbose is supposed to reveal more log details but we shall stay as it is for now.