BCM20732S refuses to program

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

cross mob
legic_1490776
Level 5
Level 5
25 likes received 10 likes received First like received

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?

0 Likes
1 Solution
Anonymous
Not applicable

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:

cgs_exe_location.PNG

Location of the Chipload.exe file

ChipLoad_exe_location.PNG

Location of the 20732_EEPROM.btp file

20732_SFLASH_btp_file.PNG

Using cygwin:

cygwin_directory.png

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:

Converting_cgs_to_hex_file.jpg

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:

Converting_cgs_to_hex_file_Success.jpg

Let me know if this helps.

View solution in original post

8 Replies
Anonymous
Not applicable

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

0 Likes

How would this apply to the 20732S module?  Is there any external way to access the eeprom?

0 Likes
Anonymous
Not applicable

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:

cgs_exe_location.PNG

Location of the Chipload.exe file

ChipLoad_exe_location.PNG

Location of the 20732_EEPROM.btp file

20732_SFLASH_btp_file.PNG

Using cygwin:

cygwin_directory.png

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:

Converting_cgs_to_hex_file.jpg

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:

Converting_cgs_to_hex_file_Success.jpg

Let me know if this helps.

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?

0 Likes
Anonymous
Not applicable

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

0 Likes

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.

0 Likes

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.

0 Likes

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:

BCM20732S based boards sometimes develop UART failure

0 Likes