CC3100MOD: Ther are individual differences in sl_Start() exexution time.

user3970495

Prodigy 90 points

Part Number: CC3100MOD
Other Parts Discussed in Thread: CC3100

I'm using CC3100MOD and SimpleLink.There are individual differences in sl_Start () execution time.

Servicepack version is 1.0.1.14-2.12.2.8

When I checked the rising time of nReset (nHib)-> IRQ, the result was as follows.

Board A:about 2.3sec
Board B:about 1.7sec
Board C:about 1.8sec
What cause?

over 4 years ago

0 Michael Reymond over 4 years ago

TI__Mastermind 40965 points

Hi,

For each of your tested boards, is the startup time consistent? So is the Board A startup time always 2.3 seconds, the Board B time always 1.7 seconds, etc?

There are a few factors that could alter the startup time of the CC3100, based purely on software differences:

1. The different CC3100 could be performing radio calibration - this is performed based on mainly temperature variations, but given the internal CC3100 temp sensor is not extremely precise, it could potentially result in only some CC3100 units recalibrating on sl_Start

2. If there is a WLAN profile programmed and auto-connect enabled, the CC3100 will scan at startup and then connect to the AP. This will have some time variance depending on how long the scan takes. The scan will take a variable amount of time per channel depending on the local RF environment.

Is there any hardware difference you can tell between the different CC3100mod units? They should all have the same internal BOM, so it's unlikely that will be the cause of the startup time difference.

Regards,

Michael

0 user3970495 over 4 years ago in reply to Michael Reymond

Prodigy 90 points

Reply Thank you.
>>For each of your tested boards, is the startup time consistent? So is the Board A startup time always 2.3 seconds, the Board B time always 1.7 seconds, etc?
→Yes , the startup time is consistent for each of tested boards.
I don't using auto-connected. I am using auto smart config.

>>Is there any hardware difference you can tell between the different CC3100mod units?
→I couldn't find a difference. Is there a way to check?

Thank you.

0 user3970495 over 4 years ago in reply to Michael Reymond

Prodigy 90 points

Let me ask you an additional question.

The conditions for re-calibration are described in spec as follows,

only if the temperature has changed by more than 20°C,

or the time elapsed from prior calibration is greater than 24 hours.

If so, restarts should be faster after second time(within 24 hours).

But, board A takes a long time even if it restarts immediately. And it always takes a long time about 2.3 sec.

We think that the information of the temperature sensor is not taken in correctly.

(It varies by 20 degrees or more due to disconnection between the sensor and the module, etc.)

Could you please tell us how to check the temperature sensor read value ?

Best Regards,

0 Michael Reymond over 4 years ago in reply to user3970495

TI__Mastermind 40965 points

Hi,

There is unfortunately no documented way to check the internal temp sensor from the application MCU - that data is only provided to the NWP.

In general, any automatic process that is enabled at startup such as auto-connect, fast connect, etc. could have an impact. Have you tried also disabling auto smart config?

If that doesn't help, then please collect the NWP logs from each of your three devices, so that I can check the running state of the NWP and see what differences there might be in the startup sequence. Please take a look at section 19.1 in the NWP programmer's guide.

https://www.ti.com/lit/swru368

Regards,

Michael

0 user3970495 over 4 years ago in reply to Michael Reymond

Prodigy 90 points

Hello.

>>Have you tried also disabling auto smart config?

I tried disabling auto smart config.But , the result did not change.

I collected NWP logs of boardA and boardB.
I will attach the NWP log files, so please check it.

Best regards,

Fullscreen boardA.log Download

