LP-EM-CC2340R5: Help getting started with BLE

Hello Gal,

I hope you are doing well. Basic_BLE should be a good starting point for your application. We have good content in our SimpleLink Academy, though if you have already completed those labs I would also recommend looking over the guides in the SDK themselves. 

BLE5-Stack User’s Guide — SimpleLink CC23xx SDK BLE5-Stack User's Guide 3.02.04.00 documentation

TI BLE5-Stack Quick Start — SimpleLink CC23xx SDK BLE5-Stack User's Guide 3.02.04.00 documentation

BLE5-Stack — SimpleLink CC23xx SDK BLE5-Stack User's Guide 3.02.04.00 documentation

We also have documentation on our RTOS (under the CC13xx CC26xx SLA), I would recommend looking over RTOS concepts, and FreeRTOS basics. 

RTOS Concepts (ti.com)

BLE is a complex protocol that's gone through years of development/iteration, so it has become quite large. 

Thanks,
Alex

Hi Gal,

since you were kind to "like" my UART to BLE bridge example post, I'm willing to help you - and other CC2340 new users on E2E - to kick-start your experience on this groundbreaking (relatively) new entry-level general purpose BLE device, which, IMHO, is a superb technical achievement that is "TI to its very core" in terms of elegance, versatility, balance and affordability. To almost quote a famous Dire Straits song, you get your "Bluetooth for nothing and your chip for (almost) free". I will try to give you useful pointers and exercises within a learning method/path, from the point of view of a self-taught (with the help of the great E2E TIers, of course) user, who has been working with the device and following its development since its early selective preview phase. Sometimes TI engineers are so knowledgeable and experienced, in perfectly good faith, that they give many things for granted. The TI documentation, traditionally a very strong competitive advantage of using TI devices, is, understandably, not as great and as complete as for other parts, basically for these reasons: 1) It's a very new device(for TI standards); 2) it uses a new (for TI, and single) M0+ core, the MSPM0 family has been designed and released concurrently and they are the first TI M0+ MCUs that I'm aware of, except for a relatively obscure and specific part that I can't remember, unlike their previous unconnected/wired and wireless devices which were multicore and used at least an M£ as the application core; 3) That I remember, it is the first 32-bit and wireless device which doesn't support TI's in-house TI-RTOS(SYS/BIOS) kernel (in the past there has been dual support along with FreeRTOS and, since TI has been pushing their POSIX layer, some level of kernel-independence was possible (even though the POSIX standard was never meant for MCUs and you can't really operate maeningfully only using those calls); 4) since everything runs on a single core, there are certain architectural, behavioral and programming constraints that are unusual, compared to other TI (and other vendors') BLE devices: 5) the BLE standard is probably the most complex (and, at times, apparently over-engineered) networking standard and it is not very flexible, because it has to guarantee multi-vendor and multi-device interoperability and covers most (if not all, at this point) OSI layers. I will try to give you a learning path that can lead you to fulfilling your stated goal of a peripheral BLE sensing device. In order to proceed, I need you to answer these questions:

1) what is your technical/academic background (i.e. engineer, self-taught hacker, "maker"? Are you capable of adapting great material which is not specifically related to the specific part to a new one?

2) what is your proficiency with the C language, as in the "Embedded C" that is commonly used in MCU programming (I assume excellent, if you're here);

3) are you practically experienced with mixed-signal non-wireless MCUs and which ones do you currently use (i.e. 8/16/32-bit, other TI devices such ast the MSP430)?

4) what is the compiler/toolchain that you normally use, do you work with an IDE and, preferably, is it Code Composer Studio?

5) what type of sensors (commercial/self-built) are you trying to use, how are they connected (ADC, custom digital interface, common serial interfaces like UART, I2C, SPI and are you familiar with them?);

6) what is your current programming approach (i.e. bare metal/register based, low level drivers, high level frameworks like Wired/Arduino) and have you only used a "main loop" architecture, have you developed any sort of custom scheduler, or have you ever used an RTOS/kernel in practice?

7) if you have never used an RTOS in practice, do you at least understand the theory and the SWOT (Strengths, Weaknesses, Opportunities and Threats) of using an RTOS, like multitasking/resource management, goodbye to determinism/much harder debugging, networking/GUI capabilities, task starvation/memory leaks etc. and the priority/scheduling and task/thread communication techniques?

8) as Alex just mentioned in his excellent post, Bluetooth and especially its new variant BLE (now at v5.4), is an extremely complex wireless protocol (or family of protocols), which would work when split up in different HW architectures (Host/Network Processor or all-in-one), that has originally been developed within the Telco industry, where they were used to committee-based, carrier-grade, interoperable standards that eventually ended up becoming OSI/ISO. Are you familiar with its architectural model (i.e. GAP, GATT, profiles, characteristics, HCI), its defined roles and constraints. Have you already designed a BLE peripheral and are you aware of what its main mandatory SW components are?

Once you have answered these questions, I will do my best to guide you around how I have adapted my pre-existent application and my underlying original non-wireless application framework (which were running either in a host-MCU + network processor configuration or on a dual core BLE device, with the networking stack running on a completely separate core from the framework & application), to this technical HW/SW marvel of everything running smoothly on a single, simplest ARM M0+ core. I hope that even other users, with different technical backgrounds and capabilities, may find my advice beneficial, by, in case, skipping the points that they are already proficient with. Just to make it clear, this will be a "best effort" contribution by an average user (not a top-tier expert) and it will be subject to errors, corrections and criticisms, which I will very much welcome.

(to be continued...)

Bye

Stefano

Hi Stefano. thank you for your reply!

1. I am an Electrical engineer working as a board designer/field application engineer. I can adapt learned material between different products, it is just that this platform is very new to me (never dealt with rtos nor BLE).
2.I think I am rather proficient with low-level C (wouldn't call myself an Expert, but as I mentioned before, it is what I do for a living <and hoby>).
3.I had a small project using the MSP430FR2110 MCU.
4.For working with MSP/CC MCUs I use CCS  with TI Clang compiler and flashing using a launch pad(but have no problem migrating to another tool).
5.Well, for the first part of prototyping I would work with a commercial sensor, later on I will use my own implementation. the commercial one is communicating using UART, for my implementation I will need to supply a square-wave output and read back digital IO (a slow demodulated ASK signal).
6.I usually program using bare metal and low level drivers approach. and I only programed MCUs using a main-loop architecture (with counter based run-time limits for different functions and other more advanced functionality)
7.I understand the SWOT of RTOS to some degree, but would definitely require deeper understanding about using the different sync options (more of the practical side rather than the theoretical which is not very different to any type of OS).
8.I have never designed a BLE peripheral before (closest thing I had was playing with a UART BT4 module). I am familiar with part of the architectural model (GAP,GATT,Characteristics) to some degree, but that's it.

I am very excited to learn both of these topics (RTOS and BLE stack) and start using this promising new product (CC2340R5, and hopefully R2 when it will be released)

Thank you for your willingness to teach!

Gal

Hi Alex, Thank you for your reply.

I read through the material you've recommended and I think it assumes prior knowledge and familiarity with programing using RTOS framework, and probably some level of experience with BLE apps.

I feel I could probably build an app using the examples, but with a lot of overhead for modules I do not need and with many of the parts working as "magic functions" with me having the deep understanding of what is happening in my programm.

Since I am used to program bare-metal (or with low level drivers), I find it unsatisfactory to use high level abstraction without understanding what is happening "behind the scenes" (and optimizing whatever I can as a result of that understanding).

I appreciate your response but I assume I lack further, more basic, understanding before I can make proper use of these sources.

Thank you,
Gal 

Hello Gal,

First I want to thank Stefano for his input, I think his reply was very detailed and has some great information for someone interested in BLE and RTOS. 

I next want to inquire about your specific application you are targeting, if you just want to send BLE packets then you can stick to bare metal, however if you want to connect to a phone, or something along those lines you will need to use the BLE stack (to be BLE compliant). The BLE stack and RTOS would make things much easier as a starting point when developing with our devices, as well as our SDK examples and documentation based around that. 

Thanks,
Alex F

Hi Gal, Alex and anyone else who's interested,

great reply Gal, I have all the information I need to more or less assess your needs and make my suggestions. The good news is that, given your background and competences, in 2-3 weeks, you should be able to start accomplishing your goal. The bad news is that I won't "teach" you, but just give you some subjective advice on a path and the steps in sequence that should lead to your success. I will start by briefly replying to your last post, point by point, so that I can give you a background picture on how and why the following milestones will unfold, according to my method, with some activities happening in parallel. As usual, please anyone reading, correct me if I'm wrong and I welcome every criticism.

1) excellent, some of the materials that I will point to will be outdated, will refer to different hardware and even operating system, but as an engineer, you will be used to solving problems and adapting solutions on your own and this will be an invaluable exercise to help "glue" the concepts in your mind;

