• State Resolved
  • Locked Locked
  • Replies 22 replies
  • Subscribers 41 subscribers
  • Views 1481 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

BOOSTXL-CC3135: No Cmd Ack detected when using WLAN_NORMAL_POLICY

ghada dhibi
Intellectual 520 points

Part Number: BOOSTXL-CC3135
Other Parts Discussed in Thread: CC3135, CC3220SF, , CC3220S

Hi, 

I am using STM32L4 microcontroller and the BOOSTXL-CC3135 WIFI module interfaced through SPI, 

I have successfully ported the CC3135 driver that I found in the simplelink_sdk_wifi_plugin_2_40_00_22, and I used the DPL source files that I found under the simplelink_cc32xx_sdk_3_30_01_02\kernel\freertos\dpl SDK to interface the CC3135 module with FreeRTOS, 

Note that in my STM32 application, I am using the FreeRTOS V10.0.1, and IAR embedded workbench(8.22.1)

As a result, I can successfully start the CC3135 module in STA mode, Connect to an access point, and use the MQTT library to publish and subscribe to topics. 

I have a little strange behavior in my application, and it appears in this case: 

  • The system Core Clock of the host is equal to 120 (and  my SPI frequency is equal to 15MHz) 
  • and the Power Manage Policy is a Normal Policy (default and desired policy). 

In fact, the behavior is random and can be summarized that the MQTT library does no longer works correctly, and that after a certain time I would get the following error message "[ERROR] - FATAL ERROR: No Cmd Ack detected [cmd opcode = 0x84b7] " 

I have resolved the problem with different ways: 

  1. When I use  System Core clock equal to 80 MHz, with the same SPI frequency (15 MHz) 
  2. By putting a delay of 1 ms after each assertion of CS pin (and before transmission or a reception from SPI lines ) 
  3. By changing the Power manage Policy from SL_WLAN_NORMAL_POLICY to SL_WLAN_ALWAYS_ON_POLICY. 

I am almost certain that my issue is not SPI or GPIOs configuration, I already visualized signals and they are OK. 

I think that the CC3135 module was in a certain mode that does not wake up and received frame that I send from SPI, that's why maybe a delay between assertion CS and transmitting frame let the CC3135 wakes up from a low power mode. 

So, my questions are : 

  • Is there another host frequency requirement? apart from the frequency of SPI interface ? maybe it does support that my host is working with 120 MHz ? (note that I changed to 100 MHz and still not working)
  • When Using the SL_WLAN_NORMAL_POLICY , is there a minimum required time to wake up from the sleep mode ? 
  • How can I configure the CC3135 module to works with a host that uses 120 MHz as a system frequency and 15MHz as SPI frequency, using a SL_WLAN_NORMAL_POLICY  power manage policy and without putting delay ? 

Best regards, 

Ghada 

  • 0 in reply to Vincent Rodriguez
    Intellectual 520 points

    Hi , 

    Thank you for your response, 

    In the link you described to me in your answer, it says that I should add line of code in CC3220SF_LAUNCHXL_initGeneral() function. (Step 1) 

    I can not add this line code, because I don't have CC3220SF_LAUNCHXL.c file (neither CC3220S_LAUNCHXL.c). In fact, I am using the BOOSTXL-CC3135 module interfaced with an STM32 board, and I have ported the mqtt-client example code into. 

    So, I ignored this step and I have connected the CC_NWP_UART_TX pin ( pin number 34 of the connector P4) to an FTDI cable (RX pin of C232HD) . 

    Using Putty terminal, I saved the log file as described and I have run the code that manifests the bug, i.e.: 

    • The system Core Clock of the host is equal to 120 (and  my SPI frequency is equal to 15MHz) 
    • and the Power Manage Policy is a Normal Policy (default and desired policy). 

    My log file is not readable, and I hope that it help you to analyse the problem. 

    You will find attached the log file. 

    Regards. 

    Ghada 

    Fullscreen 5657.putty.log Download 
    =~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2020.02.19 10:29:30 =~=~=~=~=~=~=~=~=~=~=~=

