RTOS/LAUNCHXL-CC1352R1: Using TREX, the download of SimpleLink CC13x2 26x2 SDK errors out at 95% with an UNZIP Error

Thanks for the feedback. I have experienced the same myself from time to time. Normally the download succeed if repeated a few hours later but using a download from the SDK download page is often a good option.

I too experienced the "unzip" error that Eric mentioned. As TER suggested, I was able to download the v2.40 version of the SDK from the TI website and install it manually. I don't think this is a 'good' answer, but it's nice to have that as a backup.

Unfortunately, my problems didn't end there. I wasn't able to debug any of the examples in the SDK (I tried about 4-5 examples). The examples build OK, but fail when trying to download and run them on the CC1352 LaunchPad.

I tried the same process on CCS Cloud and had the same results. The CC1352 examples from SDK v2.40 would build, but would not load properly. After clicking the "Debug" button, everything seemed to be working work up until it hung with the dialog stating: GEL Expression: GEL_Go(main)

I suspect the same error is keeping any of the examples from working on both CCS Cloud and Desktop, though CCS Cloud appeared to give a little more information as to where things were failing.

Thankfully, by going back to SDK version 2.30, I found I was able to build and debug serveral examples. (I wondered why both SDK versions 2.30 and 2.40 were both available in TI-Resource Explorer in the Cloud? But I suspect there might be a known, undocumented problem with v2.40.)

Lastly, printf() doesn't work when added to the NoRTOS examples from SDK v2.30. (I can't get far enough along to figure out if v2.40 has the same problem.) We were able to get it to work, though, by increasing the Heap size in the linker command file. Even though printf() isn't something I'd use in production code, many users like it for debugging their code, so it might be nice to see the TI default include a larger heap size.

Yes, this answered our question. Thanks. By the way...I have two suggestions when you break compatibility with a previous SDK and match up silicon revs to SDK revs. First, I get it - constantly improving products for your customers. That is great. However, for the unaware (they don't see/notice the release notes, not aware of silicon/SDK match requirements), they can simple run into this problem and think there is an issue with their board or SDK or both...not knowing about the incompatibility.

Two ideas/suggestions that might help fix this:

1. When I compile for the latest version, can't the build process check my silicon rev (first or early in the process) and give me a warning or error that says "this SDK is not compatible with your silicon". I have a target config provided and a processor noted. Or maybe at least say for the first rev of the SDK that has this requirement - throw a warning that says "please check your silicon rev. This SDK requires Rev E silicon or newer". That way, I would have noticed the problem earlier in the process vs spending hours trying to debug why it wasn't working and getting hung up in the GEL files. I can imagine other new users have the same problem. Yes, you have it documented on E2E - you showed me the link - but how might a new user FIND this? By asking another E2E question possibly.

2. When I click on the heading (SDK ver 2.40.xx.xx), there is some documentation that comes up in TI-REX. The bottom has some folder listings which you probably can't change. However, the top part just has a short description of the SDK - why not include a big warning sign that says "this SDK is for Rev E silicon or newer. Please make sure your target hardware is populated with RevE silicon." I would have seen that - and others will too.

3. And SimpleLink Academy - where many users start their investigation - maybe have this warning sign in Project Zero and at the top of the first SLA topic. I would have run into it there too.

My bad for NOT checking the release notes. That was my oversight. I am just suggesting when you have a break in compatibility that is a "production/development STOP issue" for new users, that you populate a few other places that new users hang out with the message about compatibility. It saves people time and creates a better user experience for everyone. FYI - the compiler warning (or gee, you could do it with launch or connect or load too) is my favorite.

Another idea is this - when you try to connect to a processor on a board and your .out file was built for a wrong target, we get the error "cannot connect to target." Sometimes this is a target config problem or power or debug/device switch problem. Ok. So there is some checking here. Is there a way (during connect when the Gel file runs), could query the .out image and figure out which SDK ver was used to build it and then match that to the silicon rev used? CCS could then provide an error of "mismatch of SDK and Silicon..." of some kind.

Thanks for the feedback, I have forwarded your post.