- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have a board based on the BCM20732S, which previously worked but now fails to be detected and programmed.
Is it possible that something I did to it corrupted the internal eeprom? What sorts of things could cause this, and is there any way to recover from this?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello idgirod,
We have an "official" document coming out soon but here are some excerpts to get you out of trouble. You can find each of the programming files under the SDK directory as shown below.
Location of the cgs.exe file:
Location of the Chipload.exe file
Location of the 20732_EEPROM.btp file
Using cygwin:
The following procedure converts the cgs file to a hex file:
1. Using command-line interface(eg. Cygwin, cmd.exe), run cgs.exe.
2. Use the following command
a. ./cgs.exe -I <output_file_name.hex> –A 0xFF000000 –B <btp_file.btp> -D <file.hdf>
3. Definitions of parameters:
a. output_file_name.hex – will be the converted hex file.
b. btp_file.btp – btp file for the TAG.
c. input_file.cgs – built cgs file for the application.
d. 0xFF000000 – base address for the EEPROM
e. File.hdf - directories for hdf file
Results of the successful command execution:
Downloading the hex file:
The following procedure downloads the hex file:
1. Using command-line interface, run chipload.exe.
2. Use the following command
a. ./Chipload.exe –BLUETOOLMODE –PORT COM16 –BAUDRATE 115200nfc –MINIDRIVER <minidriver.hex> -CONFIG <output_file_name.hex> -BTP <btp_file.btp> -NODLMINIDRIVER
3. Definitions of parameters:
a. COM16 – connected port.
b. btp_file.btp – btp file for the TAG.
c. Output_file_name.hex – converted hex file.
d. btp_file.btp – btp file for the TAG
Results of the successful hex file download execution:
Let me know if this helps.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello idgirod,
WICED Smart Quick Start Guide - Please see Appendix E in this document to recover the EEPROM:
Appendix E: Recovering a Corrupted WICED Smart Tag
JT
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
How would this apply to the 20732S module? Is there any external way to access the eeprom?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello idgirod,
We have an "official" document coming out soon but here are some excerpts to get you out of trouble. You can find each of the programming files under the SDK directory as shown below.
Location of the cgs.exe file:
Location of the Chipload.exe file
Location of the 20732_EEPROM.btp file
Using cygwin:
The following procedure converts the cgs file to a hex file:
1. Using command-line interface(eg. Cygwin, cmd.exe), run cgs.exe.
2. Use the following command
a. ./cgs.exe -I <output_file_name.hex> –A 0xFF000000 –B <btp_file.btp> -D <file.hdf>
3. Definitions of parameters:
a. output_file_name.hex – will be the converted hex file.
b. btp_file.btp – btp file for the TAG.
c. input_file.cgs – built cgs file for the application.
d. 0xFF000000 – base address for the EEPROM
e. File.hdf - directories for hdf file
Results of the successful command execution:
Downloading the hex file:
The following procedure downloads the hex file:
1. Using command-line interface, run chipload.exe.
2. Use the following command
a. ./Chipload.exe –BLUETOOLMODE –PORT COM16 –BAUDRATE 115200nfc –MINIDRIVER <minidriver.hex> -CONFIG <output_file_name.hex> -BTP <btp_file.btp> -NODLMINIDRIVER
3. Definitions of parameters:
a. COM16 – connected port.
b. btp_file.btp – btp file for the TAG.
c. Output_file_name.hex – converted hex file.
d. btp_file.btp – btp file for the TAG
Results of the successful hex file download execution:
Let me know if this helps.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am still have problems with some devices that no longer program and just noticed your reply here.
What is the difference between using this command line tool vs. what the IDE does when you go through the programming process? It seems like the commands are mostly the same, with the exception of "NODLMINIDRIVER". Is there some reason why using the command line will be likely to work if the IDE programming process fails to detect the chip?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Idgirod,
The command line tool and IDE should be identical.
Have you seen the Crystal Warm-up Issue:Re: BCM20732S module keeps crashing
1 - create a CSG file inside the application folder named app.csg with the content below:
ENTRY "PMU Crystal Warm up Time"
{
"Crystal warm up time" = 5000
}
Let me know if this helps
JT
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
My build includes the crystal warm up time modification, which is required for it to work.
However, once the device gets into this broken-UART state, there is no way to load software on it regardless of the crystal setting. However the previously loaded image would have had the crystal fix.
One thought that occurred to me was if when an error occurs during the HCI programming process, the device then on the next boot fails over to some other built-in "failsafe" boot loader (one that is NOT used when reprogramming from a device with a valid image). If so, could it be that this fail safe boot loader has a problem with the crystal setting that causes it to fail to work correctly?
Based on this theory I tried heating up the chip to see if that helped, but it did not seem to.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The Quick Start Appendix describes holding down the BOOT_ROM switch on the TAG board during reset to put the board into a known state for recovery.
This procedure actually prevents the on-board ARM from being able to access the EEPROM that is on the module. Upon boot, the ARM reads the contents of the EEPROM (and in the case of pressing the button, the read of the actual content is negated due to the switch pulling the internal EEPROM SDA line "high") and since it does not find a valid image, it enters its 'programming' mode.
However, I looked into this previously and determined that asserting VDDIO high when connecting to SDA during boot is not optimal.
SCL and SDA are both open-drains and the internal pull-ups are actually pulling the signal high while the hardware drives it low (i.e. hardware never drives the pin high, but it floats the output pad leaving the pull-up to pull the line high). If you were to put a scope to either of these signals during firmware access, you will see high to low transitions that are very sharp while the low to high transitions will be fairly slow due to the intrinsic RC.
If you connect SCL/SDA to Vdd, when the hardware block drives SDA low, there will be a direct short (though momentary) between Vdd and GND, which is not ideal (even if the recovery works fine). This will happen pretty early during boot process because the ROM always uses 0xA0 as the slave address of the EEPROM and you will be able to see that there are repeated 0s in this sequence (and the shorts) which may cause issues with the supply or the chip itself.
Shorting to GND on the other hand is safer because that's precisely what happens when there is a 0 bit on the bus and there is a 10K pull-up, which will limit the current to something within the max ratings of all components on this line.
The reason recovery works under this scenarion is because the data on the i2C bus is invalid when its shorted to GND. When the ROM tries to read from slave 0xA0, the actual data bytes on the bus are overridden to 0x00, which is not a valid slave. Once this occurs, the ROM immediately gives up on the EEPROM and goes into download mode if uart is also connected.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
When I tried this with my custom board I shorted the pin to ground.
But for my purposes, I am not sure this procedure will help anyway.
I think my device is already in programming mode, but programming mode does not seem to work anymore.
The device responds to the detection request on the HCI UART, but the response is garbled by strange spikes on the serial line.
I put more detail on this in a separate post here: