1 2 Previous Next 21 Replies Latest reply on Dec 24, 2014 11:06 AM by MichaelF_56

    BCM20736S recovery problem - SDA high does not enter recovery mode

    jcardona

      Hi,

       

      In our BCM20736S-based design we have noticed that we cannot enter recovery mode.  Our design exposes SDA (pint 22) so we can drive it high when necessary.  But the normal sequence: 1. hold SDA high. 2. reset 3. release SDA does not put the device in recovery mode.  When attempting a recovery, the download logs show the following message:

       

      11:17:29.077  Will be downloading 0 bytes of code and 4931 bytes of data without a minidriver
      11:17:29.077  BTP file: Platforms/BCM920736TAG_Q32/20736_EEPROM.btp
      11:17:29.077  The config data is coming from the following files
      11:17:29.077  build/proximity-BCM920736TAG_Q32-rom-ram-Wiced-release/proximity-BCM920736TAG_Q32-rom-ram-Wiced-release.hex
      11:17:29.077 Sending bytes to HW:
      4 bytes:  01 03 0C 00
      11:17:29.081 Received bytes from HW:
      8 bytes:  04 1C 08 04 0C 60 00 F0
      (...)
      11:17:29.179 Received bytes from HW:
      8 bytes:  04 1C 08 04 0C 60 00 F0
      11:17:29.179 ERROR: Failed to execute HCI Reset
      
      
      
      

       

      This happens on boards that we can program normally, so we have ruled out UART/cable problems.

      We can also observe activity on SDA on boot, so we know that SDA is properly accessible.  Below is SDA activity on a normal reset.

       

      good-board-sda.png

       

      Anyone out there has experienced similar recovery problems?

       

      Best,

       

      Javier

        • 1. Re: BCM20736S recovery problem - SDA high does not enter recovery mode
          jcardona

          MichaelF_56

           

          Just wanted to update our status after a full day wasted on this issue.  This has stalled our development and putting the whole project at risk, so I would really appreciate any help you can provide.

           

          In order to simplify the variables we have tried to use one of our working (no-bricked) boards and a pristine SDK 2.2 release:

           

          1. Hit RESET and execute:

           

          ./make hello_sensor-BCM920736TAG_Q32 download BT_DEVICE_ADDRESS=random UART=/dev/ttyUSB0 DEBUG=1
          (...)
          Downloading application...
          Download complete
          Application running
          

          2. Verify application us running by observing advertisements and reading characteristics over BT

          3. Hold SDA-high, RESET, release SDA.

          4. Execute:

          ./make proximity-BCM920736TAG_Q32 recover BT_DEVICE_ADDRESS=random UART=/dev/ttyUSB0 DEBUG=1
          (...)
          Creating OTA images...
          Conversion complete
          OTA image footprint in NV is 5111 bytes
          Recovering platform ...
          **** Recovery failed - retry ****
          

          Logs attached.

           

          After this the board can still be programmed.

           

          We also tried to modify the recover_using_chipload target in the makefile to not use minidriver by removing the argument:

          -MINIDRIVER $(SOURCE_ROOT)Platforms/$(PLATFORM_FULL)/$(PLATFORM_MINIDRIVER)

           

          Recovery also fails, but with a different error.  This second log is also attached.

           

          We are really out of ideas here.  Any suggestions?

           

          Thanks,

          • 2. Re: BCM20736S recovery problem - SDA high does not enter recovery mode
            jcardona

            Ah, I should say we are using a FTDI-1.8 USB-to-UART cables for programming.  I see from other users (userc_7511) that:

             

            "I think we had a 1.8 volt problem when programming with the TAG board as the middleman.  Since I am using a 3.3V FTDI USB to UART cable now instead of the Tag board, the voltage looks fine and we are getting data/program into the Sip module." (Source: Programming the BCM20736S on a custom PCB)

             

            I don't know why a 1.8V cable would successfully program a board and yet, be unable to recover it.  But we have ordered a 3.3V cable and we'll try with that...

            • 3. Re: BCM20736S recovery problem - SDA high does not enter recovery mode
              userc_7511

              jcardona,

              For us the problem with 1.8 volts was that it is at the bottom edge of what the voltage regulator will tolerate on our custom board.  (wish we had known that sooner ).1.8 volts may be fine for you.    

               

              One possibility that comes to mind.  What is the voltage on the SDA pullup?  What is the voltage you are operating the BCM module at?  I understand from the BCM20736 datasheet that minimum voltage for logic high is your operating voltage minus 0.4 volts.  So if your BCM has VDD at say 2.5 volts, then you need at least 2.1 volts on SDA for it to be seen as a 'high'.  Take this with a grain of salt though, because my field is software, not hardware.

               

              I see in your log files that there seems to be a problem writing to the BCM's EEPROM memory which is connected to the SDA/SCL lines of the module.  A couple of things come to mind... not sure if any of these apply to you.

              1.  If the SDA were somehow still high after you released it, could that interfere with writing to memory.

              2. Does your schematic have the pullup on P1 ?

              3. In our case we had an external memory chip on the SDA/SCL I2C bus and it just happened to have the same address as the BCM's internal memory EEPROM, and we believe there was a conflict which manifested as a CRC error on dowload.  Do you have any other devices connected to SDA/SCL?

              4. ? last and probably least... bad BCM module?  I think you said you tried multiple boards.. so probably not.

               

              hope this helps.  I know how you feel.  We were spinning wheels too and under the gun to make progress.  If you contact your Broadcom rep they can put you in touch with more personalized support if the forum is not getting you what you need.  We got some great help from 79rpm and with some minor schematic changes might be back on track soon.

              1 of 1 people found this helpful
              • 4. Re: BCM20736S recovery problem - SDA high does not enter recovery mode
                userc_7511

                Oh... one more thought.  On the off chance that your "Reset" button is not working, maybe try to hold the SDA high during power up and release it only after the device is recognized in the computer (for windows it shows up in the device manager COM section).

                • 5. Re: BCM20736S recovery problem - SDA high does not enter recovery mode
                  jcardona

                  Hi @ehoffman,

                   

                  Thanks for taking the time to offer advice.  I believe I've covered all the issues you mention (some of them I learned from your responses in other threads).  Namely:

                   

                  1. Regulator.  We don't use one and the 20736S seems to allow as low as 1.65V, so I don't think we are facing the same issue you saw witht hat.

                   

                  2. For recovery reset, we short SDA to 1.8V, which is the same as VDD, so I think it is driven high.

                   

                  3. SDA is properly released after reset.

                   

                  4. Yes, we have a pull up on P1.

                   

                  5. No additional devices connected to SDA/SCL, only a test point.

                   

                  6. Bad module?  Hard to tell, but I have 6, but bricking them rapidly...

                   

                  Did you help?  YES.  As I said, your answers in other threads were very useful, and your moral support, even more!

                   

                  Best,

                   

                  Javier

                  • 6. Re: BCM20736S recovery problem - SDA high does not enter recovery mode
                    userc_7511

                    Sorry, made a mistake in the post above regarding logic high level.  The one I gave was output HIGH.  The HIGH for the input is 0.75 times VDD.   So at 2.5 volts, login high for input is 1.875  (meaning 1.8 probably would give a high, but not guaranteed).  Here is the snapshot of the page. bcmLogic.PNG

                    1 of 1 people found this helpful
                    • 7. Re: BCM20736S recovery problem - SDA high does not enter recovery mode
                      jcardona

                      Noted, but in our design VDD is 1.8, so SDA should be high.

                      I also run a quick experiment: run a make recovery after a plain reset, and then repeated the process after sda-high + reset, then compare the output logs.  Both fail, but the errors differ, so it seems as if SDA is doing something.

                       

                      SDA-High + RESET Error:

                      21:35:14.312 ERROR: Failed to execute HCI Reset

                       

                      RESET Error:

                      21:36:52.396 ERROR: Download minidriver error trying to write 251 bytes to address 0x002010FB

                       

                      Anyway, I should better stop before I lose all my hair...

                       

                      Cheers,

                       

                      Javier

                      • 8. Re: BCM20736S recovery problem - SDA high does not enter recovery mode
                        jora_1327726

                        Where are you guys getting instructions to drive SDA high for recovery mode?  I've seen this now in several posts recently but the instructions I received a while back were the exact opposite -- Short SDA to GND (Re: Unable to (re) program BCM20736):

                         

                        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: BCM20736S recovery problem - SDA high does not enter recovery mode
                          jcardona

                          That was direct experience.  On earlier prototypes, we had never succeeded in entering recovery mode by following the instructions above.  We were only able to do so by holding SDA high, which learned from the TAG3 schematics.

                           

                          Cheers,

                           

                          Javier

                          • 10. Re: BCM20736S recovery problem - SDA high does not enter recovery mode
                            jora_1327726

                            Hmm.. I never looked at the recovery section in the user manual.  I guess I don't understand what the recovery mechanism is -- SDA is already pulled up on the TAG3 board.  Does SW5 just prevent any data from getting sent on the bus forcing a timeout?

                             

                            Can one of the Broadcom guys clarify?

                            • 12. Re: BCM20736S recovery problem - SDA high does not enter recovery mode
                              MichaelF_56

                              Either technique should work.

                               

                              If VDDIO is present on SDA during boot up, then the firmware bypasses the step where it looks to the EEPROM for a valid image and goes directly into programming mode (Re: 20732S-Recovery from FW download failure)

                               

                              However, the previous entries in this post seem to imply that you can also GND the SDA pin and see the same behavior: Re: How can BCM20732S boot from ROM?

                               

                              Connecting SDA to Vdd/Vio to recover is probably not optimal for the following reason provided to me by one of the senior firmware engineers.

                               

                              SCL and SDA are both open-drain configuration and the pull-ups pull the signal high while the HW drives it low (never drives high, but floats the output pad leaving the pull-up to pull the line high). If you put a scope to either of these lines on the board when the firmware accesses these, you will see that high to low transitions will be very sharp while low to high transitions will be pretty slow due to the intrinsic RC.

                               

                              If you connect SCL/SDA to Vdd, then when the HW 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 because the ROM always uses 0xA0 as the slave address of the EEPROM and you can see that there are repeated 0s in this sequence (and the shorts) which could do bad things to the supply or the chip.

                               

                              Shorting to GND on the other hand, is safer because that is 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.

                               

                              jota_1939431 touches on this in his blog here as well: I2C Discussion

                               

                              jcardona userc_7511 jora_1327726 userc_4243

                              • 13. Re: BCM20736S recovery problem - SDA high does not enter recovery mode
                                MichaelF_56

                                Note that I created a new category called "Recovery' and tagged/grouped the threads I felt were relevant to the recovery process as I know these are sometime hard to find: WICED Smart Forums

                                • 14. Re: BCM20736S recovery problem - SDA high does not enter recovery mode
                                  jcardona

                                  mwf_mmfae,

                                   

                                  Thanks for the explanation.  Even though I have never seen a grounded SDA to work on our boards, I just tested that on a TAG3.  Instead of pushing the BOOT_ROM button, I connected the SDA side of the switch to ground, and I was able to complete a recovery.  So that confirms your explanation.

                                   

                                  But there is something more:  On the TAG3 holding the BOOT_ROM button + RESET with any of the dipswitches 1 to 3 off fails to enter recovery mode.  So, after reverting the dipswitches to ON, 'make ... recovery' will fail.  Could you run that experiment on your end?  Should just take you a few minutes.

                                   

                                  This would reveal that the ROM is doing something more than just checking for a valid EEPROM before entering recovery mode.

                                   

                                  Best,

                                  1 2 Previous Next