1       Simple Debug Tip

A large majority of the time, the simplest way to track down the source of the issue (and WHY the issue is happening) is by taking an oscilloscope (logic analyzer) capture of the SCI-TX and SCI-RX pins of the device.

The reason this is so effective is because it immediately rules out/in several key causes:

1. Hardware issues are immediately evident by strange waveform behavior.
2. Configuration and system-level issues are simple to see since one line may be working and the other not.
3. Lack of output is immediately evident.
4. If the data is present, but not being received in the registers, code issues are easy to track down.
5. Issues where the data is present, but the wrong values, is easy to debug with wavefroms through elimination of either code (bad waveform, bad data) or configuration (good waveform, bad data) as the issue.

Because of this, I highly recommend using some kind of waveform-viewing device to troubleshoot first. If this does not immediately make the issue obvious, the next section walks through more in-depth debug steps.

2       Finding the Source of the Issue

What is the actual issue observed? Find your issue in the lists below, then use the information provided to debug further. NOTE: some issues may fall into more than one category/issue description, and so should be debugged using relevant information from all sections.

2.1     Hardware Issue Symptoms and Causes

• Debugger not working properly (or at all).
  • Cause: JTAG connection issue. For instructions on resolving JTAG and debugger-related issues, please see https://www.ti.com/lit/SPRACF0 for a full walkthrough on debug steps.
• Incorrect SCI waveform on SCI-RX pin (not returning to high).
  • Cause: Incorrect circuit in SCI-TX path (if the other non-C2000 device’s software/hardware are validated to work correctly when isolated from the circuit).
    • The RX pins of SCI/UART protocol devices require a pull-up resistor in the circuit to allow for the signal to return to high logic level without being driven. The pull-up resistor must be chosen carefully to not be too large of a value (weak) so that it does not actually pull up a tri-stated or floating output from another device. A weak pull-up may also be susceptible to noise. The pull-up resistor must also be chosen to not be too small of a value (strong) so that it doesn’t prevent the output signal from toggling from the other device. This pull-up resistor decision is heavily dependent on application, so saying “use X resistance” will not always be true. However, 10kOhm is typically a sufficient starting point to begin testing in-application what resistances will work. This must be tested by the user for the particular application and expected system expectations.
    • It is also worth noting that a pull-down resistor would be harmful to proper function. This is why resistor-dividers used to step-up/down logic levels cannot be used in the SCI-TX/RX paths, as they GND reference of even a moderately weak pull-down will always pull the voltage back to GND when not driven. This leads to BRKDT being flagged and other errors in the system.
• Incorrect SCI waveform on SCI-TX pin or RX pin of other device in system (not returning to high).
  • Cause: Incorrect circuit in SCI-TX path (if verified to NOT be a software issue).
    • Similar to the SCI-RX pin, the SCI-TX pin expects that the other device’s RX pin will have a pull-up on the other end for both noise immunity and enforcing a return-to-high logic level. If this pull-up resistor is missing, the other device may not return to the proper logic level, and will receive incorrect signals. Note that the C2000 SCI-TX pin will return-to-high logic level when the module is enabled, but any transceivers in between the C2000 device and the other device may not enforce return-to-high without a pull-up.
    • It is also worth noting that a pull-down resistor would be harmful to proper function. This is why resistor-dividers used to step-up/down logic levels cannot be used in the SCI-TX/RX paths, as they GND reference of even a moderately weak pull-down will always pull the voltage back to GND when not driven. This leads to BRKDT being flagged and other errors in the system.