2) low-level C is essential, so that your very proficient is more good news. Embedded-specific, in my mind, means being familiar with register and bit-field manipulation, but also with pragmas, intrinsics and the occasional ASM, especially if you're interested in the few parts that have to be adapted in RTOSes, according to the targets' instruction sets (for example, atomic operations that can't be carried out in plain C. From what I understand, the CC2340 family is the first one (perhaps along with the MSPM0 one) in TI's 32-bit MCU portfolio, to migrate from TI's "traditional" ARM compiler Armcl, to TIClang, which should be compatible with ARM GCC (which has been supported for a long time). From my experience, on top of being a great compiler, the "old" TI Armcl had exceptionally clear documentation and was pretty simple, while covering most usage cases (I find some compiler commands very very niche and always wonder, on average, what the level of actual tweaking is in the real world, but that's just me). I have found the TIClang docs less "TI-clear" and more reference, but there are migration guides that you can refer to and they will help you out. After a bumpy start with some slightly obscure errors from code that flew past TI Armcl's perhaps more forgiving compliance to the standards, I have successfully migrated everything to TIClang;

3) one of the reasons for discussing TIClang in the earlier post is that you have mentioned using an FRAM-based 16-bit MSP430 MCU in the past. I love that architecture very much, but haven't used it for a few months and I'm not sure there has been a transition to a TIClang compiler from the "traditional" TI one for that architecture, but I suspect it hasn't happened and might never occur. This said, even though the MSP430FR2110 is a very low end Value Line device, it still benefits from the superb documentation of this fantastic 16-bit product family, with the added bonus that, compared to the other non-FRAM low-end devices (like the G family) it implements a newer low-power management module and modes that are more similar to the ARM M0+. Anyway, given the very limited resources of this part, you can only use it in "bare metal" mode and probably not even implementing a proper driver set (but rather inlining register manipulation here and there);

4) using the "default" IDE, toolchain and prototyping hardware is the best option when learning: this way, you will have plenty of similar setups in the excellent E2E forums and it will be much easier to look up similar scenarios;

5) UART is obviously the most basic form of serial communication and it's nearly ubiquitous in MCUs (sometimes not fully implemented though, but "helped", by a simple peripheral). With your MSP430FR2110, you had a eUSCI_A, which implemented UART and SPI (but not I2C, which is hugely popular with sensors). In the CC2340, You will find a single hardware UART port (with limited pin muxing support, especially in the LaunchPad) and defaulting to the XDS110 (if you use that option) UART to USB adapter, so if you will need more, you will have to bit-bang them on generic timer output pins. It also sounds like your final implementation will also need a specific IO setup, so, again, you must be familiar with operating at the lowest level of the timer peripherals, obviously with at least a logic probe to check and tweak the outcome. You will find this quite more challenging (albeit not impossible), when dealing with a single-core BLE device, running an RTOS;

6) to fully exploit the device, you will have to expand your skills in both directions, downwards, operating at the very low register level, with the usual tricks to increase speed so that you fit in the strict time constraints and upwards, with the higher level calls, like when you're operating directly with the BLE stack, where you only have header/interface (not code) visibility. Main loop-only architecture will no longer be sufficient, although with a resource-limited device it will still be very useful when designing your application, possibly leading to an approach (which I use a lot) that I would define as "mixed-mode", where your core application, although subaltern to the BLE stack, can still be implemented that way. You basically say you have written your own basic scheduler, meaning you're basically almost half way in your journey towards RTOS adoption. FreeRTOS, despite the OS in its name, is not a full-stack operating system, but more a kernel. It performs task scheduling (including prioritization) and flow control, inter-task communication and (very limited, as should be in small embedded devices) memory management. Unlike more complex (and sometimes over-engineered, if applied to small devices, solutions like, for example Zephyr), it doesn't provide networking stacks, which are separately provided by other vendors, HW like TI or SW;

