- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Glad to hear that. Verbose is supposed to reveal more log details but we shall stay as it is for now.