CC3200 - NON-OS - sl_Start incredibly unreliable

Hi,

I want to make sure yout LaunchPad is functioning OK.

Have you tried using the pre-compiled binaries from the various SDK examples? Are these working OK?

If the answer is no, we need to further investigate.

If the answer is yes, try first to recompile the same examples and program the resulting binary. Is it still working OK?

Shlomi

Shlomi,

I can get some of the examples to work fine. Maybe I need to start a different way...

I'm an experienced dev who's done work in the desktop environment for decades - VB, MFC, ATL, STL, C#, JavaScript, SQL, RLL, you name it... What I'm really looking for is a strategy to understand how to use this chip from first principals. I don't need a C tutor... but I want to understand why I'm doing what I'm doing. Copycatting the examples may get me started, but I don't feel confident. What I want is something like a "CC3200 for Dummies" that will allow me to, using the CCS, create a brand-new empty project, and understand how and why I'm importing this or that library. Do I need an RTOS at all? Can I get away without one? How do I integrate hibernation? I think I'm just missing some serious basics and while the information is probably all out there, it's not cohesive. Is there a tutorial where someone takes a blank project and builds it up showing all the includes and the why's? I do see a "Launchpad" empty project - which is nice... but ultimately my project will run on its own board - not a Launchpad... so I don't know what I'm getting there when I use that starter.

Also - I have found that if I flash my app and run the debugger, it sometimes works fine... but if I make a change, I'm always better off reformatting and then blowing down the program versus just re-writing it. I don't know if that's a Uniflash quirk, something with the Launchpad or the chip....

Best,
Mike

P.S. Sorry for the delay - was on vacation.

Hi,

I really not understand. How are you able flash application (write into serial flash) and debug this application by debugger? This is really not possible. Current version CC3200 heven't integrated flash on chip. CC3200 use external serial flash (connected via SPI).

Debugger from CSS can upload code into RAM, run this code and debug it by JTAG/SWD. If you upload code by uniflesh into serial flash, code in serial flash is read by bootloader into RAM and execute this code. In this case you are not able debug code by JTAG/SWD.

You can check if this is not your case of hanging of sl_Start(): https://e2e.ti.com/support/wireless_connectivity/simplelink_wifi_cc31xx_cc32xx/f/968/t/499123

Jan

Jan,

Thank you for your response. I guess I'm just fooling myself into thinking that's what's happening. If I read you correctly, then I should just be able to load up a CCS project, build, run the debugger, and the code gets loaded into the CC3200 and executed. When I try to do that, I get very inconsistent results. For example, if I switch projects and try to run this way, I can't get it to work. However, if I reformat and flash, THEN use the debugger, I can get it to work - sometimes. I haven't been rigorous about documenting what works and what doesn't, so maybe it's an order-of-operations thing. Bottom line is I'm new to embedded and I'm looking for resources to help me understand how to work with both the CCS and the CC3200.

Best,
Mike

Hi Mike,

If you have latest SDK (1.2.0) please check link in my previous post. I think it can be your case. You can easily check this. Before debug press reset button on your launchpad. If this helps, then is your case.

If you are able run your code with sl_Start() only after reformatting flash, then you have something horrible wrong in your code. As you wrote examples works without issue. You can post your code here, and we can quickly check them.  By the way. If you use latest SDK, latest service pack need to be uploaded inside device.

Jan

Jan,

Thank you... I will try this. In the meantime, do you have any suggestions for learning this whole platform other than looking at the examples? That's certainly going to be a part of it, but what I wish to do is an amalgamation of a bunch of different examples - and the first one out of the gate - provisioning AP - is not part of the 1.2 SDK. Very frustrating... One of the first things I need to do is get this thing to wake up in AP mode and give me a list of access points - once selected, it needs to switch into STA mode, verify the connection, switch back if not OK, or proceed with its data collection and hibernate loop. Seems simple enough. Some examples show NON-OS, some are TI-RTOS, some are FREE-RTOS... I don't have any guidance as to which is appropriate. Again - noob to the embedded world and working by myself. MOSTLY, the app needs to sleep and wake up, do a little data collection, send the results, and back to sleep - which seems like NON-OS. But the provisioning piece... RTOS?

Hi Michael,

Although it is desired to start your own clean project, I do recommend to start with an existing one. This is what I usually do.

te reason is that there are some project settings that are easy to miss and since TI has already done it, why not use it as baseline.

Anyway, you can start with the "CC3200-Getting_Started_Guide.pdf" document that comes as part of the SDK. There is extra documenation in the SDK you can browse.

Documentation regarding Uniflash cab found here: http://processors.wiki.ti.com/index.php/CC31xx_%26_CC32xx_UniFlash

Regarding CCS, you can refer to their wiki pages. Specifically, to start with, processors.wiki.ti.com/.../Projects_and_Build_Handbook_for_CCS

Regarding your queries, deciding on what OS to use, you can pick any, depending on your needs.

SDK has all flavors as reference. You can pick from those or use your own.

Personally, I always like to use OS but if you have  diluted application that does not need OS, you can do without.

Lastly, moving from debug mode to runtime should be fairly easy.

debug mode uses JTAG and download the program to RAM, i.e. you can execute it and debug but it is flushed upon reset. With Unflash, you can program the application to on-borad flash and it should persist. Upon reset, it loads from flash to RAM for execution.

Shlomi