7) of my suggestions, IMHO the ones you will find more valuable are the ones regarding the documentation and methods related to the understanding (in theory and in practice) of the RTOS component, which is absolutely central and essential in your journey. It's true that there are similarities between RTOSes and other non-RT OSes (desktop/server/mobile), but there are also very big differences. RTOSes are much less forgiving, especially when you also and simultaneously deal with the low-level hardware, something that is usually impossible - except for kernel and driver development, which are usually out of scope for an application developer - with non-RT ones. There are some strict constraints that you must respect - that's where POSIX alone, at least in my experience - is lacking and there will be even greater ones when also dealing with the TI BLE Stack;

8) there's no way around learning the theory and the architecture of BLE and it has grown to a pretty large spec during all these years. At least, though, it's very well documented in multiple sources (ultimately at the BLE SIG, with TI being a very well respected member) and with different levels of detail. The problem (if you consider it as such) of the TI BLE stack is that it's closed source, like in many other (but not all) cases with other vendors. This means that you will only be able to interact with interfaces, that your understanding from code and code comments, unlike the rest of the SDK, will be very limited or non-existent and you will have to rely on user manuals or on advice from E2E (or FAEs if you have access to them). The other downside is that in some - usually niche and corner - cases, the inflexibility of the binaries will prevent you from achieving that very specific behavior you badly need, sometimes with no workaround. Finally, let me give you some further advice on where to find your technical reference. Unlike the early MCU days, where you either only had the device data sheet or, more recently, the family user manuals (usually as rolling version PDFs), here a lot of the information will be scattered online, in comments, in headers, in code examples, in high/low-level drivers and even in a setup tool like SysConfig, which I sometimes refer to as a "living datasheet" (it is currently used as a static code-generating tool, but it's great for generating code or checking your own even when you want to dynamically change the settings at runtime. Finally, don't expect to find everything glued together in a single place or organized according to a coherent and linear flow, like in proper workshops (but hold your breath!). Those times are long gone, due to exponentially-growing complexity, vendor time-to-market constraints and competition/cost concerns.

All this said, let's go...

MILESTONE 1 - Get to know your new device deep within:

1a) get to know your device (the CC2340), which is definitely a BLE-enabled part, but is also capable of working standalone (i.e. unconnected). My first suggestion is to try out the no-RTOS (and, obviously, no BLE) examples and start blinking LEDs, echoing the UART, generating a PWM output, as you would have done with the MSP430FR2110. As you will have probably realized already, the way TI has implemented its SDKs (across most devices) is by providing two levels of drivers, high (under the SimpleLink umbrella, although it seems to me that this concept has been watered down a bit in the last few years and the high-level drivers are less coherent than before, probably also due to internal organizational changes) and low, which are responsible for actually implementing the HL/SL ones on the specific families/parts. Of course, the high level ones tend to target the least common denominator (especially in terms of peripheral capabilities), while the lower level ones will provide more (but not full, for that you will need to operate on the registers directly) peripheral functionality (and efficiency). So, my suggestion for this milestone is to take the different examples and/or create your own and replicate the outcomes with both levels of drivers and, whenever possible, enhance them with Low Level drivers and poking and peeking (to use an '80s style language) the registers yourself. Inspecting and "decoding" the drivers will be essential also because sometimes the documentation at the register level is very crude and doesn't give too many hints on who actually does what. The other crucial aspect of studying (especially Low Level) drivers is that, on top of what you find in the register field descriptions, there are some order constraints that you must follow when you manipulate registers, otherwise you might get some undefined or, even worse, plain unexpected behavior. Sometimes, you won't find this mentioned in the manuals, but TI driver engineers will have known what to do in which correct order, so you better follow them. Within this milestone, you will also become familiar with the SysConfig tool, used statically at startup and you will configure pins, timers, serial ports (you can also start studying I2C and SPI if their new to you). The CC2340 clock tree is not very flexible (sadly, in some cases, probably due to it being a very BLE-oriented and low-end device), so you don't really have to worry about that, at least. Ultimately, try to replicate what you have done with your MSP430FR2110 on this device, believe me it's a great way to strengthen your foundations for your next milestone;

1b) in parallel, try to find out where the documentation is, other than in the usual PDFs. Here are some pointers for you:

I obviously don't need to tell you to download the CC2340 Datasheet (SWRS272C) and the technical Reference Manual (SWCU193).

For peripheral register description, forget the PDFs and go straight to this resource (here I'm pointing you to the LGPT1 timer as an example, it's on you to figure out where the other instances or the other peripherals are described, also check out the SDK version release in the link, this should now be outdated):

