cannot get rtc_sample code to work on the 20737S

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
BrCa_1072751
Level 2
Level 2
First like received

I am trying to put the 20737S chip on my board into a deep sleep, but the chip does not wake up on either a GPIO interrupt or by timer. Once the chip goes into a deep sleep, the chip stays asleep.  My board does not have an external clock.  I was able to put 20737 chip into a deep sleep and have it wake up either by timer or GPIO interrupt.

I tried to using the rtc_sample code from the Broadcom community site.  The sample code works on the BCM92073X_LE_KIT, which uses the 20737 chip.  The code however does not work on the BCM9WICED_SENSE, which uses the 20737S.  The Wiced Sense board stays asleep, just like my board, after going into a deep sleep.

Is there something I have to add or change in the rtc_sample code to make the 20737S chip wake up after a deep sleep?

I am using SDK 2.2.0.

0 Likes
1 Solution

bcarey,

Can you let us know if this is indeed resolved per your comments in this thread: How can I wake BCM20737S up by using GPIO interrupt?

I believe you solved this issue by unplugging the USB cable from the board.

Here's the explanation for why unplugging the USB allows the device to appear to come out of Deep Sleep, when really something completely different occurs..

Essentially, when coming out of Deep Sleep, or HIDOFF, the device reboots. When rebooting, the firmware knows to look at the HCI Rx line to see if its high, or if there is an external host attached.  When the USB cable is attached, the HCI UART Rx line is indeed high by design (handled by the FTDI bridge chip).

Therefore, when plugged into USB, the firmware senses this HCI Rx high state, it puts the part into programming mode (or HCI mode as it is sometimes referred to in the documentation).

So while it is not technically in Deep Sleep anymore, it appears that way.  In reality, the part is in programming mode.

Unplugging the USB cable removes the external high signal on HCI Rx, hence when the part reboots coming out of deep sleep as directed by the application, it never goes into programming mode.

View solution in original post

0 Likes
15 Replies
Anonymous
Not applicable

Hello Brad,

The TAG3 has an RTC devcice and the WICED Sense does not have an RTC device.

1.  Have you added an RTC to the WICED Sense Board?

2.  Please compare the TAG3 schematics Hardware User Guide (SDK 2.x and TAG3 Board) and the WICED Sense Reference Design Schematic (PDF).

Have you checked the crystal warm-up issue: Re: Prototype boards are failing with issue similar to one previously reported

ENTRY "PMU Crystal Warm up Time"

{

   "Crystal warm up time" = 5000

}

ENTRY "I2C Speed"

{

    "Speed" = "100 KHz"

}

Is the question that you are asking?

Thanks

JT

0 Likes

Hi JT,

No, we do not have an external RTC, or 32KHz crystal. We thought that we should be able to use the internal 32KHz crystal to implement RTC functions.

I take you are saying this is not correct for the 20737S?

If so, what is your suggestion for implementing sleep mode?

If our configuration is okay, should a non RTC method, like a timer, be used? If using the RTC is okay, what direction can you point us in for resolution?

Thanks,

brad

Sent by Outlook<http://taps.io/outlookmobile> for Android

0 Likes
Anonymous
Not applicable

Hello Brad,

Let me do some research on this with the developers.

Thanks

JT

0 Likes
Anonymous
Not applicable

Hello Brad,

Sorry the external crystal is optional.

Quick Question:

Another user was experiencing a similar issue: Re: rtc_sample bricks our BCM20736S-based board

Here is what fixed there issue with the error in the make file:

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

Is this your issue?

Thanks

JT

0 Likes

make rtc_sample-BCM920736TAG_Q32 download is not the issue.  I saw the post earlier about bricking the 20737S.  I made sure the make command was set for the BCM920737TAG.

0 Likes
Anonymous
Not applicable

Hello Brad,

Not sure it helps but the rtc sample code from the below thread is for an internal LPO

Source Code: deep sleep enablement and the associated clock source handling...

The rtc sample code in the SDK is for an external LPO...

Thanks

JT

0 Likes

Not sure it helps but the rtc sample code from the below thread is for an internal LPO

Source Code: deep sleep enablement and the associated clock source handling...

The rtc sample code in the SDK is for an external LPO...

0 Likes

Here is the output from the rtc_sample for external lpo on the Wiced Sense board and my 20737S board:

13:22:00 - blecm evt handler:

13:22:00 - 0e04010a200c

13:22:00   enterHidoff!!!

13:22:00   Prepare Power save

13:22:00   noAdv

13:22:00   Start Power Save

13:22:00   TimersKilled

13:22:00   abortHidoff!!!

13:22:00   Stop Power Save

13:22:00   Fine Timer(1024 ms, 1/sec)

13:22:00   Fine TImer tick 80

13:22:00   Normal Timer(0 s, 0 tick)

13:22:01 - Current date/time is:

13:22:01 - Jul 15 12:00:00 2014

13:22:01 - Its been 143121600 seconds since bigbang.

13:22:01 - Upper and lower 32 bit values: 0x00000000, 0x00000029

13:22:01 -

