cancel
Showing results for 
Search instead for 
Did you mean: 

WICED Smart Bluetooth

Anonymous
Not applicable

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

0 Likes
1 Solution
Anonymous
Not applicable

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, mwf_mmfae and j.t for your support!!

Javier

View solution in original post

0 Likes
36 Replies
Anonymous
Not applicable

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

0 Likes
MichaelF_56
Moderator
Moderator

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.

j.t vik86

0 Likes
Anonymous
Not applicable

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

0 Likes
MichaelF_56
Moderator
Moderator

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.

j.t vik86

0 Likes
Anonymous
Not applicable

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

0 Likes
MichaelF_56
Moderator
Moderator

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.

0 Likes
Anonymous
Not applicable

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

MichaelF_56
Moderator
Moderator

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 vik86 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.

j.t

0 Likes
Anonymous
Not applicable

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

MichaelF_56
Moderator
Moderator

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

0 Likes
Anonymous
Not applicable

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

0 Likes
MichaelF_56
Moderator
Moderator

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.

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.

0 Likes
Anonymous
Not applicable

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

0 Likes
Anonymous
Not applicable

Hi mwf_mmfae

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

0 Likes
MichaelF_56
Moderator
Moderator

We have a meeting later this week with the developers.

I will ask at that time if these can provide guidance on how to properly map the Ext OSC/RTC sample from the SDK from an SoC based design to one using the SIP module.

At this point, it appears nobody else has tried/implented this in an actual design.

@_vik86

0 Likes
Anonymous
Not applicable

Hi mwf_mmfae,

It appears nobody else has tried/implented this in an actual design.

Thanks a lot for following up.  It is not very reassuring to hear that.

Isn't there any internal test configuration of the SIP that you can share?

If your team does not have a SIP-based board with an external clock, let me re-iterate my offer to share our boards with your team to test this.

We will eagerly await to hear how the meeting with your developers went.

Cheers,

Javier

0 Likes
MichaelF_56
Moderator
Moderator

It was decided that j.t will take the only reference design we have internally that uses the SIP module (iBeacon) and have the lab wire up an external reference clock, then test and validate accordingly with known HW.

He is out of the office this week, and I am not sure of his schedule next week.

If you must go into production today, I would recommend excluding the external crystal from the design as we cannot gaurantee when this will be tested/updated.

vik86

0 Likes
Anonymous
Not applicable

Hello Jarconda,

Let me get the External Crystal project started and get back to you next week.

I am at CES, so this is NOT a great week since I am out of the office.

Thanks

JT

0 Likes
Anonymous
Not applicable

Thank JT,

I just got back from Vegas myself.  I'll wait to hear from you next week.

Stay out of trouble!

Javier

0 Likes
Anonymous
Not applicable

We just succeeded in changing the sample code to run successfully out of the internal code.  Patch below:

--- a/Apps/rtc_sample/rtc_sample.c

+++ b/Apps/rtc_sample/rtc_sample.c

@@ -111,22 +111,22 @@ void rtc_sample_create(void)

     bleprofile_Init(bleprofile_p_cfg);

-       // If we need to use the external 32K, then configure the reference

-       rtcConfig.oscillatorFrequencykHz = RTC_REF_CLOCK_SRC_32KHZ;

+    // If we need to use the internal 128K, then configure the reference

+    rtcConfig.oscillatorFrequencykHz = RTC_REF_CLOCK_SRC_128KHZ;

        // 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);

-       gpio_configurePin(0, 11, GPIO_INPUT_DISABLE, 0);

-       gpio_configurePin(0, 12, GPIO_INPUT_DISABLE, 0);

-       gpio_configurePin(1, 10, GPIO_INPUT_DISABLE, 0);

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

+       /*gpio_configurePin(0, 10, GPIO_INPUT_DISABLE, 0);*/

+       /*gpio_configurePin(0, 11, GPIO_INPUT_DISABLE, 0);*/

+       /*gpio_configurePin(0, 12, GPIO_INPUT_DISABLE, 0);*/

+       /*gpio_configurePin(1, 10, GPIO_INPUT_DISABLE, 0);*/

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

     // Initialize the RTC.

     rtc_init();

     memset(buffer, 0x00, sizeof(buffer));

@@ -179,7 +179,7 @@ void rtc_sample_create(void)

     // Switching to the external 32K with bleapputils_changeLPOSource without having

     // initialized the RTC, the high-z'ing bonded GPIOs and not having the 32KHz oscillator physically

     // connected to the chip will invoke undefined behavior.