https://dev.ti.com/tirex/explore/content/simplelink_lowpower_f3_sdk_7_20_00_29/docs/driverlib/cc23x0r5/register_descriptions/CPU_MMAP/LGPT1.html

For TIClang:

https://software-dl.ti.com/codegen/docs/tiarmclang/compiler_tools_user_guide/index.html

and (for migration from previous TI Compiler experience, it's also a useful reference in general, to compare with the other compiler's documentation):

https://software-dl.ti.com/codegen/docs/tiarmclang/rel2_1_0_LTS/migration_guide/index.html

TIP N.1: first try to port your old MSP430 project to the CC2340, in bare metal, it should have all the capabilities (apart from the FRAM) of the tiny device;

TIP N.2: dive into the Low Level peripheral drivers and match them with the online peripheral documentation, especially for register setting priorities. Also try to examine the new features and limitations of the new peripherals versus the MSP430's (although the device you used was likely among the simplest and less capable of the line). Finally, study the M0+ and the device specific power management states and what can be switched off and when (especially the clocks), not just in relation to the CPU and the RAM, but also depending on which peripherals are in use (spoiler, when BLE is enabled you can't switch off anything, also consider that VLO/slow clocks can't be fed into the peripherals like timers in the MSP430). This exercise might seem futile, because in RTOS mode, it will be the Power Management driver that constantly takes care of this, but it's still useful conceptually;

TIP N.3: use SysConfig as a "live" data sheet and copy/paste the different generated static configuration files portions (and also use them to study the register settings), to experiment with runtime modifications. Be aware of the fact that generated code and the TI drivers use structs and arrays of structs to set everything, so they are not very flexible to modify, unlike chains of register-setting instructions. Finally, take a look at how High Level drivers (i.e. "SimpleLink" actually "cripple" the capabilities of the hardware (for example, see how the HL PWM driver doesn't actually exploit the multiple channels of a timer (you can't control an RGB LED using it with a single instance) and try to re-write some code, using the LL timer calls and, if necessary, operating at the register level, so that you come up with a much more powerful and efficient solution).
   
**************************************************************************************

MILESTONE 2 - Learn to use an RTOS on your new device (still without touching BLE):

2a) Here's where things get more interesting and challenging and where my suggestions might be more valuable. I will now point you to a "TI old-school" secret "weapon of mass instruction" that they have buried somewhere in their closets and that I will try to resurrect. It's outdated, unrelated specifically to the CC2340 and doesn't even mention FreeRTOS, but it's a killer resource to become proficient with RTOSes: The full TI-RTOS/(SYSBIOS) Workshop. This was a 3-day (at least it was presented that way) course on TI's proprietary RTOS, with outstanding material, lab exercises and even videos. The version (v4.0) I will provide the link to is the last one that is exclusively Copyright Texas Instruments and it was made available on their website up until 2015 (I think at least May). After that date, the course maintenance and delivery was outsourced (or held jointly with) to a company called MindShare, which is still operating, that (if I recall correctly) might have been founded by an ex-TIer who was in charge of such training activities. I feel confident that I can safely link to this material without infringing on TI's IP (or intentions regarding it), because it is stil somewhat available on E2E, albeit in incomplete form (no exercises/labs/videos, I have the videos too in mp4 format but I'm afraid I can't post them for size reasons, unless TI gives me permission to upload them to Youtube, if they are not there already, or more preferably, they do it themselves):

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/887582/faq-where-is-the-old-ti-rtos-workshop

This is the link to the zipped complete files:

TI-RTOS_Kernel_Workshop_Files.zip 

Most of the material is outdated (CCS is at v6, we're at v12 now), the target MCUs (unconnected and wireless) are different and, as mentioned already, it's about another RTOS (and compiler, but that is not really material). The general concepts, however, are explained very clearly and the information flow is awesome Fun fact, after taking a previous version on a Tiva, a long time ago, I did exactly what I'm about to suggest: I went over the workshop, using the preview (the black - the only black LaunchPad ever released) MSP432R, now prematurely defunct, and ported all the examples to FreeRTOS, since it was supported on that device (that's when TI was starting to push the POSIX layer for kernel independence). Now it's up to you, as the best possible exercise, to learn the workshop's concepts and follow its flow and format and adapt/port all the examples in the labs to this new CC2340/FreeRTOS/TIClang reality. But how do you learn the FreeRTOS equivalents to TI-RTOS(SYSBIOS)?

2b) Some of the best books on FreeRTOS are freely available on their website at:

https://www.freertos.org/Documentation/RTOS_book.html

You should follow the "Mastering the FreeRTOS Real Time Kernel - A Hands On Tutorial Guide" (with its companion zipped code examples) in parallel with the TI Workshop, in order to replicate its concepts and labs. The Technical Reference Manual will also become handy, once you're more familiar with FreeRTOS. When you will have completed the workshop and migrated all the code examples, you will be fully RTOS-aware and capable of porting your early MSPFR2110 application to a multitasking architecture and on the CC2340, perhaps enhancing it a bit if it was too simple to actually remodeling it this way. Once you have completed this second exercise, try to design your future application (without the BLE part), perhaps giving commands and reading data over the UART, where the serial communication is implemented in a separate task. Once you have accomplished this intermediate goal, you will be able to move to Milestone 3.

TIP N.1: take the TI-RTOS Workshop according to its flow, but, in parallel, also use the free "Mastering the FreeRTOS Real Time Kernel" book as textbook, only not necessarily in a linear way;

TIP N.2: go all-in FreeRTOS, ignore/skip the POSIX layer (and rewrite any example with native FreeRTOS code) and pay extra attention to the "from ISR" variants.

TIP N.3: in the beginning, forget about message queues and events (which will become important later on) and, for your first simple application, use globals and manage critical code sections using semaphores, which also serve as "gates" for the TI Power Management driver. This way, before you actually start playing with multitasking priorities/scheduling and inter-task communication, you will have learned how to replicate the "main loop" model you are already familiar with, under the RTOS' supervision and you will have fully understood the ISR interaction with it and its constraints.

**************************************************************************************

MILESTONE 3 - Start your new BLE HW adventure:

3a) with BLE documentation, the gap between user guides and reference/standard documentation becomes huge. BLE is an "evolved" (i.e. extended through many revisions) networking (PAN) standard, which, unlike others (i.e. WiFi, LoRa, etc.) has an essential "semantic" component, which means it's not only a communication protocol, but it also extensively covers the application domain with strict constraints, meant to ensure interoperability between central (including its ubiquitous manifestation, the smartphone and its apps) and peripheral devices, beacons etc. The latest iteration (5.4, not yet supported by the CC2340 BLE Stack), as its main new feature and release rationale, provides a new applicative usage case (Electronic Shelf Labels) which justifies the new technical features. It also has a very formal set of components for device discovery, handshake/security/access, application features, etc. Finally, since it's a wireless protocol which is always state-aware, it must always be on (even if sleeping most of the time and waking up for a very short period), in order to preserve the connection within very specific time intervals. That's why, apart from some vendors' mostly early implementations (with architectural workarounds) it must be used with an RTOS or at least a kernel that gives the BLE Stack priority over everything else.

A good starting point, in order to design a peripheral device application, is indeed TI's excellent documentation (as already pointed by Alex with his links). What has been really key, however, in my case, is to understand how TI decided to implement an "framework" (the BLE app side one) into another SDK (the more general one, which includes the drivers, some tools like SysConfig, the TI BLE Stack and now even the RTOS). This means that TI has abstracted and generalised the workflow and steps that are necessary, in order to quickly build and application, covering the vast majority of normal usage cases (especially for a low-end standalone device, probably without a complicated display). Broadly speaking, the final application is split in two distinct main parts, which are very much connected. The first one, covered by this "BLE APP sframework", defines the outwards and inwards BLE behavior, including advertising its capabilities, setting up and keeping a connection and receiving and transmitting data. This activity is all event-driven, TI's model and code is completely open and it is compiled with the rest of the code. Let's say that this is like an apartment that you want to furnish/customize, but the walls must stay untouched. This part also communicates with the BLE Stack (BTW, reflect on the word "stack" and on its dual meaning, because sometimes it might be confusing. In TI's framework examples, this is called from appMain(), it creates the highest-priority BLE Stack task and its own task (in deeper calls) and it's usually called first (unless you want to activate BLE at a later stage) at the FreeRTOS entry point (main_freertos.c). Remember you must satisfy/complete all the essential requirements of this "mainApp()" framework, in the form that is requested (i.e.  attribute table, callbacks and other objects) and don't deviate from it. Key BLE protocol-related files to look into are [custom name]_profile.c/h and [custom name]_profile.c/h in the /common/Profiles/[custom name] and /common/Services/[custom name] folders and, for your app functionality, look inside the /app/Profiles folder. Also take into into account that some of the low-level BLE configuration takes place within the SysConfig tool (if you use it, which you certainly should, especially as a beginner).