13:22:01 - Entering deep sleep.

13:22:01 -

13:22:01 - blecm evt handler:

13:22:01 - 0e04010a200c

13:22:01   enterHidoff!!!

13:22:01   Prepare Power save

13:22:01   noAdv

13:22:01   Start Power Save

13:22:01   TimersKilled

13:22:01   abortHidoff!!!

13:22:01   Stop Power Save

13:22:01   Fine Timer(1024 ms, 1/sec)

13:22:01   Fine TImer tick 80

13:22:01   Normal Timer(0 s, 0 tick)

13:22:02 - Current date/time is:

13:22:02 - Jul 15 12:00:00 2014

13:22:02 - Its been 143121600 seconds since bigbang.

13:22:02 - Upper and lower 32 bit values: 0x00000000, 0x00000029

13:22:02 -

13:22:02 - Entering deep sleep.

The HidOff seems to get aborted all the time.  It does not go to sleep.

Here is the output from the rtc_sample for internal lpo on the Wiced Sense board and my 20737S board:

13:23:38 - Current date/time is:

13:23:38 - Jul 15 12:00:09 2014

13:23:38 - Its been 143121609 seconds since bigbang.

13:23:38 - Upper and lower 32 bit values: 0x00000000, 0x0012696D

13:23:39 -

13:23:39 - Current date/time is:

13:23:39 - Jul 15 12:00:10 2014

13:23:39 - Its been 143121610 seconds since bigbang.

13:23:39 - Upper and lower 32 bit values: 0x00000000, 0x0014732E

13:23:40 -

13:23:40 - Current date/time is:

13:23:40 - Jul 15 12:00:11 2014

13:23:40 - Its been 143121611 seconds since bigbang.

13:23:40 - Upper and lower 32 bit values: 0x00000000, 0x00167CE6

13:23:40 -

13:23:40 - Entering deep sleep.

It just stops there.  It does not wake up.

Here are the make commands that I am using: 

rtc_sample_external_lpo-BCM920737TAG_Q32 download

rtc_sample_internal_lpo-BCM920737TAG_Q32 download

0 Likes
Anonymous
Not applicable

Hello Brad,

P0 is the culprit on the WICED Sense Kit - Please see the WICED Sense Schematic: WICED Sense Schematics

pastedImage_0.png

Disconnect the R23 and tie it to VDDIO and that should fix your problem.

Also see this post: http://community.broadcom.com/message/9777#9777

Thanks

JT

0 Likes

I tried running rtc_sample with the fix on P0 on my board (not on the Wiced Sense board).  rtc_sample for internal lpo still hangs on a deep sleep (doesn't wake up).  However, now, for rtc_sample for external lpo, the app never starts.

I tried running my app on my board with the P0 fix.  No change.  What happens is that after calling devlpm_enterLowPowerMode(), the hidoff callback gets called.  After that, the device goes to sleep and never wakes up.  I am trying to get the 20737S to wake up by both timer and GPIO (in this case P13).

I tried running my app on the 20737 eval kit using GPIO P0 and the deep sleep worked fine.  Does using P13 instead of P0 make a difference?

0 Likes
Anonymous
Not applicable

Hey Brad,

Take a look here: BCM2073XS GPIO Basics

Stay away from P0.

Let me know if that helps.

Thanks,

JT

0 Likes
Anonymous
Not applicable

Hello Brad,

A few more comments from the developers:

1.  Is HCI UART connected?
2.  Perhaps it is waking up, but it sees HCI UART is connected and so boots in HCI mode?
3.  Turn off dip switch 2 on SW4 on TAG3 and try the test again.

Thanks

JT

0 Likes

bcarey,

Can you let us know if this is indeed resolved per your comments in this thread: How can I wake BCM20737S up by using GPIO interrupt?

I believe you solved this issue by unplugging the USB cable from the board.

Here's the explanation for why unplugging the USB allows the device to appear to come out of Deep Sleep, when really something completely different occurs..

Essentially, when coming out of Deep Sleep, or HIDOFF, the device reboots. When rebooting, the firmware knows to look at the HCI Rx line to see if its high, or if there is an external host attached.  When the USB cable is attached, the HCI UART Rx line is indeed high by design (handled by the FTDI bridge chip).

Therefore, when plugged into USB, the firmware senses this HCI Rx high state, it puts the part into programming mode (or HCI mode as it is sometimes referred to in the documentation).

So while it is not technically in Deep Sleep anymore, it appears that way.  In reality, the part is in programming mode.

Unplugging the USB cable removes the external high signal on HCI Rx, hence when the part reboots coming out of deep sleep as directed by the application, it never goes into programming mode.

0 Likes

I haven't pursued getting the rtc_sample to work after figuring out how to wake up the 737S chip from a deep sleep by using a GPIO interrupt. 

I was using the rtc_sample to figure out how to wake up the chip from a deep sleep.  Since the goal was to wake up the chip by using a GPIO interrupt, I no longer needed the rtc_sample code.  I think that as long there was no USB connection to the chip, the rtc_sample would have worked.

0 Likes

Thanks Brad.

0 Likes