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.
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.
It was decided that jota_1939431 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.
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.
I just got back from Vegas myself. I'll wait to hear from you next week.
Stay out of trouble!
We just succeeded in changing the sample code to run successfully out of the internal code. Patch below:
@@ -111,22 +111,22 @@ void rtc_sample_create(void)
- // 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.
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);
s/internal code/internal clock/
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?
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".
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:
Can you provide information about each one of the above values? Some seem redundant...
Good news. jota_1939431 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.
On Friday, January 9, 2015, mwf_mmfae <
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...