Repository files navigation

• #include <ti/drivers/>TI-RTOS Drivers DocumentationThis is where you will find peripheral control interfaces.These interfaces properly(ish) interact with the RTOS(SYS/BIOS).
• #include <ti/sysbios/>SYSBIOS Guide |SYSBIOS and XDC API DocumentationThis is where you will find synchronization primitives and task control functions.
• #include <xdc/>SYSBIOS and XDC API DocumentationThis is where you will find useful standard functionality, like timestamping,text formatting, and logging.
• #include <driverlib/>Non-RTOS Driver LibraryThis is the bare-metal interface used by TI-RTOS. You can find someinteresting low-level functionality that is not exposed by TI-RTOS drivers,likeSysCtrlSystemReset() found in<driverlib/sys_ctrl.h>.That being said, you should not be directly using peripherals that arealready controlled by the TI-RTOS drivers mentioned inti/drivers.

• To do proper debug stepping, you need to load the debugging symbols for thefunctions that are found in the ROM. TI calls this the golden ROM image.This symbols file can be found at either of these locations(should be identical files):

  • ti/tirtos_cc13xx_cc26xx_2_21_01_08/products/bios_6_46_01_38/packages/ti/sysbios/rom/cortexm/cc26xx/r2/golden/CC26xx/rtos_rom.xem3
  • ti/tirtos_cc13xx_cc26xx_2_21_00_06/products/bios_6_46_01_37/packages/ti/sysbios/rom/cortexm/cc26xx/r2/golden/CC26xx/rtos_rom.xem3

  Note, the source that created these ROM images is indeed in the source tree.It just takes a bit of searching.

• Video about TI-RTOS Debugging

• GNU GDB Server and Flashinghttp://www.ti.com/lit/an/swra446/swra446.pdf

• Checkout thedebugging quick start.

• SYS/BIOS FAQ

• EMUPack is the software that controls the debuggerhardware. It controls things like flashing, providing a gdb server,upgrading debugger FW, and more.Annoyingly, it installs to theti/ccs_base directory.
• XDC is a standard for providing reusable software components,called "packages", that are optimized for realtime embedded systems.In other words, it is this annoying (but somewhat cool) Javascript systemfor generating C/C++ code/headers, ROM symbol linking info, and build config.The.cfg in the project directory is XDC's Javascript style configurationthat describes what components to include in the compilation and theirsettings.XDC also brings lots of target standardized libraries for necessary thingslike snprintf (System_snprintf), logging, and error handling.The command responsible for processing all the .cfgs is thexs commandfound inti/xdctools_VERSION_core.
• SYS/BIOS is the underlying RTOS. It has been ported to many architecturesand platforms, including x86.TI-RTOS seems to be more of the summation of SYS/BIOS andall of the hand written drivers and control logic for a given MCU.The subsystem outside of SYS/BIOS that control power and peripherals aresomewhat significant, thus the combination takes on the TI-RTOS name.
• XDS typically refers to the series of TI debugging hardware like theXDS110, which is embedded in the TI Launchpads.Another note worthy XDS debugger is the XDS200, which is said to be faster(and more expensive) than the XDS110.
• CCS is the TI curated IDE with awesome debugging support.

• The Idea Behind XDC

• Projects for use with the GNU C Compiler, GNUMake, XDC, and TI-RTOS:ti/tirtos_cc13xx_cc26xx_2_21_01_08/examples/GNU/CC2650_LAUNCHXL.

This directory holds upgraded/fixed core libraries and drivers for the CC2650.

These libraries were carefully upgraded/merged to use the new code from fromsimplelink_cc2640r2_sdk_2_20_00_49 on Nov 29, 2018 by Craig.To make use of them, you must add this overrides directory to the includes list with higher priority than the core libraries. Next, you must modify your equivalentCC2650_LAUNCHXL.c file to have the following two definitions (converted to use your own CC2650_BLAH_ADC...COUNT defs.):

constuint_least8_tADCBuf_count=CC2650_LAUNCHXL_ADCBufCOUNT;constuint_least8_tADC_count=CC2650_LAUNCHXL_ADCCOUNT;

They were merged fromtirtos_cc13xx_cc26xx_2_21_00_06.

This fixes a critical issue that was solved in the C2640R2 2.30.00.28 SDK.The issue deals with a misuse ofuDMAChannelDisable functionfrom withinUDMACC26XX_channelDisable. TheuDMAChannelDisable functionexpects a channel number, but was given a channel mask. This results inDMA channels never being disabled, both during the startup of the SPI driverand the closing of the ADCBuf driver (in the ADCBuf cleanup routine).This issue was resoled in the cc2640r2 SDK by simply making the direct registerwrite from within theUDMACC26XX_channelDisable function, since this registerexpects a channel mask.This upgrade also brings theUDMACC26XX_disableAttribute function, that isn't used.See commit 784e0035696feb367439ae55194fdafc63fefc59.

There is one other uDMA problem that needs to be solved.The internalisOpen variable is never initialized toFALSE.This means that the driver may not follow the proper initializationroutine on system reset.The following function should be added to the LORABUG.c file, right afterthe uDMA setup:

voidLORABUG_initUDMA() {UDMACC26XX_init((UDMACC26XX_Handle)&(UDMACC26XX_config[0]));}

The function should then be called before SPI or ADCBuf init functions in main.

Major changes like

Power_setConstraint(PowerCC26XX_NEED_FLASH_IN_IDLE);Power_setConstraint(PowerCC26XX_DISALLOW_XOSC_HF_SWITCHING);

Power_releaseConstraint(PowerCC26XX_DISALLOW_XOSC_HF_SWITCHING);

constuint_least8_tSPI_count=CC2650_LAUNCHXL_SPICOUNT;

These changes were merged fromsimplelink_cc2640r2_sdk_2_30_00_28.

The most importantThe new SPI driver depends on the power constraintPowerCC26XX_DISALLOW_XOSC_HF_SWITCHING, which was only implementedin the new Power driver. For this reason, I had to upgrade the Power driveralso.

From the updatedPowerCC26XX.h:

+#definePowerCC26XX_DISALLOW_XOSC_HF_SWITCHING 6+/*!< Constraint: Prevent power driver from switching to XOSC_HF when the crystal is+ *   ready. The RTOS clock will be rescheduled to try again in the future.+ *   This is a workaround to prevent the flash from being accessed by a bus master+ *   other than the CPU while switching to XOSC_HF. This would cause a bus stall.+ *   This functionality is only implemented on CC26X0, CC26X0R2, and CC13X0 as the+ *   bug was fixed in hardware on later devices.  */

The silicon bug being reference here is in the CC2650 Errata.

These changes were merged fromsimplelink_cc2640r2_sdk_2_30_00_28.

This had to updated because the new Power driver required a differentfunction interface toSysCtrlAdjustRechargeAfterPowerDown.Another interesting change to this library is the correction to theSysCtrlResetSourceGet function, which returns the last reset source.I believe this is to compensate for a silicon bug which causes a issuefor a particular type of reset and further results in misreported reset source.

These changes were merged fromsimplelink_cc2640r2_sdk_2_30_00_28.

All the best and happy debugging.Craig Hesling 2018