Common Problems and Questions

Output not showing on terminal

Problem: When debugging and running the code, expected printf() output is not displayed within the terminal. The most common causes for this are that either 1) the terminal is not connected (even if the Terminal pane is visible) and/or 2) the Console pane is being watched instead of the Serial Console pane.

Solution: Connect or reconnect the terminal by following the instructions here.

CCS Says “Select a Project”

Problem: When trying to compile a project, CCS throws an error, asking the user to select a project. This is because the project was not imported correctly.

Solution: Ensure to follow the instruction for importing projects here: 3. Test Project.

CCS Stuck “Building” Project

Problem: When trying to compile and/or debug a project, CCS will start the compile, or “Building” process but will get stuck on this step. This is a bug in CCS where the compilation happens correctly but with errors and CCS doesn’t finish the process of displaying the result. Fixing one or more of the compile issues that occur will prevent it from getting stuck but are hard to find without the compiler output.

Solution: Within the project, right click on the Debug folder and select Open in Integrated Terminal. This opens a command line interface, typically on the bottom pane of the CCS window. Within that command line interface, enter the command:

Windows: C:\ti\ccs<version>\ccs\utils\bin\gmake all

Linux: Two options:

make all, assuming make is installed.

~/ti/ccs<version>/ccs/utils/bin/gmake all.

MacOS: TBD

for the commands above, ccs<version> is the original installed version of CCS. For Fall 2025 this would be ccs2020. This may be determined by typing in the first portion of the command, e.g., C:\ti\ccs, and then using tab-complete to determine the correct folder for the version. The paths above assume the default install location is used.

These commands will compile the project from command line where the problems with the compilation can be reviewed. Fix these and the building process within CCS should start working again.

CCS Says “Error connecting to the target: DAP Connection Error”

Problem: When trying to debug/program the Launchpad Board, CCS will fail and throw the above error. This is because pins PA19 and PA20 are being modified, which are required for the debugger’s connection.

Solution: First, review the code and ensure that PA19 and PA20 are not being modified (the error could arise from the previous user of the Launchpad Board). Once that is confirmed and/or fixed, unplug the Launchpad Board, then hold the button S1 on the devboard and plug the Launchpad Board back in. The button may be released after plugging back in. Debugging should now be possible.

For the RSLK, the button S1 is located underneath the protoboard near the green light.

CCS Says “Cannot Find Target Configuration”

Problem: When trying to run a project, CCS will compile the project but fails to download to the microcontroller, stating that it “Cannot Find Target Configuration”. Commonly associated with this error is seeing the project name in the project explorer preceded by Folder: **; and the workspace is given as **UNTITLED ### where the ### is some letter and numbers.

Solution: This error is because CCS is not opened in a proper workspace. To fix, go to File → Open Recent Workspace…. The default workspace is workspace_ccstheia, so select that one. Then re-import the project.

CCS Says “Error: spawn ./DSLite ENOENT”

Problem: When trying to run a project, CCS will compile the project but fails to download to the microcontroller, giving the message “Error: spawn ./DSLite ENOENT”. This error is likely due to a antivirus/firewall blocking the launching of the helper program, “DSLite”.

Solution: Incrementally disable antivirus/firewall features and attempt to debug the project. This will identify the functionality that is interfering with CCS. Depending on the program, it may be possible to add an exception to avoid this issue while still allowing the antivirus/firewall to operate.

Some pins are cut off of the Launchpad Board/RSLK

Problem: The Launchpad Board or RSLK (actually, a Launchpad Board mounted on the RSLK) has one or more [header] pins cut off, making it impossible to connect circuitry to them. This is done to denote that the MSPM0G3507 GPIO pin connected to the corresponding header pin has been burnt out, commonly by misuse: for example, connection of the 5.0 V supply (either from ADALM1000 or Launchpad Board to the pin) to a GPIO pin will cause it to fail.

Solution: If the pin is absolutely required, then another Launchpad Board or RSLK must be used. In many instances, the required pin to be used can be changed. Ask an instructor for guidance.

GPIO output pin configuration is correct but doesn’t work

It is not uncommon for I/O pins to fail on microcontrollers; especially for ones mounted on development boards where the pins are free to be connected to various signals. If the pins on the MSPM0G3507 are connected to a voltage higher than 3.3V, a failure is likely the pins are not designed to support voltages over 3.3V.

The IO Test project may be used to perform a quick test on all almost all the pins on the MSPM0: IO_Test.zip. Nothing should be connected to the pins during this testing.

Why are there port/pin numbers labelled on the car?

As noted above, the I/O pins a susceptible to failure. The labels on the car list the pins that are known bad on the car. Please note that additional pins may have failed since this label was added. If you identify a car with additional failed pins (via the IO_Test.zip or other methods), please let us know the car # and pin # so we can update the label.

In the short term, we may place a wire plug in the header where the pin is accessible to identify it as a bad pin. This plug is short piece of wire that blocks access; but can be pulled out. Please don’t pull them out!

Why are there small wires in the headers of the car?

See paragraph above.

Multiple button presses detected for one physical button presses

Problem: Buttons, in their simplest form, are usually two pieces of metal that come into contact with each other to form an electrical connection. These pieces of metal behave according to the laws of nature: what happens when two objects impact each other? For elastic impacts (relevant here), they will bounce apart. Electrically, they will connect, then disconnect, then connect, etc., until the energy of the impact has dissipated enough such that the contacts will remain connected. This may also occur when the button is released as well, although less likely as the contacts are separating (not impacting) as opposed to connecting (impacting).

Button Presses: Ideal versus Bouncing

This “bounce” will happen quickly within buttons (usually within milliseconds); however, processors/microcontrollers operate on a much faster time scale. Due to this, a program may sense multiple button presses for a single physical press.

Solution: This behavior can be corrected or compensated for in many ways, both through hardware and software modifications. An easy “debounce” solution to this is to ignore any button activity for a small amount of time after a state change is detected. We can do this within the MSPM0 by using the intrinsic function delay_cycles(), which will cause the program to pause for a specified number of CPU cycles. For example, the code below will delay 1 million cycles. The MSPM0, as configured for this course, has a CPU speed of 32 MHz; therefore, this code is effectively a 10 ms delay. A 10 ms delay is good enough for most switches but some “dirty” switches may require 20 ms or more.

delay_cycles(320e3);    // 10 ms delay

Delaying the program for a short amount of time after a button press or release is detected will allow for the button to complete bouncing before the state of the input is checked again, thereby eliminating multiple presses detected from a single physical press. For example: to count button presses, the code format could be as follows:

// Press detected
delay_cycles(320e3);
// Wait for release
delay_cycles(320e3);
presses++;