$66&$&"H 
� -�-1{�@	��	��
�
�	-�-1{�@
�����
�
�*��
�
�	�
�*� '��7z��P*�33����>V�
�*� X���E#
�	��
�
��
f
�!
'�/sys/servicepack.ucf
���`
�
-���`!-���`-���`@-���`8
�
�
�-�	��`�
���	�
�!
'�/sys/servicepack.ucf
���`
�
-���`!
�
�
�-���`�p��p�p�-�	��`�
�*�� *�� �*�	 H
�
�
�����

��Y���
�
�
�
�
�
�
�

�	-�-1{�@
�
	
�>
�!
'�/sys/pmcfg.ini
�I�-�I�
�
-�I�
-�	I�
�


a"<b
�
�

�!
'�/sys/servicepack.ucf
���`
�
-���`!
�
-���`-���`@-���`8
�
�
�
�
�-���`�-�	��`�
��*�
�!
'�/sys/ipcfg.ini
���-���
�
-����-�	��
�
�
�!
'�/sys/mode.cfg
���I-���I
�
-���I-���I<-�	��I
�
P
Q
�
�7�`� �t7�`�l 97�`إ �7�`�� T7�`�� �7�`dI �7�`,i 7w@� 0w
2�`��	�
�
� 
f�	
g��	
�!
'�/sys/devname.cfg
��c
��	


�����.�c�	�
�!
'�/sys/servicepack.ucf
���`
�
-���`!
�

�
�
�
�
�
�
�!
'�/tmp/phy.cal
�]��-�]��
�

���
�
'�/sys/wlangen.ini
��j�N�
�!
'�supportedrates.cfg
�˷�
��PPPPPP P@P�PS�
��

�.1
�!
'�/sys/macadd.bin
��q

��5V��2$�V>�	
�-���`D
�-���`H�L-���`PL
�-���`���L�-���`���-���`����.���-���`��-���`�
�-�	��`�
���.���
�-�	]���
�
���.����
��%
� �=.9
=
=
�
�!
'�/sys/macadd.bin
��q

��5V��2$�V>��	>
�
'�/sys/rxfltr.ini
�����N
�
'�/sys/rxfltr.ini
�����N�A
�
'�/sys/rxfltr.ini
�����N�A�A"�A�A�A�A�A�B�B
�!
'�/sys/httpsrv.cfg
�F�
��	�
�
P
�!
'�/sys/macadd.bin
��q

��5V��2$�V>�
�!
'�/sys/mdns.cfg
�[\-�[\
�
-�[\-�[\�-�	[\�
�B�B��B��A�A�A�B��A�A��
�!
'�/sys/macadd.bin
��q

��5V��2$�V>��P�:.
A
�!
'�/sys/p2p.cfg
�o�
��.7.
B.CP�.4".`
�C�
h�!@
'�/tmp/phy.cal
�]��-�]��
�
-�]���-�	]���
����	.mQR==�(
�!
'�supportedrates.cfg
�˷�
��
�!
'�supportedrates.cfg
�˷�
���
mmmmm�	�
�!
'�/sys/date_time.cfg
�
>(
��3�.'��.'��m...m.:.m.'..?4....*, de,.s*, ��,*, ,-*, 
�.q[��
s6)	
�.0

�!
'�/sys/stacfg.ini
�TU1
7.2�3-�TU
�
-�TUh-�	TU
�
h
K
J#
�
�!
'�/sys/pref.net
��-��
�
-��p-�	��
pR�S
{
�*"71�V�$��Z`7	\�;	
v"
w"
x"
y"
�"1  
�"
�"1
c"
�!
�!
�!�!�W�A��%�

'(#B#72�W
�)	f�
[��6f4)	f)	��
J#
�
�!
'�/sys/stacfg.ini
�TU-�TU
�
-�TUh-�	TU
�
hS�S[��6�)	�)	���!
�
�
'�/sys/pref.net
��-��
�
-��p-�	��
p
'S�S[��6�)	�)	��s{[��6�)	�71�[�$��q-?$�$�)	2�.e$e$�!
'�/sys/ipcfg.ini
���-���
�
-����-�	��
�
�[��62)	2)	��
C[��6�)	�)	���!
'�/sys/mode.cfg�

Fullscreen boardB.log Download

@�
� -�-1{�@	��	��
�
�	-�-1{�@
��F�V
�
�*��
�
�	�
�*� ��TT��*F*�33���e;^
�*� �X���E#
�	��
2
��
�
�!
'�/sys/servicepack.ucf
���`
�
-���`!-���`-���`@-���`8
�
�
�-�	��`�
��L�	�
�!
'�/sys/servicepack.ucf
���`
�
-���`!
�
�
�-���`�p��p�p�-�	��`�
�*�� *�� �*�	 H
�
�
��F��
j������
�
�
�
�
�
�
�

�	-�-1{�@
�
	
�>
�!
'�/sys/pmcfg.ini
�I�-�I�
�
-�I�
-�	I�
�


a"<b
�
�

�!
'�/sys/servicepack.ucf
���`
�
-���`!
�
-���`-���`@-���`8
�
�
�
�
�-���`�-�	��`�
��*�
�!
'�/sys/ipcfg.ini
���-���
�
-����-�	��
�
�
�!
'�/sys/mode.cfg
���I-���I
�
-���I-���I<-�	��I
�
P
Q
�
�7�`� �t7�`�l 97�`إ �7�`�� T7�`�� �7�`dI �7�`,i 7w@� 0w
2�`��	�
�
� 
f�	
g��	
�!
'�/sys/devname.cfg
��c
��	


�����.�c�	�
�!
'�/sys/servicepack.ucf
���`
�
-���`!
�

�
�
�
�
�
�
�!
'�/tmp/phy.cal
�]��-�]��
�

���
�
'�/sys/wlangen.ini
��j�N�
�!
'�supportedrates.cfg
�˷�
��PPPPPP P@P�PS�
��

�.1
�!
'�/sys/macadd.bin
��q

��5V�2$^;e	
�-���`D
�-���`H�L-���`PL
�-���`���L�-���`���-���`����.���-���`��-���`�
�-�	��`�
���.���
�-�	]���
�
���.����
��%
� �=.9
=
=
�
�!
'�/sys/macadd.bin
��q

��5V�2$^;e�	=
�
'�/sys/rxfltr.ini
�����N
�
'�/sys/rxfltr.ini
�����N�A
�
'�/sys/rxfltr.ini
�����N�A�A"�A�A�A�A�A�B�B
�!
'�/sys/httpsrv.cfg
�F�
��	�
�
P
�!
'�/sys/macadd.bin
��q

��5V�2$^;e
�!
'�/sys/mdns.cfg
�[\-�[\
�
-�[\-�[\�-�	[\�
�B�B��B��A�A�A�B��A�A��
�!
'�/sys/macadd.bin
��q

��5V�2$^;e�P�:.
A
�!
'�/sys/p2p.cfg
�o�
��.7.
B.CP�.4".`
�C�
h�!@
'�/tmp/phy.cal
�]��-�]��
�
-�]���-�	]���
����	.mQR==�(
�!
'�supportedrates.cfg
�˷�
��
�!
'�supportedrates.cfg
�˷�
���
mmmmm�	
�!
'�/sys/date_time.cfg
�
>(
��3�.'�.'�m...m.:.m.'..?4....*, de,.s*, ��,*, ,-*, 
.q[��
s6)	
.0

�!
'�/sys/stacfg.ini
�TU1
7.2�3-�TU
�
-�TUh-�	TU
�
h
K
J#
�
�!
'�/sys/pref.net
��-��
�
-��p-�	��
pR�S
{
#*"71�V�$��Z`7	\�;	
v"
w"
x"
y"
�"�  
�"
�"�
c"
�!
�!
�!�!�W�A��%�

'(#B#72�W
�)	f�
[��6f4)	f)	��
J#
�
�!
'�/sys/stacfg.ini
�TU-�TU
�
-�TUh-�	TU
�
hS�S[��6�)	�)	���!
�
�
'�/sys/pref.net
��-��
�
-��p-�	��
p
'S�S[��6�)	�)	��s{[��6�)	�71�[�$��q-?$�$�)	2�.e$e$�!
'�/sys/ipcfg.ini
���-���
�
-����-�	��
�
�[��62)	2)	��
C[��6�)	�)	���!
'�/sys/mode.cfg
���I-���I
�
-���I-���I<-�	��I
�
P.

0 Michael Reymond over 4 years ago in reply to user3970495

TI__Mastermind 40965 points

Hi,

Thanks for providing the NWP log files. Based on the timestamped log data, one specific step when starting the BoardA CC3100mod takes significantly longer than BoardB - from the timestamps it seems like the physical radio init takes ~1100ms on BoardA, vs. ~200ms on BoardB.

I will need to investigate further, and see what could be the cause of the radio init taking longer on the BoardA CC3100mod device.

Regards,

Michael

0 user3970495 over 4 years ago in reply to Michael Reymond

Prodigy 90 points

How is progress of investigate ?

>> physical radio init takes ~1100ms on BoardA

What are the factors that increase the “physical radio init” time?

Did you find more details in the logs we provided?

What kind of processing is “physical radio init” specifically?

0 Michael Reymond over 4 years ago in reply to user3970495

TI__Mastermind 40965 points

Hi,

The physical radio init, from the point of view of the CC3100 firmware code, is when the radio + its controller get initialized. In effect, just like how your main MCU sends sl_Start to the CC3100, the CC3100 will instruct the radio to initialize.

I am still in the process of investigating and I appreciate your patience.

Regards,

Michael

0 user3970495 over 4 years ago in reply to Michael Reymond

Prodigy 90 points

Could you please let me know if you have any updates on this matter?

And Could you please provide approximate dates of reporting the investigating results ?

Best Regards,

0 Michael Reymond over 4 years ago in reply to user3970495

TI__Mastermind 40965 points

Hi,

I have been working with our hardware support team as well as our R&D on your issue.

From the HW support team, there have been no revisions of the CC3100mod, and every unit should have the same BOM and design. This means that the startup time difference is not likely due to a physical HW issue with the devices. Just to confirm, each of the boards you are testing with are the same hardware, is that correct?

Now, I have been working with our R&D team to see what could be the delaying step in the FW init, as it does look like from the timestamp the radio init takes much longer on BoardA. However, they have not given me their conclusions on their investigation yet. I will update you next week when they have given me their thoughts.

Regards,

Michael

0 user3970495 over 4 years ago in reply to Michael Reymond

Prodigy 90 points

>>each of the boards you are testing with are the same hardware, is that correct?

Yes, they are the same design, same BOM.

If a part on the board fails/not working, does it affect the startup time?

If yes, please let me know the parts or signals etc on the board we should check.

0 Jan D over 4 years ago in reply to user3970495

Guru 79905 points

Hi,

Just a few hints/ideas:

It is a radio performance (RX/TX side RSSI) similar at all devices? If RSSI levels differs I will suspect soldering issue around RF output pin
Another idea is a issue with internal RTC XTAL stabilisation. Maybe XTAL was damaged by improper re-flow process.

Jan

0 Michael Reymond over 4 years ago in reply to Jan D

TI__Mastermind 40965 points

Hi,

It is not likely if a specific part fails that it will only delay the startup time of the CC3100 - a failure would either result in no impact, or the CC3100 not starting up at all.

That being said, Jan has some good suggestions for failures around the soldering, and not a specific part failure. Perhaps an inspection on the soldering work might reveal something.

Regards,
Michael

0 user3970495 over 4 years ago in reply to Michael Reymond

Prodigy 90 points

Thank you for reply.
I checked the reflow profile.
But there was no particular problem.
Also , I measured the initialization time of another board in the same lot as Board A.The initialization time was the same as that of Board B.
Please tell me if there are any other points that you should suspect.
What is the status of the analysis of NWP logs?

Regards,

0 Michael Reymond over 4 years ago in reply to user3970495

TI__Mastermind 40965 points

Hi,

The final NWP log analysis did not show any explanation for the unexpected behavior, simply that one of the radio initialization steps took extra time. There was no error, fault, or other unexpected operation of the CC3100.

Now, the startup time of the CC3100mod as expressed in the datasheet has been measured to be typically 1.35s. However, there is no max value or typical upper bound to the startup time as written. Thus, while Board A has a startup time ~0.5s longer than the other boards and ~1s longer than typical, this isn't out-of-spec or otherwise a fault by itself. Checking the NWP logs, there doesn't appear to be any further impact on the system besides the lengthened startup time.

If your testing shows no cause for the startup time difference in your HW, nor does your functional testing show any change in behavior other than the increase in startup time, then there unfortunately isn't much else to investigate. As the startup time is not out-of-spec, there isn't anything I can do further.

If you do discover further changes in behavior on Board A, such as if it does not interact with the host correctly anymore or if it later fails entirely, then please let me know. Otherwise I hope you understand our explanation of why the investigation has been concluded.

Regards,
Michael

0 user3970495 over 4 years ago in reply to Michael Reymond

Prodigy 90 points

Thank you for your cooperation.

>>simply that one of the radio initialization steps took extra time.

>> There was no error, fault, or other unexpected operation of the CC3100.

"There was no error", I get it. Thank you for analyzing.

Q1: About took extra time,

~~~

The following is described in the “cc3100mod.pdf” regarding the initialization time.

8.12.2.1 nHIB Timing Requirements

If temperature changes by more than 20°C, initialization time from HIB can increase by 200 ms due to radio calibration.

~~~

Would you please let me know if there are other specifications (factors) related to the startup time?

Q2: I plan to set the timeout of cc3100mod startup to 4 seconds on our device.

Is 4 seconds a reasonable time?

Best Regards,

/////////////////////////////////////////

+1 Michael Reymond over 4 years ago in reply to user3970495

TI__Mastermind 40965 points

Hi,

There are a variety of factors that can impact the startup time. For example, if you have auto-connect or fast-connect enabled, then the CC3100 will need to scan or directly probe for the AP that is programmed in its Wi-Fi profile. With new servicepacks, the size and quantity of patches that need to be copied and executed can also increase, lengthening startup time. This is why the value given in the datasheet is a typical number.

As for a timeout, sl_Start() actually has a built-in timeout, though it's set to 65535ms by default. Reducing this to 5-10 seconds would be reasonable.

Regards,

Michael

0 user3970495 over 4 years ago in reply to Michael Reymond

Prodigy 90 points

Thanks for your cooperation.
This resolved my issue.

Wi-Fi

Wi-Fi forum

CC3100MOD: Ther are individual differences in sl_Start() exexution time.