1 2 3 Previous Next 36 Replies Latest reply on Jan 24, 2015 11:20 AM by jcardona

    rtc_sample bricks our BCM20736S-based board

    jcardona

      Hi,

       

      We have bricked two boards by trying to use the external clock.  The first board failure happened when we modified rtc_sample.c to comment out the statements to disable P10, P26 and P27:

       

      //gpio_configurePin(0, 10, GPIO_INPUT_DISABLE, 0);
      gpio_configurePin(0, 11, GPIO_INPUT_DISABLE, 0);

      gpio_configurePin(0, 12, GPIO_INPUT_DISABLE, 0);

      // P26: port 1, pin 10

      //

      gpio_configurePin(1, 10, GPIO_INPUT_DISABLE, 0);

      // P27: port 1, pin 11

      //gpio_configurePin(1, 11, GPIO_INPUT_DISABLE, 0);

       

      After this happened, we were unable to recover the board using the usual recovery procedure: reset while holding SDA (pin 22) to VDD. (See Edit Note below)

      This failure lead us to suspect a conflict between the crystal and P26 and P27, which apparently exists on the SOC version of the 20736.  So we repeated the experiment (with a second board), this time with rtc_sample.c unmodified.  That resulted in the exact same failure: a terminally bricked board.  Below is the schematic of the crystal circuit.

       

      xtal-pins.pngxtal-network.png

      We are able to run rtc_sample.c successfully on the BCM920737TAG after populating the crystal 0OHM resistors.

      This was observed with WCED-Smart-SDK Version: WicedSmart_002.001.001.0056.

       

      Now our questions:

       

      1. Is there anything wrong in our crystal circuit?

      2. What could cause a board to brick and become unrecoverable?

      3. The changelog for SDK 2.2 just mentions "Bug fixes".  Were any rtc-related bug fixes resolved?

       

      EDIT:  We are now able to recover from this.  See this thread for details: BCM20736S recovery problem - SDA high does not enter recovery mode

       

      Thanks,

       

      Javier

        • 1. Re: rtc_sample bricks our BCM20736S-based board beyond repair
          jcardona

          More details on this...

           

          It appears that our boards cannot complete a recovery procedure, even the good (unbricked) ones.  Or at least this is the conclusion we arrived to based on the following observations:

           

          1. Both a good board as well as a bricked board report **** Recovery failed - retry ****.  After a failed recovery, the good board continues to be programmable, while the bricked board does not.

           

          2. The logs show that the hardware responds in the same way for both the good and the bricked boards:

           

          22:16:57.058  Will be downloading 0 bytes of code and 4931 bytes of data using minidriver Platforms/BCM920736TAG_Q32/uart_DISABLE_EEPROM_WP_PIN1.hex
          22:16:57.058  BTP file: Platforms/BCM920736TAG_Q32/20736_EEPROM.btp
          22:16:57.058  The config data is coming from the following files
          22:16:57.058  build/proximity-BCM920736TAG_Q32-rom-ram-Wiced-release/proximity-BCM920736TAG_Q32-rom-ram-Wiced-release.hex
          22:16:57.058 Sending bytes to HW:
          4 bytes:  01 03 0C 00
          22:16:57.062 Received bytes from HW:
          7 bytes:  04 0E 04 01 03 0C 00
          22:16:57.062 Sending bytes to HW:
          259 bytes:  01 4C FC FF 00 10 20 00 10 B5 81 B0 73 48 00 F0 E3 F8 00 23 72 49 0B 60 72 49 0B 60 00 F0 EF FB ...
          22:16:57.087 Received bytes from HW:
          7 bytes:  04 1C 08 04 30 F0 00
          22:16:57.091 Received bytes from HW:
          7 bytes:  04 1C 08 04 30 F0 00
          (...)
          22:16:57.577 ERROR: Download minidriver error trying to write 251 bytes to address 0x00201000
          

           

          3. Even though the ChipLoad is invoked with the -NODLMINIDRIVER option, ChipLoad seems to try to download the minidriver.

           

          Tools/ChipLoad/Linux64/ChipLoad -BLUETOOLMODE -PORT /dev/ttyUSB0 -BAUDRATE 115200 -NODLMINIDRIVER -MINIDRIVER Platforms/BCM920736TAG_Q32/uart_DISABLE_EEPROM_WP_PIN1.hex -BTP Platforms/BCM920736TAG_Q32/20736_EEPROM.btp -CONFIG build/proximity-BCM920736TAG_Q32-rom-ram-Wiced-release/proximity-BCM920736TAG_Q32-rom-ram-Wiced-release.hex -LOGTO build/proximity-BCM920736TAG_Q32-rom-ram-Wiced-release/proximity-BCM920736TAG_Q32-rom-ram-Wiced-release.log -CHECKCRC -NOVERIFY -DLMINIDRIVERCHUNKSIZE 251 > build/proximity-BCM920736TAG_Q32-rom-ram-Wiced-release/download.log 2>&1 && "Tools/common/Linux64/echo" Recovery complete && "Tools/common/Linux64/echo" && "Tools/common/Linux64/echo" "Application running" || "Tools/common/Linux64/echo" "**** Recovery failed - retry ****"
          **** Recovery failed - retry ****
          

           

          4. After removing the -MINIDRIVER option from the chipload arguments, chiploads honors the NODLMINIDRIVER argument but the recovery still fails, with a different error:

           

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

           

          The way we used to enter recovery mode in earlier SDKs was to hold SDA to VDD, then hit RESET, release SDA and then make recovery.  Is there anything in the recovery code that might have changed in SDK 2.1.1 ?

           

          Also, another observation related to recovery:

           

          The recovery process works on the TAG3 board but only if dipswitches 1-4 are ON.  If any DIP switches 1, 2 or 3 are off when the reset + bootroom buttons are pressed, the device does not enter recovery mode.  In other words, the following sequence will always fail:

           

          1. attach usb cable to PC

          2. turn any combination of dipswitches 1,2 or 3 off

          3. press and hold boot_rom push button (SW5)

          4. press RESET

          5. release SW5

          6. turn on all dip switches

          7. attempt to make recover

           

          This always fails.  But leaving all dipswitches on in step 2 will work.  In other words, it appears as if the UART must be connected during recovery boot, which is in contradiction with the answer given here:  Unable to (re) program BCM20736

           

          Any advice on how to recover this boards would be very appreciated.  Overall we are finding these devices too easy to brick and too hard to recover.

           

          Thanks,

           

          Javier

          • 2. Re: rtc_sample bricks our BCM20736S-based board beyond repair
            MichaelF_56

            Per the other thread, I personally do not see how using P11/P12 (primary) for the external clock will conflict with P26/P27: Re: BCM2073xS (BCM20737S) GPIO bonding

             

            I am not aware of any external crystal related fixes in SDK 2.2

             

            Can you confirm that this is a SIP module design as noted in the other thread as opposed to an SOC design as noted in this one. The pin/GPIO mappings between the two are quite a bit different.

             

            I will also engage a few others on my team tomorrow that have more experience than myself in this area and have them confirm my my understanding of how primary and secondary GPIO assignments work and what is lost when you make the decision to use one over the other. I will also try to find some others users here on the forum that were able to get the external crystal working within their design.

             

            jota_1939431 VikramR_26

            • 3. Re: rtc_sample bricks our BCM20736S-based board beyond repair
              jcardona

              Hi mwf_mmfae,

               

              Thanks for your help.  Yes, I confirm that our design uses a SIP (BCM20736S).

              Just to summarize our problems with our design after this long thread:

               

                1. When flashing rtc_sample the board becomes "unreprogrammable"

                2. The recovery procedure (SDA-to-VDD + RESET) has stopped working, both for good as well as for "unreprogrammable" boards.

               

              1+2 result in a bricked, unrecoverable board.

               

              Thanks,

               

              Javier

              • 4. Re: rtc_sample bricks our BCM20736S-based board beyond repair
                MichaelF_56

                Ok, so it looks like you are trying to translate the SOC based example here (can be used on the TAG board, which uses the SOC) to your own SIP module design: how to config RTC use external 32.768?

                 

                Per the datasheet here for the SOC: BCM20737 SOC Data Sheet

                 

                P26/27 or P11/12 can be used for the crystal circuit, which explains the dual function pin descriptions discussed in the other thread.

                 

                I also noticed that we recommend a circuit in figure 6 on page 20 of the datasheet as well (note that we recommend different values vs. what is shown):

                xtal.png

                  So at this point, the approach you have taken to implement this on the SIP module design seems sound.

                 

                There are quite a few software changes noted in the thread above as well.  Have you since worked through those as well?  If I am not mistaken, I think this example should now be included within the SDK as well.

                 

                jota_1939431 VikramR_26

                • 5. Re: rtc_sample bricks our BCM20736S-based board beyond repair
                  jcardona

                  Hi mwf_mmfae,

                   

                  Yes, we are trying to use the rtc_sample.c example code that is included in SDK 2.1.1 on our SIP based design.

                  Unfortunately, until we resolve the recovery problem, we cannot do much experimentation with the rtc: every failed example costs us one bricked board, and we don't have that many prototypes...

                   

                  Cheers,

                   

                  Javier

                  • 6. Re: rtc_sample bricks our BCM20736S-based board beyond repair
                    MichaelF_56

                    Have you ever been able to program one of your own boards without the external Xtal setup?  I ask because most customers struggle to initially setup the programming interface to their own board.

                     

                    There are 2-3 other examples of such that are in progress now within the forum.I'm trying to figure out if it's a programming setup issue, HW conflict, SW conflict, etc.  These bricking issues are definitely the most difficult issues to figure out.

                    • 7. Re: rtc_sample bricks our BCM20736S-based board beyond repair
                      jcardona

                      Hi mwf_mmfae,

                       

                      Yes, we were able to program our boards successfully.  The HW evolution has been...

                       

                      proto002 - no SDA exposed, no external clock

                        - programmed successfully

                        - after bricking a board, we realized we needed SDA access to unbrick

                        - reworked one proto002 to expose SDA

                        - recovered that board with the SDA-high + RESET sequence

                        - captured engineering change order for proto003: expose SDA

                       

                      proto003 - exposes SDA (via test point) + external clock

                        - programmed successfully

                        - bricked board while testing the external clock

                        - bricked board could not be recovered with SDA-high + RESET sequence

                        - tried recovery sequence on non-bricked boards, and also fails

                        - documented recovery troubles here: BCM20736S recovery problem - SDA high does not enter recovery mode

                       

                      We have proto004 plans on hold until we resolve this problem.

                       

                      Thanks,

                       

                      Javier

                      • 8. Re: rtc_sample bricks our BCM20736S-based board beyond repair
                        MichaelF_56

                        jcardona,

                         

                        As a follow up to the dialog over the weekend, I wanted to update/confirm with you a few items I learned/verified today (item 1 was posted in the previous thread and was related to the proper use of available GPIO).

                         

                        2.

                        I learned that the rtc_sample that is provided within the SDK was only tested on an engineering prototype board initially. This board, like the TAG3 development board, uses an SOC. To date, we have not tested this feature on a board that uses the SIP module.

                         

                        With that said, have you tested this yourself using the TAG3 board first using the following instructions related to installing the 0 ohm resistors provided within the comments?

                         

                        * To demonstrate the app, work through the following steps.

                        * 0. Enable the external 32KHz oscillator on the TAG board (see Quick Start Guide -

                        *   make sure that R102 and R103 on BCM920737TAG_Q32 are populated

                        *    with a 0 Ohm resistor, else the the behavior is undefined).

                        * 1. Plug the WICED eval board into your computer

                        * 2. Build and download the application (to the WICED board)

                        * 3. Application initializes and RTC and prints time every second.

                        * 3.a Application programs and enters deepsleep, optionally configuring for a timed wake.

                        */


                        The good news here is that VikramR_26 configured this tonight, using the TAG3 board and sample rtc_sample app from the SDK - installing only the 0 ohm resistors and loading the sample app, and everything appears to be working fine (he confirmed he could re-program the board and that the external clock was working).

                         

                        3.

                        Since we do not have a reference design to verify with using the SIP module, the team has asked that you send your schematics to mailto:communities-list@broadcom.com

                         

                        Once received, we will review and see if there is anything on the SIP schematic design that looks like a problem.

                         

                        At this point, we are thinking that since you copied the sample app from the SDK and have selected the right GPIO to call per the other thread where GPIO for the EXT OSC is being discussed, that the problem must be HW related. We are just not sure where at this point.

                         

                        jota_1939431

                        • 9. Re: rtc_sample bricks our BCM20736S-based board beyond repair
                          jcardona

                          Hi mwf_mmfae,

                           

                          Thank you for following up.

                           

                          1. Yes, we had tried the rtc_sample program on a TAG3 (with R102 and R103 populated) and it worked as documented.

                           

                          2. Regarding sharing the schematic, what is the visibility of that mailing list?  I don't think we can make the design publicly available (yet).

                           

                          Best,

                           

                          Javier

                          • 10. Re: rtc_sample bricks our BCM20736S-based board beyond repair
                            MichaelF_56

                            The mailing list is internal to our team. Broadcom only.

                            • 11. Re: rtc_sample bricks our BCM20736S-based board
                              jcardona

                              This is just to report that we are now able to recover from this failure, but we have not been able to get the external crystal to work.  I had sent my schematic for internal review, but no feedback yet.

                               

                              This post (BCM2073XS GPIO Basics) indicates that we cannot use P26 and P27 when using the external clock.  We are now disabling those when running this test.  In fact we are just trying the unmodified rtc_sample.c application to test this.

                               

                              Any suggestions welcome.

                               

                              Best,

                               

                              Javier

                              • 12. Re: rtc_sample bricks our BCM20736S-based board
                                MichaelF_56

                                Prior to the holiday break, VikramR_26 was able to implement the TAG3 board and the example rtc_sample from the SDK with no modifications other than the addition of the zero ohm resistors mentioned within the .c file included within the rtc_sample. The external crystal that is included on the TAG3 design came up without a hitch and he was able to see the clock transitions on the scope.

                                 

                                The only feedback I've received thus far on your schematic is as follows (I believe we've already discussed):

                                 

                                His schematic looks good, in his program he has to take care of this

                                     // Since the 32K external LPO is connected to P10, P11, P12, P26 and P27,

                                     // input and output disable all 5 GPIOs.

                                     Source : rtc_sample.c

                                When using the external crystal . So he cannot use P10, P11,P12,P26 and P27 when the external Oscillator needs to be used.

                                • 13. Re: rtc_sample bricks our BCM20736S-based board
                                  jcardona

                                  Hi mwf_mmfae,

                                  Prior to the holiday break, vik86 was able to implement the TAG3 board and the example rtc_sample from the SDK with no modifications other than the addition of the zero ohm resistors mentioned within the .c file included within the rtc_sample. The external crystal that is included on the TAG3 design came up without a hitch and he was able to see the clock transitions on the scope.

                                   

                                  Yes, but I don't know how is that information relevant.  As I said in the original post, and repeated on this thread, we were also able to run the example from the SDK on the TAG3 board.  The issue is with the BCM20736S-based board.  The same rtc_sample.c that works on the TAG3 fails on the SIP.

                                   

                                  Looking at the rtc_sample.c code, I don't see any reason why it should not work as is on the BCM20736S.  Of course, that assumes that the following calls behave the same on the SOC as well as the SIP:

                                   

                                  1.  P39 is not documented on the SIP datasheet.  Assuming SIP behavior is the same as SOC.

                                   

                                  // Always clear interrupts on P39, which is the interrupt pin used by the wake-from-deep-sleep HW block.
                                  gpio_clearPinInterruptStatus(GPIO_PIN_P39 / GPIO_MAX_NUM_PINS_PER_PORT, GPIO_PIN_P39 % GPIO_MAX_NUM_PINS_PER_PORT);
                                  

                                   

                                  2. P10 is not brought out neither on the SOC nor the SIP, yet the code configures it.

                                   

                                  // Since the 32K external LPO is connected tp P10, P11, P12, P26 and P27,    
                                  // input and putput disable all 5 GPIOs.    
                                  gpio_configurePin(0, 10, GPIO_INPUT_DISABLE, 0);
                                  

                                   

                                  3. rtc_init() is not documented.  Assuming it works on the SIP.

                                   

                                  // Initialize the RTC. 
                                  rtc_init();
                                  

                                   

                                  4. bleapputils_changeLPOSource() is documented as "Internal, not for application use".  Yet it is used by the application example.  Assuming it works on the SIP.

                                   

                                     bleapputils_changeLPOSource(LPO_32KHZ_OSC, FALSE, 250);
                                  

                                   

                                  Also, regarding our schematic, it seems that we have correctly hooked up the crystal, and the advice from your team is to have our program take care of disabling all 5 GPIOS.  But our program is the unmodified rtc_sample.c, which does disable all 5 GPIOs.  In an act of desperation, we even unsoldered the components that were connected to P26 and P27 so they would be left floating.  Still no luck.

                                   

                                  So right now our assumption is that we have hit a hardware limitation on the SIP.

                                  If the SIP has not been tested with an external clock, may I lend you some of our boards so your team can examine this issue? And if it has been tested, can we have access to the test code?

                                   

                                  Thanks,

                                   

                                  Javier

                                  • 14. Re: rtc_sample bricks our BCM20736S-based board
                                    jcardona

                                    Hi MichaelF_56

                                     

                                    I was wondering if the new year will bring us some new insights to those of us trying to hook up an external clock to a BCM20736S...  Anything new to report?  As I mentioned on my last post, I can provide sample boards if someone wants to troubleshoot this.

                                     

                                    Cheers,

                                     

                                    Javier

                                    1 2 3 Previous Next