� -����{�(�(�-	9

�
�	-����{�( LS
�
�
�
��%
�
'�/sys/fips.cfg
��:��Ve(�Ze(-
�!
'�/sys/certstore.lst
��J
�

�
-��J-��J�-�	�J��
��u)
�*��1
�
�	�
�*� ! {�A��
W*�""�4-��
�*� �����1��
�	��
�)
��
�)
�
�
'�/sys/servicepack.ucf
���`
�
 ^ B
�!
'�/sys/ucf_signatures.bin
��Ql-��Ql-��Ql4-��Ql4T-�	�Ql��
�
�!
'�/sys/servicepack.ucf
���`
�
-���`!-���`-���`x-���`p
�
�
�
�
�
�
�
�
�
�
�
�
�
���1	�
�!
'�/sys/mode.cfg
���I-���I-���I4-���I4�-�	��I
��-���`L9�$��$�$
�*�@ *�Q �$*�\v 
�
�
��RG�
WG�[G-�	��`�^
��
]L)��`aaA	9	�)����{�(	�!
'�/sys/certstore.lst	��J	�
	�
)��J	�)��J�)�	�J��	�
'�/sys/fips.cfg	��:��We(�[e(`aaA			�
'�/tmp/crashminidump.bin	��+�1��1��1��	�!
'�/sys/mdmpcfg.ini	��I��ye(	�!
'�/sys/pmcfg.ini	�I�)�I�	�)�I�4)�I�4
)�	I�	�>	a"<b	�	�
	�	�
'�/sys/servicepack.ucf	���`	�
 ^ B	�!
'�/sys/ucf_signatures.bin	��Ql)��Ql	�)��Ql4)��Ql4T)�	�Ql��	�	�!
'�/sys/servicepack.ucf	���`	�
)���`!	�)���`)���`x)���`p	�	�	�	�	�	�	�	�)���`�	�)�1	�!
'�/sys/ipcfg.ini	���)���	�)���4)���4�)�	���$	�!
'�/sys/mode.cfg	���I)���I	�)���I4)���I4�)�	��I	��	Q
	�	�1�`  �1�` 	 @M1�``V H1�`�k l1�`{ ��1�`� � 1�`T' `1w@  �)	1�`�	�		�	� 	f	�		g	�!
'�/sys/fips.cfg	��:��ye(/-	�	�		�!
'�/sys/devname.cfg	��c)��c	�)��c4)��c4b)�	�c	��			
	
	�	�	�	�	�)�G�	�			�	�	�	���5	�!
'�/sys/phypwr.cal	�e�A�ye(	8	�	�	�	P	P	P	P	P	P 	P@	P�PS�	
	�	�		
	�)1	�!
'�/sys/macadd.bin	��q
�ye(	5	V4	2$��-		
	�	�!
'�/sys/naptlv.bin	�2<�ye(D)���`|	�)���`��)���`�	�	�)���`�	�	�	�)���`���#)���`��#	�	�)��#	�)���`t/	�x)���`|/x	�)�	��`�^	�	�	�	�)�x	�	�(	�	��	5%	�	�	�	�)��(	�	�	�	�	�)(��	����	� 	�	:		)	
;�
��
�	
;l 	L
	L
	�	�	�	;	�
'�/sys/rxfltr.ini	�����We(�[e(	�
'�/sys/rxfltr.ini	�����We(�[e(�A	�
'�/sys/rxfltr.ini	�����We(�[e(�A�A"�A�A�A�A�A�A�B�B			�!
'�/sys/mdns.cfg	�[\�ye(B�B��B��A�A�A�B��	�)C	
<		�!)`
'�/sys/p2p.cfg	�o��ye(	
	�	=:A	�		Q%�,)h <��!��		
?		�!
'�/sys/httpsrv.cfg	�F�)�F�	�)�F�4)�F�4��!+
'�/sys/phybg.cal	��^�)�	)�	)�	)��^�	�)��^�t)�	�^��t�t	�
	<	)				=	=	�		(	�	
�	W	�!
'�/sys/date_time.cfg	�
>()�
>(	�)�
>(4)�
>(44)�	
>(	�h3�)'4)'4).)):))'))?4)))r), de��), ����), ,-��), ��
Z)i1`aaA	s	6	)	
Z)0	�!
'�/sys/stacfg.ini	�TU17)2�)W$Vx�e.
�\��)[��ܼͫͫ�)[ � �  �)�TU	�	3)�TU4)�TU4�)�	TU	��	K	J#	�#	�!
'�/sys/pref.net	���ye(	�!
'�/tmp/chanhist.tbl	���)���	�)���P1A:�oD�)����)�	���H�����O�$#(aR�SS1"	{
]A	")	��		
	6�)	�)�	F���	�	�	�	 	�	�	�	�	 	�		�	�P	�P�:	 		**"*")[��ͫܽͫ�[00�)	��6�0)	�)[0�w0�w�	�!
'�/sys/fips.cfg	��:��ye()	f�6f)	f)	3�	�!
'�/sys/macadd.bin	��q
�ye(	5	V4	2$��-63)	3)[�)[�)	��!NB�!NB�1��x������������1����������<����1������2��������	�"TIME	�Iqx�G(a!�`G�����O�$#!!"!"!"!"!$1#ATIME	T	�	�)T	6�)	�)[��ͫܽͫ�[�	) 	.$TIME	r	)"++)/#����	0#TIME(aA�TIME$a1%�TIME#>�	=	z	.$TIME	H		.$Bbox	r	)"++)/#����	0#Bbox>�	=	.$TIME	r	)"++)/#����	0#TIME(aA�TIME$a1%�TIME>�	=	.$TIME	r	)"++)/#����	0#TIME(aA�TIME$a1%�TIME>�	=	.$TIME	r	)"++)/#����	0#TIME(aA�TIME$a1%�TIME>�	=		r&&	)"00!1�TIME# �1�TIME �1�TIME �1�TIME �(a4��
"��>�	=	�		8#TIME	�	L$TIME	M4��
"��97!�`G	q	 	�	
		�	
	�	�			�	�	>�	=	 $)���)��	r	)	#	�)V|� ;	T	r	)",,	�>�	=)]"<)�"	Z" 	�		�)E	�	�	!)"$��1.)#�����))	)?"q	r""	)"7>�	=)))=	))0)1 	�	!	r!!>�	=	r  >�	=	r>�	=	,	r	)">�	=97!�`G), eg`��), -.`��!�`G	 #y��)��	 y	*	.$TIME?"�	r""	)"	 #c��)��	 c>�	=		!�`G	�	*>�	=	5	�	RA"	�".��TIME6�L)	�	�	L$TIME	M� !�`�1��0!� K� 1�@�� �ˀ(a
!�����V�$#1��!�b!�`G	), ���), gh���), .4���), ���), hi���), 4.���	r���!�!p)	�!

'�/tmp/chanhist.tbl	���	!)) )���	�)���P	�	)	�	�	-	G$TIME	H$	I$	J$��1	K.	�)F)����)1A:�)�)���)-)����)���9)�	���H)]"<)�"	Z"d	N$�
'	)]"<)�"	Z"d)]"<)�"	Z"d�
�	.$TIME))]"<)�"	Z"d	(
	N$		.$TIME)]"<)�"	Z"d	(
�!	)w��)�$����������	�$���1�`��P'�Q)!1�`��	�)[ � �  �6%�)	%1��0!� K�!
'�/sys/dhcp.bin	�y
)0
�
')/�
�1�@��@81�b���H�4-��!
'�/tmp/table.arp	�l�%)P
)�l�%	�)�l�%4)�l�%4�)�	l�%��1��d1�@��)�y
	�)�y
4)�y
4�)�	y
��1���1�������1��.1������Q1����P'���1������`Tꁨ�	�
!�A��)]"<)�"	Z"d)3)2�"B�	
	�
�)]"<)�"	Z"d	�	�)	3�63)	3)[��ܼͫͫ�)[�)[� 	H ()I �a hb =����)J @�C )K (� � 	L	l�%��1��d1�@��)�y
	�)�y
4)�y
4�)�	y
��1���1�������1��.1������Q1����P'���1������`Tꁨ�	�
!�A��)]"<)�"	Z"d)3)2�"B�	
	�
�)]"<)�"	Z"d	�	�)	3�63)	3)[��ܼͫͫ�)[�)[�)(�a 	H ()I �a hb =����)J @�C )K (� � 	L12bX� X� 1(��D9 1(�(� 1(����* 1(�

T� 1(�\D� 1(��<� 1(��4� 1(��,� 1(��$� 1(��� 1(��� 1(��| 1(��x 1(���s 1(���o 1(���k 1(���g 1(���c 1(���_ 1(���[ 1(���W 1(���S 1(����M 1(�t�- 1(�HP% 1(�
h� 1(�l�� 11�l�d�� �

  • 0 in reply to ghada dhibi
    TI__Mastermind 28285 points

    Ghada,

    It looks like the NWP doesn't see you send the 0x84b7 command (DeviceSet()) command. Can you verify that this error code always occurs, and then find where in your code this command is getting called from? 

    I would suggest continuing the debug there to understand what power modes your device is in right before calling this, and if you there is bad behavior occuring. 

    Lastly, can you share your user.h file so i can verify your mapping?

    THanks,

    Vince 

  • 0 in reply to Vincent Rodriguez
    Intellectual 520 points

    Hi Vincent, 

    Yes, I think also that the NWP doesn't see my deviceSet command, this error code occurs very frequently. 

    In fact, the DeviceSet function is called before connecting MQTT client to broker, and used as below: 

      SlDateTime_t dateTime = {0};
  dateTime.tm_day = (uint32_t)DAY;
  dateTime.tm_mon = (uint32_t)MONTH;
  dateTime.tm_year = (uint32_t)YEAR;
  dateTime.tm_hour = (uint32_t)HOUR;
  dateTime.tm_min = (uint32_t)MINUTES;
  dateTime.tm_sec = (uint32_t)SEC;
  sl_DeviceSet(SL_DEVICE_GENERAL, SL_DEVICE_GENERAL_DATE_TIME,
               sizeof(SlDateTime_t), (uint8_t *)(&dateTime));

    I have ignored this function call, as I am using mqtt in a non secured communication (no TLS), and unfortunately, the problem has just been created in another function: "sl_WlanGet", in fact, below the screenshot of my IAR when the problem occurs in the sl_WlanGet function (this function is called by the MQTT Library in the MQTTClient_connect procedure ) 

    and in this case, the error message is : "[ERROR] - FATAL ERROR: No Cmd Ack detected [cmd opcode = 0x8cb6] " and the 0x8CB6 represents the SL_OPCODE_WLAN_CFG_GET value. 

    So I don't think that the error becomes from the use of the sl_DeviceSet function, neither sl_WlanGet. It seems that the NWP is not able to receive my command when my host is working with 120MHz and the NWP is in a Normal policy. 

    Also, I have checked the Power Manage Policy that I am using, with this code that I have added just after the sl_start function: 

        int ret;
    _u8 Policy = 0xFF;
    int length = 0 ; 
    SlWlanPmPolicyParams_t newPmPolicyParams;
    length = sizeof(newPmPolicyParams);
    ret = sl_WlanPolicyGet(SL_WLAN_POLICY_PM ,&Policy,(_u8*)&newPmPolicyParams,(_u8*)&length);

    The Policy value is always equal to 0 and it represents the SL_WLAN_NORMAL_POLICY (the default one) . 

    You can find attached my user.h file. 

    Best Regards, 

    Ghada 

    5001.user.h

  • 0 in reply to ghada dhibi
    Intellectual 520 points

    Hi , 

    It's been a week that I have not received any feedback from you or from TI support.

    Can you help me please ? 

    Regards, 

    Ghada 

  • 0 in reply to ghada dhibi
    TI__Mastermind 28285 points

    Ghada,

    This sounds like a clocking issue with your STM device. Can you verify you're SPI port is 20 MHz or lower going to our device?

    Best Regards,
    Vince 

  • 0 in reply to Vincent Rodriguez
    Intellectual 520 points

    Hi Vincent, 

    Thank you for your response, 

    My SPI frequency is 15 MHz, I am using 120 MHz as a system Core clock and prescaler 8 for the SPI. 

    Note that I have lowered the frequency until 3.75 MHz and the issue still occurs. and it disappears only with one of ways that I have described in the ticket description. 

    Best Regards,
    Ghada 

  • 0 in reply to ghada dhibi
    TI__Mastermind 28285 points

    Ghada,

    Do you have a way of measuring this clk signal coming from the pin to verify?

    BR,

    Vince 

  • 0 in reply to Vincent Rodriguez
    Intellectual 520 points

    Hi Vincent, 

    You will find attached the clk signal measured from the BOOSXL_CC3135. 

    Regards, 

    Ghada 

  • 0 in reply to ghada dhibi
    TI__Mastermind 28285 points

    Ghada,

     in your User.h, what do you have defined for #define SL_TIMESTAMP_TICKS_IN_10_MILLISECONDS     (10000/ClockP_getSystemTickPeriod())

  • 0 in reply to Vincent Rodriguez
    Intellectual 520 points

    Hi Viencent, 

    I defined it as below : 

    #define SL_TIMESTAMP_TICKS_IN_10_MILLISECONDS     (_u32)(10) 

    My host generates a systick interrupt every 1ms, and it's clock frequency is 120MHz

    Regards, 

    Ghada 

  • 0 in reply to ghada dhibi
    TI__Mastermind 28285 points

    Ghada,

    This needs to dynamic based off the clock frequency. Are you updating this when you change to 80 mhz?

  • 0 in reply to Vincent Rodriguez
    Intellectual 520 points

    No, I didn't change it because my systick interrupt is generated every 1ms, even if I am working with 80MHz. 

    Ghada 

  • 0 in reply to Vincent Rodriguez
    TI__Mastermind 28285 points

    Also Try defining this: 

    /* #define CPU_FREQ_IN_MHZ        80 */
    With your CPU Freq and rebuild.
    BR,
    VInce 
  • 0 in reply to Vincent Rodriguez
    Intellectual 520 points

    Ok I will define and test it. 

    But the #define CPU_FREQ_IN_MHZ   is only defined in user.h and driver.h files and is not used in any driver source file! 

    Note that I am using the CC3135 driver code source that I found under simplelink_sdk_wifi_plugin_2_40_00_22. 

    Ghada

  • 0 in reply to ghada dhibi
    TI__Mastermind 28285 points

    Ghada,

    You could also look at taking the host driver from our latest CC32xx SDK. This gets updated much more regularly than the CC31xx plugin.

    BR,

    Vince 

  • 0 in reply to Vincent Rodriguez
    Intellectual 520 points

    Hi Vince, 

    I have updated the latest CC32xx SDK driver (3_40_00_05): 

    - I updated the host driver 

    - I updated the CC3135 embedded service pack . 

    The behavior still occurs ( No Ack detected ) when I ignore the HAL_Delay. 

    In addition, the #define CPU_FREQ_IN_MHZ  (that you recommended to add)  is only defined in user.h and driver.h files and is not used in any driver source file even in the latest SDK driver. 

    Regards, 

    Ghada. 

      

  • 0 in reply to ghada dhibi
    TI__Mastermind 28285 points

    Ghada,

    What do you mean when you ignore the HAL delay?


    BR,

    Vince

  • 0 in reply to Vincent Rodriguez
    Intellectual 520 points

    Hi Vince, 

    It means that when I did not put a delay of 1 ms after each assertion of CS pin and before transmission or a reception from SPI lines . 

    Best regards. 

    Ghada 

  • 0 in reply to ghada dhibi
    TI__Mastermind 28285 points

    Ghada,

    Can you place this delay only on your transmissions, and not on the reception? Does the issue go away?

    BR,

    Vince 

  • 0 in reply to Vincent Rodriguez
    Intellectual 520 points

    Hi Vince, 

    I tried to place it only only in transmissions (and only in reception as a second test ) and it still occurs. 

    After severed tests, the behavior still occurs but it becomes less frequent and this since I have used the latest SDK Driver. 

    B.R. 

    Ghada. 

  • 0 in reply to ghada dhibi
    TI__Mastermind 28285 points

    Ghada,

    The only thing i can think of is some oddities in STM SPI library that is causing issues. Is adding the delay a acceptable solution? If not, then we would need to look at the spi traffic and verify where the issue is. Could capture logic captures of all spi transmissions when you encounter the error?

    BR,

    Vince