CC3235MODASF: Http client connect problem

Hey Frank,

Here are the steps to rebuild the http library from the command line:

1. Go to the source/ti/net directory in your CC32xx SDK install
2. Edit the following lines in the makefile from the net directory:

   1. @ $(XDC) XDCARGS="$(XDCARGS)" XDCPATH="$(XDCPATH)" all -PR . -> @ $(XDC) XDCARGS="$(XDCARGS)" XDCPATH="$(XDCPATH)" all -P http
      @ $(XDC) XDCARGS="$(XDCARGS)" XDCPATH="$(XDCPATH)" clean -PR . -> @ $(XDC) XDCARGS="$(XDCARGS)" XDCPATH="$(XDCPATH)" all -P http

3. In the net directory, run <path to XDC tools install>/gmake clean
4. Then run <path to XDC tools install>/gmake to rebuild the http library

Also, error code -688 corresponds to SL_ERROR_BSD_ESEC_ASN_NO_SIGNER_E which means the CC3235 failed to verify the server's certificate chain. Please verify that the server certificate chain is correct.

Regards,

Paul

I have change makefile as below

line 49: 
@ $(XDC) XDCARGS="$(XDCARGS)" XDCPATH="$(XDCPATH)" all -PR . -> @ $(XDC) XDCARGS="$(XDCARGS)" XDCPATH="$(XDCPATH)" all -P http
line 53:
@ $(XDC) XDCARGS="$(XDCARGS)" XDCPATH="$(XDCPATH)" clean -PR . -> @ $(XDC) XDCARGS="$(XDCARGS)" XDCPATH="$(XDCPATH)" all -P http

but when i run the cmd (C:\ti\xdctools_3_61_00_16_core\gmake clean) and (C:\ti\xdctools_3_61_00_16_core\gmake)
i get :
cleaning packages ...
C:/Users/Frank/AppData/Local/Temp/make39988-2.sh: 1: C:/Users/Frank/AppData/Local/Temp/make39988-2.sh: Syntax error: "(" unexpected
c:/ti/xdctools_3_61_00_16_core\packages\xdc\bld\xdc_top.mak:267: Warning: nothing to build; the directories named after -P[RrD] don't contain any buildable packages

-P
-Pr
-PR
-PD

Hey Frank,

Sorry for the confusion my explanation wasn't clear. I meant replace the line:

@ $(XDC) XDCARGS="$(XDCARGS)" XDCPATH="$(XDCPATH)" all -PR .

with

@ $(XDC) XDCARGS="$(XDCARGS)" XDCPATH="$(XDCPATH)" all -P http

And similarly, replace:

@ $(XDC) XDCARGS="$(XDCARGS)" XDCPATH="$(XDCPATH)" clean -PR .

with

@ $(XDC) XDCARGS="$(XDCARGS)" XDCPATH="$(XDCPATH)" clean -P http

Basically what you're doing here is telling it to build only the packages found in the http directory (-P http) instead of all packages found in all sub directories (-PR .).

Regards,

Paul

I change it as (@ $(XDC) XDCARGS="$(XDCARGS)" XDCPATH="$(XDCPATH)" all -P http) and (@ $(XDC) XDCARGS="$(XDCARGS)" XDCPATH="$(XDCPATH)" clean -P http).
But still get some error message.(as below)
When trying to make it work, I had run the cmd brfore edit, does it cause this message?

C:\ti\simplelink_cc32xx_sdk_4_10_00_07\source\ti\net>C:\ti\xdctools_3_61_00_16_core\gmake clean
cleaning packages ...
making clean: Tue Jul 7 13:38:25 2020 ...
======== clean [http/] ========
making package.mak (because of package.bld) in order to clean ...
js: "C:/ti/simplelink_cc32xx_sdk_4_10_00_07/kernel/tirtos/packages/gnu/targets/arm/ITarget.xs", line 364: Error: Directory 'c:/ti/ccs1000/ccs/tools/compiler/gcc-arm-none-eabi-9-2019-q4-major-win32/bin' cannot be found. Ensure that rootDir for the M4 target is set correctly in 'C:/ti/simplelink_cc32xx_sdk_4_10_00_07/source/ti/net/ns.bld'.
"C:/ti/simplelink_cc32xx_sdk_4_10_00_07/kernel/tirtos/packages/gnu/targets/arm/_utils.xs", line 31
"C:/ti/simplelink_cc32xx_sdk_4_10_00_07/kernel/tirtos/packages/gnu/targets/arm/ITarget.xs", line 184
gmake[1]: *** Deleting file 'package.mak'
making package.mak (because of package.bld) in order to clean ...
js: "C:/ti/simplelink_cc32xx_sdk_4_10_00_07/kernel/tirtos/packages/gnu/targets/arm/ITarget.xs", line 364: Error: Directory 'c:/ti/ccs1000/ccs/tools/compiler/gcc-arm-none-eabi-9-2019-q4-major-win32/bin' cannot be found. Ensure that rootDir for the M4 target is set correctly in 'C:/ti/simplelink_cc32xx_sdk_4_10_00_07/source/ti/net/ns.bld'.
"C:/ti/simplelink_cc32xx_sdk_4_10_00_07/kernel/tirtos/packages/gnu/targets/arm/_utils.xs", line 31
"C:/ti/simplelink_cc32xx_sdk_4_10_00_07/kernel/tirtos/packages/gnu/targets/arm/ITarget.xs", line 184
gmake[1]: *** Deleting file 'package.mak'
cleaning complete: Tue Jul 7 13:38:29 2020.