• Correct data visible on pins, but not being received at all by the other device
  • Cause 1: Missing transceiver to C2000 device:
    • It must first be noted that any C2000 device communicating to/from a PC (personal computer) must have a transceiver to translate between USB (PC) and UART (C2000 SCI module) protocols. There may be intermediary protocols between USB and UART, such as RS232. Regardless, the PC USB signal must be translated to UART protocol to be interpreted by the C2000 device’s SCI module (or any other UART device). Some C2000 LaunchPads and ControlCARDs development boards have on-board transceivers connected to particular GPIO/SCI pins. Typically, these are built-in with the USB JTAG debug emulator, but are not available on all C2000 devices. Please see the particular development board’s user guide (located on the product page) for details on whether a transceiver is built-in to the board or not. Key words to search for in the user guide are “UART”, “COM port”, or “SCI”.
  • Cause 2: Incorrect transceiver circuit (assuming that a transceiver is present).
    • It is critical to ensure that a pull-up resistor is supplied on the RX pin. This applies to the RX pin of any C2000 device, and also applies to any other UART protocol device in the system that is receiving from a transceiver. This is because some transceivers do not force the voltage back to high in between packets of data. This can lead to a floating voltage that may behave incorrectly, either staying low between packets, or toggling randomly with noise in the environment. This can be observed by looking at the waveform at the RX pin of the C2000 device or the RX pin of the other device in the system. In most cases, it is essential to include a pull-up resistor on the RX pin on all UART protocol devices in the system.
• Consistent BRKDT (break-detect) errors in SCI module of this device or other device.
  • Cause: Incorrect circuit in SCI-RX/TX path.
    • For this issue, any (or all) of the above hardware issues can be the root cause of this. Please review the above hardware issues mentioned for details on debug reasoning. The summary for the root cause of this issue is that a pull-up resistor is required on the SCI-RX pin to provide proper return-to-high signal behavior and noise immunity.

2.2     System Issue Symptoms and Causes

• C2000 device or other connected device randomly flagging BRKDT (break-detect) errors.
  • Cause: If BRKDT is being observed in this C2000 device (and any issues in the “hardware issue” section above have been resolved), then this is likely an issue in the software of the other device in the system. Place an oscilloscope on the C2000 SCI-RX line and observe for a low-signal greater than 9.625 bits wide. If this is found, please correct the software in the other device that is transmitting to this C2000 device. There should never be a low-signal greater than 9.625 bits wide on the SCI-RX line of the C2000 device.
• Garbled/random data values being received on this C2000 device (not the other SCI device in system).
  • Cause 1: Incorrect packet or terminal configuration on the other device. The other device must match all of the following items from this C2000 device:
    • (1) baud rate
    • (2) number of data bits
    • (3) parity bit existence
    • (4) number of stop bits
    • (5) “Hardware” or “Flow” control = None (or XON/XOFF in some systems)
  • Cause 2: Sending ASCII data to this C2000 device but expecting HEX (or vice-versa).
    • If the other device is sending char data to the C2000 device, C2000-provided examples and functions store that data as individual chars. For example, the code will not automatically convert a char array received of “100” to the integer 100. This will instead be stored as three chars: [“1”,”0”,”0”]. Conversions must be done from char arrays to integers using C functions such as “strtol()”.
• Garbled/random data in both devices
  • Cause: Mismatched configuration settings. The other device must match all of the following items from this C2000 device:
    • (1) baud rate
    • (2) number of data bits
    • (3) parity bit existence
    • (4) number of stop bits
    • (5) “Hardware” or “Flow” control = None (or XON/XOFF in some systems)

2.3     Configuration Issue Symptoms and Causes

