cancel
Showing results for 
Search instead for 
Did you mean: 

WICED Smart Bluetooth

New Contributor II

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
Reply
1 Solution
Employee

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
Employee

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?

New Contributor II

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
Reply
Employee

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

New Contributor II

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?

Employee

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