-    bleapputils_changeLPOSource(LPO_32KHZ_OSC, FALSE, 250);

+    /*bleapputils_changeLPOSource(LPO_32KHZ_OSC, FALSE, 250);*/

     // Trace out number of bytes free.

     ble_trace1("Number of free bytes in RAM: %d",  cfa_mm_MemFreeBytes());

@@ -232,7 +232,7 @@ void rtc_sample_timeout(UINT32 arg)

                        // Configure the reference clock to use.

                        // Use the external 32k.

-                       devLpmConfig.wakeFromHidoffRefClk = HID_OFF_TIMED_WAKE_CLK_SRC_32KHZ;

+                       devLpmConfig.wakeFromHidoffRefClk = HID_OFF_TIMED_WAKE_CLK_SRC_128KHZ;

                        gpio_configurePin(0, 0, 0x100, 0);

0 Likes
Anonymous
Not applicable

s/internal code/internal clock/

0 Likes
MichaelF_56
Moderator
Moderator

This is great news!  I think we should still figure out a way to get this working internally so that we have a point of reference for future issues.

I have not had a chance to compare your patch to the code we supply within the sample.  What do you believe to be the main cause of the issue you were experiencing?

j.t vik86 arvinds

0 Likes
Anonymous
Not applicable

mwf_mmfae,

Please note that our changes are just to configure the original rtc_sample.c to use the internal clock.  This is just a workaround for us to move forward, but this approach gives us insufficient timing accuracy for our application.  This is why I have unmarked the post as "Correct Answer".

Cheers,

Javier

0 Likes
Anonymous
Not applicable

By the way, when looking into this, we noticed that the internal function bleapputils_changeLPOSource() can take the following any of the following as first argument:

enum

{

    LPO_CLK_INTERNAL,

    LPO_CLK_EXTERNAL,

    LPO_CLK_CRYSTAL,

    LPO_NO_SELECTED,

    LPO_32KHZ_OSC,

    LPO_MIA_LPO

};

Can you provide information about each one of the above values?  Some seem redundant...

Thanks,

0 Likes
MichaelF_56
Moderator
Moderator

Per the previous dialog, we will return to the idea of having j.t and vik86 test the external xtal concept using our only reference design which leverages the SIP module, the iBeacon design.

0 Likes
MichaelF_56
Moderator
Moderator

Good news.  j.t confirmed that the WICED Sense Kit actually uses the SIP module (WICED Sense Reference Design Bill of Materials) and has the correct GPIOs brought out to test the external xtal.  I believe the new plan is to use it for testing as opposed to the iBeacon design I had originally mentioned.

0 Likes
Anonymous
Not applicable

nice!

On Friday, January 9, 2015, mwf_mmfae <

0 Likes
Anonymous
Not applicable

Hello Javier,

I did confirm that with an External Crystal, the un-modified rtc_sample project does indeed work.

also used your circuit of 12pF Caps.

Crystal Waveform:

pastedImage_0.png

See TeraTerm output from the P_UART:

pastedImage_0.png

So what are your next steps?

Thanks

JT

Anonymous
Not applicable

Hi j.t.,

That's a big relief to know that there is nothing wrong with the SIP.

Did you leave P26 and P27 unconnected?  Could the fact that they are connected to other components (even though they are configured to be GPIO_INPUT_DISABLED) have an impact? I doubt that this could be our problem, because it appears that on the WICED Sense reference design, P27 is also connected to an LED (according to WICED Sense Reference Design Schematic (PDF))

Another possible factor could be that you are using a 20737S whereas we are using the 20736S.  Is the external crystal interface identical on those two?

Other than that, we are out of ideas.  We will test one more time, this time with the added hope you've given us...

Cheers,

Javier

0 Likes
Anonymous
Not applicable

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, mwf_mmfae and j.t for your support!!

Javier

View solution in original post

0 Likes
MichaelF_56
Moderator
Moderator

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 j.t 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)

vik86 j.t arvinds

0 Likes
Anonymous
Not applicable

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.


Best,


Javier




0 Likes
Anonymous
Not applicable

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.

Regards,

Kilian

Anonymous
Not applicable

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.

Regards,

Kilian

0 Likes
MichaelF_56
Moderator
Moderator

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.

0 Likes
Anonymous
Not applicable

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.

Best,

Javier

0 Likes