Stellaris support in CCS
The purpose of this page is to clarify the existing TI tools support for the Stellaris® Cortex M3 microcontrollers.
- 1 Introduction
- 2 Tool support
- 3 What is not supported
- 4 What CCS License types support Stellaris?
- 5 Getting started with CCS and Stellaris
- 6 Known Issues
- 7 References
The Stellaris® family of CortexM devices is supported by an extensive set of in-house hardware development tools and third-party software tools from several vendors. Stellaris development in Code Composer Studio is first supported in CCSv4.1.0. Cortex-M4 support starts in CCSv5.1.0, although some of the earlier development boards have a package that adds support to CCSv4.2.4.
A key item required to support Stellaris development was the addition of packed structure support. Compiler releases starting with 4.6.1 (included in CCSv4.1.0) and newer have this support. Packed structures are commonly used by many off-the-shelf libraries for Cortex M including some used in the Stellarisware software.
Support for Cortex-M4 devices started in compiler release 4.9.0.
It is possible to connect to a Stellaris development board using an XDS510 or XDS560 class emulator using the instructions provided in the links below. CCSv4.1.0 has added support for the programming of Flash on Stellaris devices and debugging using the onboard emulation that comes with the Stellaris development kits.
It contains Cortex M3 Cycle accurate and Functional simulators. For Stellaris you will want to select the little endian memory models. These Cortex M3 functional simulator model the Cortex-M3 core, Memory Protection Unit, NVIC, systick timer, memory interfaces and external memory. The cycle accurate simulator models the Cortex-M3 core in a highly accurate fashion and the memory interfaces in a protocol accurate fashion. These simulators support TI BIOS based applications development and benchmarking.
Simulators support the following rich set of debug and analysis features:
- Several Stellaris Evaluation kits (LM3S9B90, LM3S9B92, etc.) come with a 10 pin ARM connector and an ICDI. To connect an external emulator (XDS100, XDS510 or XDS560) you will need the 10 pin ARM target to 20 pin ARM emulator adapter (available here).
- If using the adapter above or a Stellaris board that has a 20-pin ARM connector, a TI 14 or 20-pin to ARM 20-pin adapter may be required (models here). The more featured emulators have these adapters already bundled, but if that is not the case you can either get one directly from TI estore or from your 3rd party tools vendor.
- Depending on the emulator, a modification to the adapter may be required due to the routing of JTAG signals. Check the emulation connection page here.
What is not supported
- Serial Wire Output for TPIU trace output
- Standard Console I/O operations (fread, fwrite, fopen, etc.) are not yet supported on the current release of CCS when using the on-board emulator
What CCS License types support Stellaris?
Stellaris is supported by both Platinum and Microcontroller licenses starting with CCSv4.1. There will not be a code size limited version (MCU Core) for Stellaris. You can use the Stellaris development kits with the free bundle license. With the free license you are restricted to using the development board that comes with the Stellaris development kits, there will be no code size limit.
Getting started with CCS and Stellaris
- Check the QuickStart Guide first
- Considerations about the configuration and compatibility of XDS emulators and CCS are shown at:
- You can also take the Getting Started with StellarisWare workshop that uses CCS
The Profile Clock is disabled due to Hardware limitations of the Cortex M core. However, CCS can still profile by reading the SCTM registers.
To enable this feature:
- From the Main Menu in the Debug View, Select View->Breakpoints
- The Breakpoints window will be added to the View. A Count Event can be selected from the drop-down menu, next to the three breakpoints icon, as shown below.
- This gives you the option to select an event to count Clock Cycles.
- Enable a breakpoint in your code by double-clicking on the source file. Select the Run icon. When the breakpoint is reached the Count Event will display the number of Clock Cycles.
You can also set two breakpoints to count the number of events between two places in your code (useful to profile functions):
- Enable the count event as shown above, then right-click on its entry in the Breakpoints view, select Properties and check the box marked Reset Count on Run. This will make the Event counter reset every time the processor is put to run, therefore allowing counting events withing breakpoint boundaries.
- Set two breakpoints in your code:
- Run to the first breakpoint. The Event counter will count the number of cycles up to this point in your code. You can disregard this number.
- Run to the second breakpoint. This time the Event count will show the number of cycles between the first and the second breakpoint.
Important! The number of CPU cycles greatly varies with the type of memory being used (Flash, RAM, external) and if the code needs to wait for a peripheral to respond, therefore keep this in mind when interpreting the results obtained.
Hardware Breakpoints Limitations
Warning! As with any debugging environment where the code is loaded to non-volatile memory (FLASH in this case), the number of Hardware Breakpoints is relatively small. The breakpoint manager lets you configure all the hardware resources in the system as you please, and if you happen to use them all up, there may not be enough to perform other activities as a result (more on this below).
The Breakpoint Manager for this device shows the message below when the maximum number of hardware breakpoints is reached:
"Breakpoint Manager: Error programming AET Job: There is no AET resource to support this job.".
I am respecting the number of hardware breakpoints available but I still get the error message above when stepping in my code. Why?
- This happens if you select the maximum amount of Hardware Breakpoints allowed then attempt to step through the code. F6 is a step over which is implemented detecting if a function call is present, stepping into if not, or setting a temporary breakpoint after the call and running if there is one. As such, if all hw breakpoints are used up, and the code you are stepping is in ROM (so you can't use software breakpoints), then step over won't be possible if on a function call.
RTS Library Selection
- Output Format - early CCSv4.1.x releases do not automatically update the RTS Library file when the output format is changed. If you change the output format from ELF to COFF you must also update the RTS library file.
- This is fixed in CCSv4.2.4 and newer.
Note: Not an Issue but a Warning The Stellaris devices use little endian, therefore the device endianess should be selected as “little” in the Project Settings. If you receive an error similar to the following you should verify the device endianess selected.
fatal error: object files have incompatible byte orderings ("C:/Program Files/Texas Instruments3/ccsv4/tools/compiler/tms470/lib/rtsv7M3_T_le_eabi.lib<boot.obj> " = little endian, "./blinky.obj" = big endian)
Frequency out of range error
One of the causes that throw a "frequency out of range" error (while trying to connect to a Stellaris device using an ICDI) is the improper installation of USB device drivers.
To solve that, open the Device Manager: right-click on the icon My Computer --> select Properties --> (if using XP, select the tab Hardware --> click on Device Manager and see if the option Other devices shows any entries named Stellaris with an exclamation mark. If so, right click and select Update Driver Software... (Update Driver if using XP) and browse to the placement of Stellaris device drivers inside the CCS install directory.
- CCSv4: <CCS_INSTALL_DIR>\ccsv4\emulation\drivers\stellaris
- CCSv5: <CCS_INSTALL_DIR>\ccsv5\ccs_base\emulation\drivers\stellaris
General information about Simulators: Category:Simulation