Common Problems and Questions

Cannot import project ZIP archive

Problem: When trying to import a project from a ZIP archive (the recommended method), the “Import CCS Projects” dialog does not allow the project to be selected within the “Discovered projects:” selection area and there is a red “X” on the project in this view. The likely cause of this is due to the project, or a project with the same name, already exists in the workspace. Check the “Project Explorer” window to verify this is the case.

Solution: You have two options here:

Delete the existing project from the workspace. To do this, right click the project in the “Project Explorer” and select Delete. In the “Delete Resources” dialog that will show up, ensure that Delete project contents on disk is selected and then click OK.
Rename the existing project within the workspace. To do this, right click the project in the “Project Explorer” and select Rename…. Give the project a new name in the “Rename Resources” dialog and click OK.

When either of the two options above are complete, the new project may be imported.

Warning

A secondary error may also arise when trying to import the project when step 1 above was followed except that Delete project contents on disk was not selected. In this case, the project folder still exists in the workspace folder but is not recognized by CCS as a project.

To solve: navigate to the workspace folder (not within CCS) and manually delete the folder.

Debug Error: Target must be connected before loading program

Problem: When attempting to debug a project, the error shown below is returned and the debug session fails. This is due to CCS incorrectly importing the project for unknown reasons.

Texas Instruments XDS110 USB Debug Probe/CORTEX_M4_0 : Target must be connected before loading program.

Solution: Right click the project within the Project Explorer pane and select Debug As → Debug Configurations…. Within the dialog that appears, select the Target tab within the right pane, then select Auto Run and Launch Options. Under Launch Options, ensure that Connect to the target on debugger startup is selected and click Apply. Debugging should work correctly now.

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 Terminal pane.

Solution: Connect or reconnect the terminal by selecting the Open a Terminal term icon within the Terminal pane or on the toolbar.

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 MSP432P401R 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 MSP432P401R 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 MSP432: 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 MSP432 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 MSP432, as configured for this course, has a CPU speed of 24 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(240e3);    // 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(240e3);
// Wait for release
__delay_cycles(240e3);
presses++;