1 2 3 Previous Next 36 Replies Latest reply on Jan 24, 2015 11:20 AM by jcardona Go to original post
      • 30. Re: rtc_sample bricks our BCM20736S-based board

        Oh, wow, problem solved on our end.

        It turns out that our make script for that particular application (rtc_sample) still had the TAG3 setting:


        make rtc_sample-BCM920737TAG_Q32 download


        That downloads fine, prints the 'Application running' message... but bricks the board. Changing it to


        make rtc_sample-BCM920736TAG_Q32 download


        makes everything work.


        And, emboldened by that success, I decided to try using P26 concurrently with the external crystal.  On our board, that pin drives an LED, so it is easy to experiment with it.  And lo and behold, the LED can be toggled periodically without observable errors.  This seems to contradict the information here (BCM2073XS GPIO Basics)


        • P12/P26 (Dual bonded, only one of two is available.)
          - P12 if not used as P26 or external 32KHz LPO; If used as 32KHz LPO, then P12 and P26 are unavailable


        On our next prototype we are following your advice and not using P26 and P27.  But given that you have already wired up a crystal to your SIP, and that you have an LED on P27, you might want to test if the information given is accurate.


        Thanks a lot, MichaelF_56 and jota_1939431 for your support!!



        • 31. Re: rtc_sample bricks our BCM20736S-based board

          This is great news Javier.


          I am confused by many of the contradictions in previous threads as well, so I will work with the developers during our meeting next week to try and understand both the platform file issue (should be the same with regards to the Xtal circuit) and the use of dual bonded pins.


          I'm glad jota_1939431 was able to prove this circuit out on a readily available SIP module based platform as this will help many other users moving forward (kilian.timmler@exelonix.com)


          VikramR_26 jota_1939431 ArvindS_76

          • 32. Re: rtc_sample bricks our BCM20736S-based board

            Hi mwf_mmfae,


            Thanks for following through.


            Just to clarify, I don't think my error with the platform file issue has anything to do with the external crystal: we can brick the target with any of the sample projects by using the wrong platform suffix in the makefile (e.g. hello_client-BCM920737TAG_Q32 instead of hello_client-BCM920736TAG_Q32, etc.)

            It is just that we had only made that error with rtc_sample, because we had tried to run that particular project on both, the TAG3 as well as our own custom board.  And we simply forgot to change the "7" for the "6" in the make script.


            The fact that such mistake did not produce a download error (it downloads fine and prints "Application running"), made us suspect of a problem during execution, not with the build.  This is why we suspected other causes:  our external crystal circuit, GPIO conflicts and the SIP hw/fw itself,... 

            Thanks again for your help.



            • 33. Re: rtc_sample bricks our BCM20736S-based board

              Hi mwf_mmfae,


              Thanks for the link to this thread, we are currently using our design that heavily relies on the first few pins (P0 to P3) together with the external crystal and the 20737S. Everything works fine. I only bricked one module while performing power measurements. The issue with the wrong make target setup is interesting, I hope this never happens to me.


              Our future design will move to some of the doubly bonded pins, maybe I should read the thread above regarding the topic. I'll let you know whether we have any problems.


              Our only external oscillator mishap was omitting the 10Meg feedback resistor.





              1 of 1 people found this helpful
              • 34. Re: rtc_sample bricks our BCM20736S-based board

                Actually we started the new design before I read this thread and so I ended up with an LED on pin 27 (I could have noticed but I was more worried about keeping other interfaces accessible). This is a major mistake. Not only can I not use the external oscillator (or can I? I only need it during sleep) but the LED flashes when the device gets powered up or wakes up from deep sleep. Also the deep sleep to wakeup time is about 3 seconds which is way too much (I'm not sure whether this is related though). The LED is connected to 3V on the Anode so the GPIO line is used when active low. If you have ever heard about problems like the above I would like to know about it. Meanwhile I'll try to separate the boot up time issue from the pin 27 issue.





                • 35. Re: rtc_sample bricks our BCM20736S-based board

                  My understanding based on the explanation provided by the firmware team is that P11/P27  are Dual bonded, so only one of two is available:


                  Essentially, if used as a 32KHz LPO, then P11 and P27 are unavailable and should be input/output disabled (especially when it is an input).


                  I'm honestly not sure how WICED Sense bypasses this limitation in the example described above.

                  • 36. Re: rtc_sample bricks our BCM20736S-based board

                    Hi Kilian,


                    For what is worth, we encountered a similar problem.  At the time we did our design, the P26-P27 dependency on the external clock had not been properly documented on the 20376S, so we went ahead and used both.  An LED was attached to P26.  In the end it turned out that our bricking problem was caused by an error in our build scripts, and not due to a GPIO conflict.  In our prototypes we can now use the external processor AND both P26 (LED, as output, active low) and P27 (interrupt input, active high, triggered on leading edge).  So far we have not seen any problems but the prototype has not been extensively tested yet.


                    So my advice would be not to ditch your design just yet.  Have you tried rtc_sample.c on your board?  Does it work?  If so, try modifying that example to toggle your LED on P27.  This, to my surpise, worked for us.


                    Still, to minimize riske, we have moved those signals to other GPIO pins on the next iteration.  But our design needs all the available pins, so that limitation has forced us to remove necessary GPIOs.  This is why we would appreciate getting a definitive answer on this.





                    1 2 3 Previous Next