simplelink_cc23xx_sdk_6_40_00_21_eng build problem

Hi - just so that I don't bang my head and stay on the safe side - I have modified an example when using the previous 6.30 SDK, which no longer compiles, with the same error mentioned in the first post. How do I modify such project, so that it now follows the new 6.40 (and hopefully future) standard, especially when the new drivers and documentation are finally made available? BTW, the (FreeRTOS) examples in the new 6.40 are many times fewer than in the previous version (what's going on?) and the one that I'm interested in is the simple_socket_server.

Thanks

Stefano

PS the example compiles and runs fine if I copy back the missing files from the 6.30 to the 6.40 and correct a path to icall_POSIX.c.

Hi Stefano,

It is recommended to start with a project on the 6.40 SDK and migrate your functionality from your 6.30 example to ensure the project works as expected. The 6.40 project will contain all of the proper links and includes required for the 6.40 SDK. I truly apologize for any inconvenience this may cause. If you are able to manually change the links and includes in your 6.30 project such that it compiles using the 6.40 SDK, then I would recommend you test your application thoroughly to ensure it is working as expected. Can you share the examples that are missing from the 6.40 SDK that you require for your use right now?

Best Regards,

Jan

Hi Jan,

thank you for your kind reply, no need at all to apologize for the inconvenience. As I mentioned earlier that specific example is the venerable simple_socket_server, but it still works for the time being and I'll just diff the examples to see what is going on when they're updated. The real problem with this device is that, despite the well-deserved initial hype, at the moment it has close to zero documentation. I'm porting my very low footprint application framework to the CC2340 in separate parts, using three different dev kits - including one now deprecated MSP432 LP, since it supports FreeRTOS, despite a different core architecture and peripheral modules - planning to glue everything together when at least the module descriptions - never mind the drivers - become available. Last reference guide release was in June (!) and was basically blank. New core (for TI, apart from the MSPM0, which is still in XMS last time I checked), new peripheral modules (from looking at the headers), newish kernel, new compiler (CLANG), new BLE version/stack, seems like we're lucky we aren't forced into Theia (yet?). I understand the massive amount of hard work behind this, don't worry. What I don't get is how the most basic peripherals (after the GPIO perhaps), the timers (including PWM), aren't covered after so long and precedence is given to other modules. Power management too is crucial, on a part like this, but I get it that it interferes with the BLE stack a lot. You must have some draft you're working on right now (which you can't share) apart from the SysTick. I hope that there isn't something less than ideal in the design, I already got burned with the MSP432P fiasco, that I've spent a lot of effort porting to, which was superbly documented (you even had the most academic materials ever and even the books by Valvano). Can you confirm that a major doc update is expected by end of February? I'm vacillating over reverse engineering the headers without the docs, wondering if it is even useful in making progress or the gateway to debugging hell with all those channel/bus matrices typical of ARM cores. Basically I'm done with porting all the pieces to SimpleLink + DriverLibs (or whatever they are called now) + a few register tweaks + BLE stack, my next step is to figure out the footprint and if it comfortably runs everything on a single and not multiple cores and how my framework - which started out a long time on bare metal MSP430 + bitbanging - gets along with BLE idle states and the FreeRTOS.

Have a great weekend,

Stefano

PS I attended sessions on the SimpleLink concept back then at Dallas HQ before it was even introduced. I hope it doesn't get undermined by device peripherals design going all over the place...

Hi Stefano,

Thank you for the kind words and thorough feedback! We will definitely take the provided feedback into account and attempt to address as many points as possible. We truly apologize for any incomplete portion of the documentation. The documentation is still under development as the device/SDK are still under development. By the official device release, all documentation should be completed and any currently present gaps should be addressed.  When you say there is "near zero" documentation, can you specify exactly which section you are referring to? Some of the main pages for the API documentation are not yet finished, but the API pages can be navigated still. For example, in the TI Drivers API guide, the main page shows up as blank, but you can look up any driver API in the search bar at the top right (UART2_open() for example). I completely agree that this is not ideal and will be addressed in the future.

Can you provide some information regarding the application you are porting from? Which device is the original project on? What is the general application for the original project?

I cannot comment on unreleased content or material on a public forum. I apologize for any inconvenience this may cause. Please reach out to your TI representative and they should be able to provide some additional details.

Best Regards,

Jan

Hi Jan,