The second main part is your own application, which interacts with the first one, that is kind of an "intermediary" with the BLE Stack (although, occasionally and in principle, even your own application part can interact directly with it). This is usually called after appMain(), when the BLE setup is completed and it defines your own application's specific behavior. It too requires its own separate task(s).

BTW, as an unnecessary reminder, The BLE Stack (let's use a capital letter) is the (compiled) closed code and interfaces that allow you to send and receive data over the air, in strict accordance with the BLE standard, while/but the "stack" should also be intended as in "stack pointer", or the memory space operated according to the push/pop model, which is extremely crucial in a small single core device, where the code portions must have very strict priorities and context data must be shuttled around (without corruption). You will soon find out that, to prevent problems, you will be forced to make certain calls from within the BLE Stack task (and outside of the ISR context), otherwise your application will crash and halt at iCall_abort (look up BLEAppUtil_invokeFunction() and BLEAppUtil_invokeFunctionNoData()).

TIP N.1: it's mandatory install a BLE sniffing app on your phone and start exploring the behavior of every possible BLE device you have around (excluding those purely hardware accessories like speakers/headphones, mice/keyboards, which operate under certain specific profiles/standards). Ideal devices are fitness bands, weather stations and every other pure information broker. From within the sniffing app, you will have a clear view and develop an understanding of the GAP/GATT model and it will all quickly sediment inside your head. I have an Android phone and I have used apps like BLE Scanner, LightBlue or nRF Connect, if you're on Apple, there must be some equivalents;

TIP N.2: my advice is to "become yourself the CC2340" and follow the framework logic, picking up an example, like the BLE to UART example that I posted, starting from the FreeRTOS entry point (main_freertos.c) and follow through the appMain(). This specific example doesn't have the second main part (so it's apaprently breaking the distinction I made earlier), because it essentially only implements a bridge between communication interfaces, without any "intelligent/interactive/sensing" activity in between. So, now it's your turn, as an exercise, to try and implement your own code, like even only toggling an LED;

TIP N.3: in my BLE to UART bridge example (which, I remind you, was intentionally based on modifying the data_stream example and it even keeps the original profile/service names), I had commented out all the log output code (using the SDK's display driver in console mode), in order to provide a pure ASCII in/ASCII out experience. A great exercise would be to reinstate that code (figuring out where it is and which events trigger it), so that you have a clear understanding of the interaction between the BLE Stack, the "appMain()" framework and whatever custom app code that you may have introduced if you have followed Tip n. 2.

**************************************************************************************

MILESTONE 4 - Complement your HW (peripheral) BLE expertise with BLE app development on a central device (the smartphone) NOT COVERED

This milestone is really out of the scope of this long post and I'm not currently in a position to give any meaningful advice. Smartphone app development is an entirely different beast, because it requires specific skills (including different more Object Oriented high-level languages and libraries), workflows (think testing on different devices, multiple OSes (Android and iOS) and OS versions, even if emulated), GUI/UX proficiency, toolchain, environments and frameworks. In my opinion, you can reach a level where you can write a simple phone app (for one OS) and side-load it (if it is even allowed by your mobile OS) and interact with your device. You can't, however, be professionally competitive mid/long-term both as a firmware (and hardware) and a software designer/developer at the same time. With BLE, however, you still need to understand the SW side, which you will discuss in parallel with your team companion(s).

One promising (but unsupported by Mozilla and Apple) technology/API for quick and dirty interaction with a peripheral BLE device would be Web Bluetooth (only available in Chrome and Opera), which could allow you to exchange information by just setting up a generic website with some JS scripts and code that take care of the BLE activity. I have to look into it sooner or later, but it seems it hasn't gone viral or even been mildly successful until now.

**************************************************************************************

CONCLUSIONS

This very long post is a work in progress in draft form and will probably stay this way, but I intend to modify, amend and integrate it, following any suggestion, correction or request for clarifications. I might even have made some terribly embarrassing mistakes, or been arrogant (but still brave) in posting my random suggestions on one of the most prestigiously attended embedded technical forums. I hope you find my advice useful and, at least, appreciate the effort. I very much welcome any feedback or criticism from everyone.

All the best and good luck with your learning journey,

Ciao (bye) from Rome, Italy

Stefano