CC3120: Unable to do provisioning on CC3120-BOOST while using TMS570LS043 microcontroller launchpad

Hi Michael,

Thanks for your inputs. Here are my further comments & questions.

A) I believe that I was able to connect to the CC3120 device earlier due the out-of-box service pack image existing on it. I am not sure if we can say sl_start(), etc. are working since there was no host driver coded on my mC. Wanted to confirm that with you

B) I could not change the mode using the web-browser connection. It got automatically reverted to AP mode

C) Porting the CC3220 code to TMS570 mC looks like a task. I tried to run the OOB CC3220 demo provided. I was unable to load it to TMS570 because of endian difference between the two.

D) Also, the document describes a file called "user.h" which needs to be modified for porting. Would this file be indirectly used by this demo? 

E) The document talks about Communication layer (SPI/UART) which needs to be implemented for the specific mC. Does it mean that we will have write the entire code to create these functionalities for other mCs?

Request to kindly address these queries.

Regards,

Navin

Hi Navin,

Yes, the CC3120 by default will start up in AP mode. However, I'm surprised it started up at all given that you mention you don't have the host driver running on your host. Usually, the host driver will handle starting the CC3120, and without it deasserting the nReset and nHib signals the CC3120 will not start.

You will need to port the CC3120 host driver to the TMS570. You shouldn't try to port a CC3220 demo directly, since the CC3220 version of the host driver has some adjustments and optimizations that are unique to it since the host and CC3xxx NWP are on the same chip. Instead, you should use an example from the CC3120 plugin and then port it to your device. See this thread for more information:

https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/p/830940/3074608#3074608

The bulk of the porting process should just be modifying the user.h, the cc_pal.c/.h files. Part of that would be to implement the SPI or UART functions that the host driver needs. You can take a look a the existing porting files in the CC3120 plugin as an example of how to implement those functions.

Regards,

Michael

Hi Michael,

Thanks for your answer. Been working on this & have some more queries. On your query, apparently, device turns on when I physically use reset switch on booster.

Also, a quick recap, am trying to test provisioning using CC3120-booster on TMS570LS043x.

1) I need to create host drivers on a TMS570 project (only then I can load it on mC using CCS). At a project level, there are multiple CC3120 files (provisioning) on the project such as .cmd file, board.h files. Is there a need to modify these files to successfully compile the project? No mention of project level changes for porting to another mC (other than MSP430) available.

2) Also, when I use CC3120 host drivers on a TMS570 project, I am facing endian issue. CC3120 driver code is little endian, whereas TMS570 is big endian.

I get this error "object files have incompatible byte orderings". Especially, on these two files - "display.aem4<DisplayUart.oem4>" = little endian and ti_drivers_net_wifi_config.obj = big endian. How do I resolve the endian difference to at least successfully compile the project? The programming guide mentions it supports both little endian & big endian mC on SPI mode. 

3) Regarding SPI interface porting, TMS570LS doesn't have DMA functionality, can I implement the interface using the normal SPI transfer? In this case, what should be the code in _ifopen & _ifclose?

Regards,

Navin

Hi Michael,

Just to add. My above question pertains to the fact that apart from the interface porting (SPI), there seems to be some project level porting required.

Many of the libraries that I have used from the CC3120 (or MSP432) SDK doesn't seem to be compatible with TMS570 project, along with the endian difference.

Is there a documentation around this project level porting?

Regards,

Navin

Hi Navin,

All of the libraries in the CC3120 plugin are built with the little-endian ARM Cortex M4 as the target platform. If you using a different endianness or architecture, you will need to rebuild all of the libraries with your architecture's toolchain. 

While most of the libraries are provided precompiled for you, you should be able to rebuild all of them from their respective make files and CCS projects. In the CC3120 plugin there should be the full source for every TI library included.

However, there are many libraries to rebuild and potentially debug. For you, it would most likely make much more sense to just port as little as possible, in effect just the host driver. In porting application code, you should take just the sl_*() API calls from the examples you are looking at. All secondary functionality such as the printing functions from the display.oem4 lilbrary should be replaced with functions native to your platform.

To go answer your questions more specifically:

1. Given the differences in architecture and libraries, you should focus on only porting the host driver. When doing so, you only need to modify the porting files I mentioned in my previous post. The board.h, the .cmd file and such are all platform-specific and don't need to be ported over. Instead, you should use code with similar functionality if needed from your native SDK.
2. Again, you don't need those ancillary support libraries to run the CC3120. It would be best if you took only the host driver, and then used native TMS570 libraries from its SDK for the other functionality of the demos.
3. Yes, you can use non-DMA SPI. DMA is used to make transfers more efficient, but if the TMS570 does not support using it with its SPI peripheral then you can use non-DMA SPI. The code in ifopen and ifclose should be whatever code is needed for the TMS570 to initialize, pinmux, and logically open/close the SPI interface so that the ifwrite and ifread can work.

Regards,

Michael

Hi Michael,

Thanks for your reply. It makes a lot of sense to me now and was able to make significant progress. I am ready with the porting files required for the mC as per your inputs.

As you had suggested, I imported only the host driver of CC3220 into the TMS570 project. However, I am facing the following two issues-

a) I still seem to have endian compatibility issues. The files within the host drivers also seem to have different endianness.

----------Error below
object files have incompatible byte orderings ("../Host drivers/ti/drivers/net/wifi/ccs/rtos/simplelink/simplelink.a<cc_pal.obj>" = little endian, "./Host drivers/ti/drivers/net/wifi/slnetif/slnetifwifi.obj" = big endian) null: object files have incompatible byte orderings ("../Host drivers/ti/drivers/net/wifi/ccs/rtos/simplelink/simplelink.a<cc_pal.obj>" = little endian, "./Host drivers/ti/drivers/net/wifi/slnetif/slnetifwifi.obj" = big endian) Assert-Deassert C/C++ Problem

-----------

b) There are few unresolved symbols & I am not sure which linker file to add for this.

--------Error below

Description Resource Path Location Type
unresolved symbol MutexP_create, first referenced in ./Host Trial C/C++ Problem

----------

Regards,

Navin 

Hi Michael,

I seem to be facing unresolved symbol issue only for the posix (.c) & freertos kernal files, though I have added them as include files.

I guess I need to add a linker file (library) in addition to adding include files. However, I am not able to figure out where the library file is. 

Also, in case that library file is simplelink.a. I believe it needs to be modified to make it big-endian and make further changes if any.

Request you to kindly guide me.

Regards,

Navin 

Hi Navin,

The needed mutex/semaphore functions for the SimpleLink host driver should be ported from your TMS device's RTOS or similar. You should have examples in the TMS SDK that demonstrate the use of its native RTOS objects. You should use those in the cc_pal files instead of trying to find and implement the RTOS objects that are used by the platforms supported in the CC3120 SDK.

You will need to rebuild the SimpleLink host driver library. There is are CCS projects provided within the plugin release, at /source/ti/drivers/net/wifi/ccs. Once you import that, you will need to adjust the build target to your TMS device and make the needed endianness changes. Once that is done, you will be able to build a simplelink.a library that will work with your platform.

Regards,

Michael