C:\ti\simplelink_cc32xx_sdk_4_10_00_07\source\ti\net>C:\ti\xdctools_3_61_00_16_core\gmake
building packages ...
making all: Tue Jul 7 13:38:41 2020 ...
======== .interfaces [http/] ========
making package.mak (because of package.bld) ...
js: "C:/ti/simplelink_cc32xx_sdk_4_10_00_07/kernel/tirtos/packages/gnu/targets/arm/ITarget.xs", line 364: Error: Directory 'c:/ti/ccs1000/ccs/tools/compiler/gcc-arm-none-eabi-9-2019-q4-major-win32/bin' cannot be found. Ensure that rootDir for the M4 target is set correctly in 'C:/ti/simplelink_cc32xx_sdk_4_10_00_07/source/ti/net/ns.bld'.
"C:/ti/simplelink_cc32xx_sdk_4_10_00_07/kernel/tirtos/packages/gnu/targets/arm/_utils.xs", line 31
"C:/ti/simplelink_cc32xx_sdk_4_10_00_07/kernel/tirtos/packages/gnu/targets/arm/ITarget.xs", line 184
gmake[1]: *** Deleting file 'package.mak'
gmake[1]: *** No rule to make target 'package.mak', needed by '.interfaces'. Stop.
xdctools_3_61_00_16_core\gmake.exe: *** [c:/ti/xdctools_3_61_00_16_core\packages\xdc\bld\xdc_top.mak:389: http/,.interfaces] Error 2
gmake: *** [makefile:49: all] Error 2

Hi Paul,

I followed your steps and rebuild the library successfully, but i still get some strange behavior about the library i build.
I can connect a http server by the old lib, and get some message back by both of post and get function.
But if using the new lib i build, it will running into a while loop function(faultISR(), line 193 in startup_cc32xx_ccs.c) after calling HTTPClient_connect().
The most strange thing is it run perfect at get function. But there wasn't any different between post and get at the time calling HTTPClient_connect().

And i try to build library as lots of type as below, and all of them get the same situation.
  1.  Change CCS_ARMCOMPILER        ?= c:/ti/ccs1000/ccs/tools/compiler/ti-cgt-arm_20.2.0.LTS in imports.mak
        to          CCS_ARMCOMPILER        ?= c:/ti/ccs1000/ccs/tools/compiler/ti-cgt-arm_20.2.1.LTS

  2.  Change IAR_ARMCOMPILER        ?= c:/Program Files (x86)/IAR Systems/Embedded Workbench 8.4/arm  in imports.mak    (The IAR vession i have is 8.3)
       to          IAR_ARMCOMPILER        ?= c:/Program Files (x86)/IAR Systems/Embedded Workbench 8.3/arm 
  3.  Change both 1. and 2. in imports.mak
  4.  Using original imports.mak
  5.  Using makefile withch is change as you told
  6.  Using original makefile

Hey Frank,

I'm glad you were able to rebuild the libraries!

I've rebuilt the default HTTP library from the SDK on my end and it seems to work correctly. Have you made any changes to the HTTP source code? If so, what exactly did you modify?

Also you mentioned in your original post you were unable to connect to your HTTP server and you were receiving error code -688. However in your last reply you mentioned being able to successfully connect to the server. Were you able to resolve the -688 error code issue you were having?

Regards,
Paul

Hi Paul,

I only change HTTPClient_DOMAIN_BUFLEN from 100 to 2048 in httpclient.h.

I have 3 steps on http client:
  1.  Connect to server A, do get request, disconnect, destroy
  2.  Connect to server A, do post request, disconnect, destroy
  3.  Connect to server B, do get request, disconnect, destroy (server B's url length >1KB and < 2KB)
The error -688 is happen at step 3 when using original lib. And step 1 and 2 run good.

But when i using the new lib(HTTPClient_DOMAIN_BUFLEN  changed to 2048), step 1 run still good.
Step 2 will run into a while loop function(faultISR(), line 193 in startup_cc32xx_ccs.c) at the time calling HTTPClient_connect();
This is a strange thing, even if i skip step 1, i still can't connect to server A. It runs good when using original lib, even skip step 1.
Because server B is getting from step 2, i couldn't try setp 3.

I am running the same code, the only difference is the lib(I rebuild whole the project after changing lib).

By the way, dose i have to change the stack size for sl thread?

pthread_attr_init(&pthreadAttrs);
// sl thread
priParam.sched_priority = 1;
status = pthread_attr_setschedparam(&pthreadAttrs, &priParam);
status = pthread_attr_setstacksize(&pthreadAttrs, 2048);
status = pthread_create(&threadArray[df_SL_THREAD], &pthreadAttrs, sl_Task, NULL);
// aws thread
priParam.sched_priority = 1;
status = pthread_attr_setschedparam(&pthreadAttrs, &priParam);
status = pthread_attr_setstacksize(&pthreadAttrs, 0x4000); //3328);  change HTTPClient_DOMAIN_BUFLEN from 100 to 2048
status = pthread_create(&threadArray[df_AWS_THREAD], &pthreadAttrs, awsThreadFxn, NULL);

Hey Frank,

Thank you for clarifying your set up.

I wouldn't think you need to change the stack size of sl_task as this thread only handles asynchronous events sent from the NWP. My guess is when you call HTTPClient_connect it's failing to allocate enough memory for the increased buffer size which is why you're seeing a hard fault. Does increasing the stack size of your aws thread not fix this issue?

As for the original error you were seeing SL_ERROR_BSD_ESEC_ASN_NO_SIGNER_E (-688) indicates that a certificate in the certificate chain could not be verified because the CA programmed to the file system is not the CA that signed the chain. What root CA cert are you providing to the CC3235SF for server B?

To find the Common Name of the root CA expected to verify the certificate by the device, you can add the SL_SSL_NOTIFICATION_WRONG_ROOT_CA case to the socket event handler. When this event occurs, the name can be found in SocketAsyncEvent.EventData.extraInfo.

Regards,
Paul