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.

CC3120BOOST: More Incorrect doc.

Part Number: CC3120BOOST
Other Parts Discussed in Thread: CC3120, SYSCONFIG

Hello,

Regarding this page in the "Academy"

http://dev.ti.com/tirex/explore/content/simplelink_academy_wifiplugin_2_40_00_17/modules/sdk_plugins/cc3120_boosterpack_oobe/cc3120_boosterpack_oobe.html

Specifically steps 3 and 4.

Step 3: I entered my local WiFi settings.  However the device is STILL in AP mode and my tablet remains connected to it...

Step 4: says to ping... I can tell it to ping itself, and that works find.  But part 3 says ping the connected device by looking under the "Station" tab.   Well the "Station" TAB only has my MAC address listed.

However, under the STATUS tab, Stations SECTION, it does show an IP address.  It tells me the station is 192.168.1.101

And another HOWEVER, this IP address is NOT what was assigned to my device.

The CC3120 is 10.123.45.1  and it assigned my tablet 10.123.45.2   I can ping that just fine.

Then in part 4, it tells me to ping the google address.  Seriously...?  With no gateway connected to the device, it will never be able to reach outside this subnet.

So...

Where is this 192.168.1.101 that it claims was assigned coming from??

Was I supposed to change the device to Station mode in step 3?  That's the only way to ping outside of it's subnet...  Obviously once I do that, my tablet will be disconnected, as that SSID is gone.

So I changed the device to station mode using the web page, now it connects to my network, under IP 192.168.1.91. I had to hunt that down on my router....  So now to connect I had to know how to find it, and connect to it from from a device that is on my network.

  • Hi Christopher,

    The CC3120 has to be reset before it can change to station mode and start auto provisioning. If it does not automatically switch roles, you can also set the role from the Device tab. We can update the documentation to reflect that.

    Once the device is in station mode, it will provision based on the WLAN profile added in task 3. We assume that profile is an internet-connected AP, and we provide the expected outcome in task 4 if there is internet connection or not. You will have to connect your mobile device to the same AP as the CC3120 and use the default station IP address (the downfall is the AP may choose to reassign this IP address, and we do not have any host MCU print output in this demo to verify).

    The Out of Box is limited by what we can configure using the integrated HTTP server without any host  involvement. I suggest moving on to the Wi-Fi Fundamentals lab to fully test the Wi-Fi features of our device.

    Best regards,

    Sarah

  • Sarah,

    Thanks,I worked around this issue.  Perhaps the online doc would like to explain it better for the next person. And the built in AP web page could be corrected to not show an erroneous IP address.

    I've already been through the fundamentals lab, as well as most other CC3x20 material on that "Academy".

    My goal is to port the driver to run on an AM335x.  But, as I discovered, the drivers as well as the example projects are now trying to impersonate POSIX libraries, rather than the SYS/BIOS that was pushed so hard last year.

    Who thought that would be a welcome idea??

    And, of course, it didn't take long for the me to stumble across a driver call in the example project which isn't in ANY of the API documentation.

  • Hi Christopher,

    The SimpleLink platform did move towards POSIX for all of our examples and libraries. To port the host driver, you only need to implement the SPI commands, sync and lock objects, and a timestamp mechanism. You can ignore the POSIX layer if you choose. Check out the Porting the Host Driver chapter of the NWP Programmer's Guide: http://www.ti.com/lit/swru455

    Which API did you have issues with?

    Best regards,

    Sarah

  • Thanks, I've been through that doc over and over.  That material is repeated in many places.

    What is DOESN'T tell you is which of the 100's of files are part of the lib.

    And what libs need to be rebuilt.  There is no build script I see.  Or instructions.

    Couple that with my preference to use SYS/BIOS kernel objects, which can ONLY be built inside the un-documented SYS/BIOS and XDC stuff in the CCS IDE (because the CFG file generates a bunch of stuff that is a mystery)

    See my last reply to Ben on this thread: https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/t/876861

    I am just trudging through... slowly

  • I continue to trudge through this horrid environment.

    You guys at TI do realize that "Doxygen" isn't really "documentation" don't you?  It's garbage:

    • You can't search with it (Try it...  just put SL_PLATFORM_MULTI_THREADED in the search box on that page that gives porting instructions...  It can't even find something on the currently open page). 
    • There is no API list of functions.  You have to know the file to find an API call (normal, real, documentation works exactly the other way around
    • When you stumble across an API call, usually it's poorly documented, and has no example
    • Nothing tells you what header to include, and what lib to link to for any API call. ( Even Microsoft's MSDN tells you that most fundamental information.)

    Then, there is this one. On the page telling you how to port the driver:

    Step 8 - Run diagnostic tools to validate the correctness of your porting
    The driver is delivered with some porting diagnostic tools to simplify the porting validation process and to reduce issues latter. It is very important to follow carefully this process.

    The diagnostic process include:

    1. Validating interface communication driver
    2. Validating basic work with the device

    It doesn't say where such tools are.  Maybe a name so I can search for them?  How about how to use them?

    So... It is very important to follow carefully this process.. A process that is not defined or described.

    And no one actually realizes these deficiencies? 

  • Hi Christopher,

    The porting section in the doxygen is out of date and will be removed from that document. Please use the link for the NWP Programmer's Guide that I shared in my above post. All of our APIs should be available in this Programmer's Guide as well. The only header you should need to include for the SimpleLink Wi-Fi library is wifi/simplelink.h.

    Which API is missing?

    Best regards,

    Sarah

  • Sarah,

    Since so much of the doc is contradictory or out of date, my source is any working code I can get my hands on.

    I picked the "network_terminal_MSP_EXP432P401R_tirtos_ccs" code as an example, and began stepping through it, comparing the calls and arguments to the API, to insure I understand it.  Then I hit

        /* Before turning on the NWP on,
           reset any previously configured parameters */
        /*
             IMPORTANT NOTE - This is an example reset function,
             user must update this function to match the application settings.
         */
        RetVal = sl_WifiConfig();

    There is no function call documented called "sl_WifiConfig()"...

    The comment is completely useless, as it is NOT clarifying what must be updated.  And it's a call that is buried into compiled code, so it cannot be stepped through.

    If the "user must update this function"... then how?  Does the user have to alter this function and rebuild the library??  Because there is no script that describes how to rebuild the library.   (You do know such a script would be useful to rebuilding this lib for another MCU, don't you?)

    So, two calls into unraveling and attempting to understand the driver using the example code, I run into something undocumented, and unexplained.

    Then there is the complaint that this driver doesn't even use the TI-RTOS and SYS/BIOS packages that are pervasive throughout all the other devices.  No consistency in using the SYS/BIOS tasks API, or kernel locking objects.  Different APIs, different function signatures, different kernel objects,... But I've already voiced that criticism. 

  • Hi Christopher,

    sl_WifiConfig() is documented in the host driver API doxygen, under the device section. This function is more relevant for the CC32xx devices that use the SysConfig tool, but it is a general default function (you can set parameters in ti_drivers_net_wifi_config.c in each example). You are not required to use it. You are able to make changes to the function itself and rebuild the SimpleLink library. CCS, IAR, and GCC compiler support are available with makefiles in the ti/drivers/net/wifi folder.

    We try to keep our software consistent across the SimpleLink platform. Our host driver supports the POSIX layer over TI-RTOS. It sounds like much of your experience may be on the Sitara platform.

    Best regards,

    Sarah