thank you for your kind reply and I underline the fact that absolutely no apology whatsoever is needed. This is a preview of a work in progress and I'm already very grateful that I get early access. I'm very excited about this new device, I hope it becomes an historic success for TIs MCU BU. I have my specfic reasons for this, in many ways, this is an energy - and space and cost - efficiency dream come true. If I can make a comparison, this is (or hopefully could become) a reboot of the MSP430 when it came out, at the time, with its architectural elegance, energy efficiency and C compiler-friendliness. When I lamented the lack of documentation, I wasn't referring to the (still limited) APIs, which are either described, or self explanatory, but to the peripheral (and also some non peripheral) modules descriptions and detailed behavior. Specifically, I'm referring to swcu193 and to swrs272/292, but I won't comment further here because they are restricted access (but you can easily see why and their dates). Elsewhere, a new device in preliminary silicon with still many crucial errata, is much better documented, albeit provisionally. There must be, however, excellent reasons for this, I also understand that, for a wireless MCU, the protocol stack (with the underlying standard being an ever moving target) might and should be highly prioritized, as that is the area where it will be mostly judged for.

To answer your questions:

What I'm porting, in reality, is more than an application, it is what I would define an applicative framework, or a middleware. Since this framework's purpose is applicative, however, it was designed from the ground up through the development of a demo (hyper)application which would serve as a testing ground for the framework, that is based on a very peculiar approach and characteristic, which I won't discuss here. What I will say is that architecturally, it focuses on an extreme low memory footprint and extreme high energy efficiency, leveraging on the specific characteristics of the first device it was designed on, which was the MSP430 non-X. It also targets engineers who are not strictly focused on the embedded space, but who want to give their products certain local or remote capabilities without disrupting them and not relying too much on external assistance, trying to prevent the gap/trap, between what the main designer of the product has in mind and the embedded/hardware team and lowering access barriers. This started in the pre-FRAM and pre-SimpleLink eras, also when connectivity (unreliable at times) was achieved through separate modules, often with non-TI architectures and was kind of glued on top. One specific requirement was that the framework had to cater to the smallest possible designs and, eventually, it had to run (the entire demo application, which terminated on the cloud and also had a BLE component to it) hosted on a 16Kb/0.5Kb Flash/RAM at 8Mhz combo (I chose the G2553 because it was the first available LP). It was also great for FRAM parts, although the early ones where high-end devices and in the new value lines some little changes have been made that were kind of disappointing. Anyway, this approach led to the need for continuous efficiency optimizations, which were also extremely hard (but very useful) to decide and achieve in order to keep the framework balanced within the constraints. Its goal, in time, evolved into becoming a bridge towards the then unconnected to the now present linked future. I was part of a focus group that was exposed to the MSP432(P) ahead of its launch and that was before it was included in the then still unannounced SimpleLink family concept, only to be prematurely EOLed and reintroduced as "E" by rebranding a Tiva part. When I got my first (black) MSP432 ES LP, I immediately ported everything to it, both in its "bare-metal" version and in a new feature-equivalent (TI)RTOS compliant version based on DriverLibs, which then I (almost) completely replicated through the simplified lowest common denominator which is SimpleLink and now it suits all the radios very well. I thought, based on TIs announcements and claims back then, that there would a future other than the MSP430 in extreme-low power unconnected MCUs, starting with the highest performance available core M4F and after that who knew. Only the Tiva - a great high-end part, but not low-power friendly - survived, despite the "E" MSP432 rebranding. I'll cut it short here, although it turned out it was just as useful with the wireless SL devices. Sadly, it seems to me like the "legacy", but still incredibly capable and unique 16-bit (and now 32-bit with the MSPM0) BU and the SL BU have almost become two separate divisions, when there would be huge synergies and transition opportunities (that was also a goal of the framework). With SimpleLink, greatly focused on connectivity and very high-specs, I started a different route, besides considering whether porting other vendors, something I have not decided yet. Instead, I successfully developed an actual feature-complete MVP (which I can't describe here, but it's a consumer device), using my framework at its very best, that I'm considering to actually manufacture. Ultimately, the CC2340 is a dream candidate both for the framework and for its two current applications (the demo and the product) and I can't wait to merge what I already did on it on the BLE side, with the rest of the framework and application which - while documentation and drivers still aren't available, is hosted on a deprecated MSP432P, mainly for its original good support of FreeRTOS and same-speed (but different architecture) core, which should remap well enough in performance, given I don't use floating/DSP only fixed point and my code is very lean. I also hope that certified tiny modules show up right after release.

Apologies for this long and somewhat fuzzy answer, in totally the wrong place. I will be checking my MSRs every day for good news (for some reason I don't get notifications, unlike for another device currently in preview) and you'll know from my requests for help how it goes with the merger.

Thank you for your kind support,

Stefano

Hi Stefano,

Thank you for the kind words! I am glad to see that the CC2340 seems like the ideal candidate for your project! The documents you have identified will definitely be updated in the near future. At this point, I cannot commit an exact date but it should happen relatively soon. If you need any assistance with your project or have any questions/concerns about the CC2340, then please do not hesitate to open a thread or reach out to your TI representative and we will help ASAP.

Best Regards,

Jan

Promise kept!

Thanks, best

Stefano