9 Replies Latest reply on Oct 22, 2014 10:16 AM by jora_1327726

    Unable to (re) program BCM20736

    jora_1327726

      I have two boards containing 736 sips that I am unable to program.  I'm pretty sure that hardware is not the problem as I've been working with these for some time now and have always been able to flash them without incident.  I think it is entirely due to firmware as they stopped responding after I flashed a 737 image onto them this morning (I updated to the 2.1.1 sdk and when I created new targets I didn't update the platform string).  The firmware had not been previously tested and I am not confident that it was bug-free.

       

      In any event, would a bad image and/or firmware cause a sip to suddenly stop responding to programming attempts (normal and recovery)?  The rx line is high at power up and it looks like the process is trying to start but the chip never responds.  I am not seeing any advertisements from the board.  We are running the SIP at 1.8V and the chip has power and the reset line is not pulled.

       

      I programmed both boards using the exact same setup so I know they were detected and were accepting commands.

       

      image16177.png

      image6326.png

        • 1. Re: Unable to (re) program BCM20736
          ArvindS_76

          Recovery should always work, even if you programmed the wrong FW image into it. Do you have the download log file (should be in the application's build folder, and must be called download.log). You may also want to try getting a more detailed download log. Edit Makefile, look for the recipe 'recover_using_chipload' and then in the command that involes the downloader, add -LOGTO some_file.log. It should now look like this:

           

          $(QUIET)$(call CONV_SLASHES,$(CHIPLOAD_FULL_NAME)) -BLUETOOLMODE -PORT $(UART) -BAUDRATE $(PLATFORM_BAUDRATE) -NODLMINIDRIVER -MINIDRIVER $(SOURCE_ROOT)Platforms/$(PLATFORM_FULL)/$(PLATFORM_MINIDRIVER) -BTP $(SOURCE_ROOT)Platforms/$(PLATFORM_FULL)/$(PLATFORM_BOOTP) -CONFIG build/$(OUTPUT_NAME)/$(OUTPUT_NAME).hex -LOGTO build/$(OUTPUT_NAME)/$(OUTPUT_NAME).log -CHECKCRC -NOVERIFY -DLMINIDRIVERCHUNKSIZE 251 > build/$(OUTPUT_NAME)/download.log 2>&1 && $(ECHO) Recovery complete && $(ECHO_BLANK_LINE) && $(ECHO) $(QUOTES_FOR_ECHO)Application running$(QUOTES_FOR_ECHO) || $(ECHO) $(QUOTES_FOR_ECHO)**** Recovery failed - retry ****$(QUOTES_FOR_ECHO)

           

          And then use the recovery steps from the quick start guide.

          1 of 1 people found this helpful
          • 2. Re: Unable to (re) program BCM20736
            jora_1327726

            No luck.  There something wrong with the serial port as you can see from the traces I included.  The logs confirm this:


            2014-09-15@12:44:41.902  Will be downloading 0 bytes of code and 11236 bytes of data using minidriver Platforms/BCM920736TAG_Q32/uart_DISABLE_EEPROM_WP_PIN1.hex

            2014-09-15@12:44:41.902  BTP file: Platforms/BCM920736TAG_Q32/20736_EEPROM.btp

            2014-09-15@12:44:41.902  The config data is coming from the following files

            2014-09-15@12:44:41.902  build/test-BCM920736TAG_Q32-rom-ram-Wiced-release/test-BCM920736TAG_Q32-rom-ram-Wiced-release.hex

            2014-09-15@12:44:41.902 Sending bytes to HW:

            4 bytes:  01 03 0C 00

            2014-09-15@12:44:42.152 ERROR: Failed to execute HCI Reset

             

            I programmed another board with older firmware (using my chipload script) and it went without a hitch.  Tried to program one of the dead boards with the same result. Serial lines responded as expected on working board:

             

            image11044.png

            • 3. Re: Unable to (re) program BCM20736
              ArvindS_76

              I'd like to see the command line parameters used by chipload. Can you set VERBOSE=1 in your make target and then copy-paste how chipload is being invoked?

              • 4. Re: Unable to (re) program BCM20736
                jora_1327726

                One more data point...

                 

                I got impatient and I flashed a third unit with the same firmware as the first two but with the correct platform in the target name.  Board was found, flashed and booted up just fine (whew!).  Repeated with same board after cycling power and again was able to flash and run the firmware.  Board is from same batch as the first two so there should be no hardware differences.

                 

                Having the wrong platform name seems to be the culprit.  I'm still interested in this as I'd like to recover the 2 borked boards if at all possible.

                1 of 1 people found this helpful
                • 5. Re: Unable to (re) program BCM20736
                  jora_1327726

                  Attached is folder for my non-ide loader.  test.bat calls chipload:

                   

                  ChipLoad.exe -BLUETOOLMODE -PORT COM35 -BAUDRATE 115200 -MINIDRIVER uart_DISABLE_EEPROM_WP_PIN1.hex -BTP 20736_EEPROM.btp -CONFIG test-BCM920736TAG_Q32-rom-ram-Wiced-release.hex -LOGTO program.log -CHECKCRC -NOVERIFY -DLMINIDRIVERCHUNKSIZE 251

                   

                  output is the same:

                   

                  2014-09-15@13:44:48.221  About to execute DownloadMinidriver command

                  2014-09-15@13:44:48.221 Sending bytes to HW:

                  4 bytes:  01 2E FC 00

                  2014-09-15@13:44:48.471 ERROR:  BluetoolDownloadMinidriver failed!

                   

                  I don't think the problem is on the PC side.  The chip is just plain 'ol not responding.  This same script/fw works on a non-borked board.

                  • 6. Re: Unable to (re) program BCM20736
                    ArvindS_76

                    Hmmm.. then its really not in recovery mode. Also try adding add -NODLMINIDRIVER to this command:

                     

                    ChipLoad.exe -BLUETOOLMODE -PORT COM35 -BAUDRATE 115200 -MINIDRIVER uart_DISABLE_EEPROM_WP_PIN1.hex -BTP 20736_EEPROM.btp -CONFIG test-BCM920736TAG_Q32-rom-ram-Wiced-release.hex -LOGTO program.log -CHECKCRC -NOVERIFY -DLMINIDRIVERCHUNKSIZE 251 -NODLMINIDRIVER

                    • 7. Re: Unable to (re) program BCM20736
                      jora_1327726

                      Same result with NODLMINIDRIVER:

                       

                      2014-09-15@14:23:41.439  Will be downloading 0 bytes of code and 10547 bytes of data using minidriver uart_DISABLE_EEPROM_WP_PIN1.hex

                      2014-09-15@14:23:41.439  BTP file: 20736_EEPROM.btp

                      2014-09-15@14:23:41.439  The config data is coming from the following files

                      2014-09-15@14:23:41.439  test-BCM920736TAG_Q32-rom-ram-Wiced-release.hex

                      2014-09-15@14:23:41.439 Sending bytes to HW:

                      4 bytes:  01 03 0C 00

                      2014-09-15@14:23:41.689 ERROR: Failed to execute HCI Reset

                       

                       

                      I agree, it appears that either it's not in recovery mode or that recovery mode was somehow compromised.

                      • 8. Re: Unable to (re) program BCM20736
                        ArvindS_76

                        OK, try this sequence:

                         

                        0. Remove UART connection to PC

                        1. Short SDA to GND

                        2. Power up the chip and wait for a couple of seconds or so.

                        3. Remove SDA to GND short.

                        4. Connect HCI UART for programming.

                        5. Try downloading with -NODLMINIDRIVER

                        • 9. Re: Unable to (re) program BCM20736
                          jora_1327726

                          I had put this problem aside but ran into it again yesterday.  Thought I had killed 3 boards but then remembered I had started this thread and hadn't followed up.  Tried above procedure and was able to recover all 3 boards.  Not sure what happened to my original but I'm confident that when I find it I'll be able to recover it as well.  I did not need to program with -NODLMINIDRIVER.  Just updating from the IDE was sufficient.