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