• Garbled/random data values being received on other SCI device in system (not this C2000 device).
  • Cause 1: Mismatched configuration settings. The other device must match all of the following items from this C2000 device:
    • (1) baud rate
    • (2) number of data bits
    • (3) parity bit existence
    • (4) number of stop bits
    • (5) “Hardware” or “Flow” control = None (or XON/XOFF in some systems
  • Cause 2: Missing “_LAUNCHXL_F28XXXX” pre-define symbol.
    • Some C2000 boards require a predefine symbol to correctly set the clock and other configuration settings on the device. Please view the “device.h” file of the project and see if there are any #ifdef lines that use pre-defined symbols like the above.
    • If a symbol like “_LAUNCHXL_F28XXXX” exists, AND that is the board you are using for your tests, you will need to add this pre-defined symbol.
    • In CCS, right click the project being used, then choose Properties → Build → C2000 Compiler → Predefined Symbol → then choose the plus button “add” symbol. Add the given pre-define symbol for your particular device that was found in the device.h file (like “_LAUNCHXL_F280025C”).
    • 
• Interrupts not firing at expected time (or at all).
  • Cause 1: Incorrect muxing (if not firing at all). GPIO Mux options must be configured properly.
    • Try using the Sysconfig tool (built into new versions of CCS and C2000Ware) to configure the SCI module and its PinMux options. This provides a graphical interface for easy configuration of the pins
    • Alternatively, ensure the following are set properly in driverlib:
      • Set the RX and TX pin config using driverlib calls like:
        • GPIO_setPinConfig(GPIO_17_SCIA_RX);
        • GPIO_setPinConfig(GPIO_16_SCIA_TX);
      • Alternatively, ensure the following are properly set using your code:
        • Make sure pullup is enabled (in GP@PUD register) in the GPIO configuration for the pins used
        • Make sure qualification is set to asynch input only (in GP@QSEL# register) in the GPIO configuration, for the pins used
        • Make sure the correct GPIO mux option is chosen (in GP@MUX# register) to allow for SCI-TX and RX to pass through the GPIO
  • Cause 2: Incorrect configuration of ePIE or FIFO (if not firing intermittently or at all).
    • Try using the Sysconfig tool (built into new versions of CCS and C2000Ware) to quickly set up the interrupt and/or FIFO configurations.
    • Alternately make sure the following procedure is done to configure the SCI module during initialization (do these in order):
      • First, ensure all SCI interrupts are disabled
      • Next, clear the interrupt status of all SCI interrupts (RXFF, TXFF, FE, OE, PE, RXERR, BRKDT, TXRDY) by clearing and then setting SCI’s CTL1.SWRESET bit and setting SCI’s FFTX.TXFFINTCLR and FFRX.RXFFINTCLR bits.
      • Next, clear the overflow status bit by setting SCI’s FFRX.RXFFOVRCLR bit
      • Next, reset the RX and TX FIFOs by clearing and then setting the FFTX.TXFIFORESET
      • Next, reset the TX and RX channels of the device by clearing and then setting the FFTX.SCIRST bit.
      • Next, actually configure all the SCI settings for your system, like baud rate (SCIHBAUD+SCILBAUD registers), parity+data length+stop bits (SCICCR register).
      • Next, enable the module by setting CTL1.TXENA, CTLA.RXENA, and CTL1.SWRESET. This also performs a software reset of the SCI module to prepare it for running.
      • Next, if using the FIFO, set the appropriate FIFO interrupt levels by setting the levels in the FFTX.TXFFIL and FFRX.RXFFIL fields. The FIFO levels must be chosen to allow sufficient time for the interrupt to handle the data requests before FIFO overflows. For long SCI ISRs, make sure to interrupt sufficiently early, or move the processing out of the ISR and only do data movement in the SCI ISR (recommended).
      • Finally, if using the FIFO, enable the FIFO by setting the FFTX.SCIRST (if not set, though it is safe to set again), FFTX.SCIFFENA, FFTX.TXFIFORESET, and FFRX.RSFIFORESET bits.
      • Finally, enable the module again by setting the CTL1.TXENA, CTLA.RXENA, and CTL1.SWRESET bits. This also performs a software reset of the SCI module to prepare it for running.
  • Cause 3: Conflicting or starved interrupt.
    • When interrupts of higher priority occur very frequently (or are allowed to nest within the SCI ISR), it is possible that they may prevent the SCI module from receiving all the data. They can essentially “starve” the SCI interrupt by being higher priority and always going before the SCI module gets a chance to start.
      • For example, if an ADC interrupt keeps firing and interrupting the SCI ISR, the SCI ISR may never (or slowly) get to the part where it moves the data over. If the buffer or FIFO fills up before the SCI gets to move the data, this could lead to data being missed and the buffer or FIFO overflowing. This requires careful interaction between the ISRs so that neither the ADC ISR (for example) nor the SCI ISR get starved for processing time.
    • It is also possible for other non-nesting interrupts to take so long to complete that the SCI buffer/FIFO fills up and additional data gets lost. This is rare, since SCI transmit times are often much slower than processing times. But there are some calculations in other ISRs that may take a very long time, and so care must be taken in those as well.
• Output works correctly on SCIA/B/C, but does not work correctly on SCIC/B/A.
  • Cause 1: Incorrect mux configuration.
    • Try using the Sysconfig tool (built into new versions of CCS and C2000Ware) to configure the SCI module and its PinMux options. This provides a graphical interface for easy configuration of the pins
    • Alternatively, ensure the following are set properly in driverlib:
      • Set the RX and TX pin config using driverlib calls like:
        • GPIO_setPinConfig(GPIO_17_SCIA_RX);
        • GPIO_setPinConfig(GPIO_16_SCIA_TX);
      • Alternatively, ensure the following are properly set using your code:
        • Make sure pullup is enabled (in GP@PUD register) in the GPIO configuration for the pins used
        • Make sure qualification is set to asynch input only (in GP@QSEL# register) in the GPIO configuration, for the pins used
        • Make sure the correct GPIO mux option is chosen (in GP@MUX# register) to allow for SCI-TX and RX to pass through the GPIO
  • Cause 2: Incorrect ePIE configuration (if using interrupts).
    • Try using the Sysconfig tool (built into new versions of CCS and C2000Ware) to quickly set up the interrupt and/or FIFO configurations.
    • Alternately make sure the following procedure is done to configure the SCI module during initialization (do these in order):
      • First, ensure all SCI interrupts are disabled
      • Next, clear the interrupt status of all SCI interrupts (RXFF, TXFF, FE, OE, PE, RXERR, BRKDT, TXRDY) by clearing and then setting SCI’s CTL1.SWRESET bit and setting SCI’s FFTX.TXFFINTCLR and FFRX.RXFFINTCLR bits.
      • Next, clear the overflow status bit by setting SCI’s FFRX.RXFFOVRCLR bit
      • Next, reset the RX and TX FIFOs by clearing and then setting the FFTX.TXFIFORESET
      • Next, reset the TX and RX channels of the device by clearing and then setting the FFTX.SCIRST bit.
      • Next, actually configure all the SCI settings for your system, like baud rate (SCIHBAUD+SCILBAUD registers), parity+data length+stop bits (SCICCR register).
      • Next, enable the module by setting CTL1.TXENA, CTLA.RXENA, and CTL1.SWRESET. This also performs a software reset of the SCI module to prepare it for running.
      • Next, if using the FIFO, set the appropriate FIFO interrupt levels by setting the levels in the FFTX.TXFFIL and FFRX.RXFFIL fields. The FIFO levels must be chosen to allow sufficient time for the interrupt to handle the data requests before FIFO overflows. For long SCI ISRs, make sure to interrupt sufficiently early, or move the processing out of the ISR and only do data movement in the SCI ISR (recommended).
      • Finally, if using the FIFO, enable the FIFO by setting the FFTX.SCIRST (if not set, though it is safe to set again), FFTX.SCIFFENA, FFTX.TXFIFORESET, and FFRX.RSFIFORESET bits.
      • Finally, enable the module again by setting the CTL1.TXENA, CTLA.RXENA, and CTL1.SWRESET bits. This also performs a software reset of the SCI module to prepare it for running.
• Loopback example works correctly, but no output seen on pin.
  • Cause 1: Incorrect mux configuration.
    • Try using the Sysconfig tool (built into new versions of CCS and C2000Ware) to configure the SCI module and its PinMux options. This provides a graphical interface for easy configuration of the pins
    • Alternatively, ensure the following are set properly in driverlib:
      • Set the RX and TX pin config using driverlib calls like:
        • GPIO_setPinConfig(GPIO_17_SCIA_RX);
        • GPIO_setPinConfig(GPIO_16_SCIA_TX);
      • Alternatively, ensure the following are properly set using your code:
        • Make sure pullup is enabled (in GP@PUD register) in the GPIO configuration for the pins used
        • Make sure qualification is set to asynch input only (in GP@QSEL# register) in the GPIO configuration, for the pins used
        • Make sure the correct GPIO mux option is chosen (in GP@MUX# register) to allow for SCI-TX and RX to pass through the GPIO
  • Cause 2: Incorrect ePIE configuration (if using interrupts).
    • Try using the Sysconfig tool (built into new versions of CCS and C2000Ware) to quickly set up the interrupt and/or FIFO configurations.
    • Alternately make sure the following procedure is done to configure the SCI module during initialization (do these in order):
      • First, ensure all SCI interrupts are disabled
      • Next, clear the interrupt status of all SCI interrupts (RXFF, TXFF, FE, OE, PE, RXERR, BRKDT, TXRDY) by clearing and then setting SCI’s CTL1.SWRESET bit and setting SCI’s FFTX.TXFFINTCLR and FFRX.RXFFINTCLR bits.
      • Next, clear the overflow status bit by setting SCI’s FFRX.RXFFOVRCLR bit
      • Next, reset the RX and TX FIFOs by clearing and then setting the FFTX.TXFIFORESET
      • Next, reset the TX and RX channels of the device by clearing and then setting the FFTX.SCIRST bit.
      • Next, actually configure all the SCI settings for your system, like baud rate (SCIHBAUD+SCILBAUD registers), parity+data length+stop bits (SCICCR register).
      • Next, enable the module by setting CTL1.TXENA, CTLA.RXENA, and CTL1.SWRESET. This also performs a software reset of the SCI module to prepare it for running.
      • Next, if using the FIFO, set the appropriate FIFO interrupt levels by setting the levels in the FFTX.TXFFIL and FFRX.RXFFIL fields. The FIFO levels must be chosen to allow sufficient time for the interrupt to handle the data requests before FIFO overflows. For long SCI ISRs, make sure to interrupt sufficiently early, or move the processing out of the ISR and only do data movement in the SCI ISR (recommended).
      • Finally, if using the FIFO, enable the FIFO by setting the FFTX.SCIRST (if not set, though it is safe to set again), FFTX.SCIFFENA, FFTX.TXFIFORESET, and FFRX.RSFIFORESET bits.
      • Finally, enable the module again by setting the CTL1.TXENA, CTLA.RXENA, and CTL1.SWRESET bits. This also performs a software reset of the SCI module to prepare it for running.

2.4     Code Issue Symptoms and Causes

• Some data being missed (rest of data looks correct)
  • Cause 1: Data or interrupt overflows
    • If SCI interrupts are not serviced once the buffer (or FIFO, if used) is full, then any additional data that comes in will be missed. This leads to a loss of data. The solution is to ensure that the buffer or FIFO is serviced with sufficient time before the next group of data comes in. This same solution applies to SCI polling, where interrupts are not used, because a full buffer or FIFO still must be emptied before additional data comes in to prevent data loss.
  • Cause 2: Starved interrupt
    • When interrupts of higher priority occur very frequently (or are allowed to nest within the SCI ISR), it is possible that they may prevent the SCI module from receiving all the data. They can essentially “starve” the SCI interrupt by being higher priority and always going before the SCI module gets a chance to start.
      • For example, if an ADC interrupt keeps firing and interrupting the SCI ISR, the SCI ISR may never (or slowly) get to the part where it moves the data over. If the buffer or FIFO fills up before the SCI gets to move the data, this could lead to data being missed and the buffer or FIFO overflowing. This requires careful interaction between the ISRs so that neither the ADC ISR (for example) nor the SCI ISR get starved for processing time.
    • It is also possible for other non-nesting interrupts to take so long to complete that the SCI buffer/FIFO fills up and additional data gets lost. This is rare, since SCI transmit times are often much slower than processing times. But there are some calculations in other ISRs that may take a very long time, and so care must be taken in those as well.