Tales of Project Troubleshooting: Solutions from a Problem-Magnet

Electrical engineering is an increasingly complex subject that requires engineers to be well versed in several simultaneous fields. Whenever attempting a new discipline or design, problems will occur. This article covers examples of the various roadblocks encountered in a new design and how they were troubleshot and overcome.

Several months ago, I pitched the idea for a capacitive-touchpad interface based on Texas Instruments' MSP430FR2633. The project would require the fabrication of two circuitboards—one that housed the control electronics and one that had the touchpad. The project would require the creation of a custom control interface, and the addition of Silicon Labs' CP2102N programmable USB-to-serial converter.  

Several stumbling blocks were encountered along the way that required a decent amount of troubleshooting to overcome. The CP2102N could not be programmed by the computer and the custom control interface could not be ordered from multiple fabrication houses. This article explains the problems encountered and the steps taken to overcome them.

Problem 1: Cannot Program the CP2102N

The CP2102N is the latest USB to UART Bridge from Silicon Labs. The older versions of the product line, the CP2101, CP2102, CP2104, CP2109 can all be replaced with one of the CP2102N packages (QFN 20, QFN 24, QFN 28). The older versions are still sold but are not recommended for new products, as the CP2102N is an all-in-one replacement. It has multiple GPIO pins, and the QFN 28 package supports charging circuits.

I selected this device based on its cost and a recommendation from Silicon Labs for new product development. Adding it to a design isn’t terribly difficult. A series of decoupling capacitors are used on the power pins, an electrostatic discharge (ESD) diode array is added to the connector to protect the IC from static discharge, and some LEDs are added to confirm UART communication with the microcontroller.

 

 

The Problem

When I connected my brand new circuit board to my computer, the CP2102N showed up in device manager, which is good.

 

Screenshot of device in Windows Device Manager

 

However, every attempt that I made to program it through Simplicity Studio’s XPress Configuration utility resulted in a failure with an error that indicates there is “no SoftIndex...select a different device.”

 

The "No SoftIndex" error from Simplicity Studio

 

As additional devices are added to the system the device is assigned an ID by Simplicity Studio. The first device is ID:0, the second device is ID:1, and so forth. The Simplicity Studio Software is unable to communicate with the device for programming.

This was especially confusing since I was able to use my oscilloscope and the program PuTTY to confirm that the chip was performing USB-to-UART conversion, which meant the device was functioning as intended and communicating with my computer. 

 

Troubleshooting

I went down several wrong paths trying to troubleshoot the problem from the software side of things.

Unsure of my initial design, I purchased a CP2102N evaluation kit from Digi-Key to experiment with. I had the same problems with the kit as I did with my custom board, which led me to believe the problem was with my computer.

Next, I ensured that I had the correct drivers installed, and removed the Device Instance ID for the installed devices using the registry editor.  

Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\USB\VID_10C4&PID_EA60\xxxxxxxxx

I hoped that the hardware would enumerate correctly upon replug. Unfortunately, when I replugged the device and allowed it to enumerate again it had the same failures.  

At this point, I realized that I was out of my depth and I began to collect information that I might send to Silicon Labs' tech-support.

USBDeview allows users to collect information about the USB devices on Windows-based system. All of this information is available through the device manager, the utility just organizes it on a single page in an easy to read fashion.

 

 

I also used the event viewer to generate an XML file of this information to provide to the SiLabs support.

 

AHA! (Finding the Root Issue)

After several back and forths with tech support, we began to realize the problem—a problem that the agent I was working with had not previously encountered. The CP2102N devices have a very long internal serial number (128-bit) that is read by the computer and used to set the Device Instance Path in the registry. However, the hexidecimal representation was being chopped—all digits of the serial number that have values 0xA, 0xB, 0xC, 0xD, 0xD, 0xE, or 0xF were replaced with 0.

 

The serial number used to create the device instance ID (highlighted in blue) should be in hexadecimal, rather than a decimal representation. Values greater than 0x9 are replaced with 0 during enumeration.  The correct serial number is shown immediately below the flawed one.

 

Simplicity Studio shows the CP2102N device (ID:0) with the correct internal hexadecimal serial number of the device (highlighted in blue).

 

It appears that Simplicity Studio uses the correct serial number in hexadecimal. However, as far as Windows is concerned, there is no such device on the system because Windows is using a chopped serial number. When Simplicity Studio attempts to program the device, it simply cannot find it. The problem appears to be unique to select USB3.0 ports.

 

Solutions

There are multiple ways to work around this problem:

• Plug the CP2102N device into a USB2.0 port (if your system still has one) and it will enumerate correctly. 
  --or--
• Plug the device into a USB2.0 port on a different computer system.
  • Use Simplicity Studio Express Configurator to set a custom serial number (e.g. AAC20180112)
• Return the device to the original host computer port and it should work.

If this becomes a larger problem for users, someone with experience with Windows device drivers will have to investigate the specific USB3.0 drivers in question and determine what is causing that serial number to go wonky.

Alternatively, a software workaround in Simplicity Studio might alleviate the problem (look for the device at both the correct and incorrect chopped device instance identifier).

Problem 2: Cannot Upload Touchpad Interface to Fabrication House for Production

Part of this project allowed me to learn how to create a custom capacitive slider. Unfortunately, I was unable to upload it in any format (Gerber files, odb++, etc…) to any of the usual fab houses we use. (Macrofab, Oshpark, etc…)

 

This was approximately the same time that I was working on a different circuit board with a custom designed coil, and it had similar upload issues.

 

 

The Problem

Unfortunately, there were no useful errors reported during upload. The programs would just endlessly attempt to process the files. Since the problem persisted across multiple fab-houses and multiple circuit board designs, I incorrectly assumed that the issue was with the PCB layout software I was using (DipTrace). So I started my troubleshooting there.

 

Troubleshooting

Diptrace customer support confirmed for me that the files I was generating were not corrupt and could be loaded by CAM350. That pushed my questions to the fabrication houses. Perhaps there was an issue with the user interface? 

So I emailed the files to Osh-park customer support and eventually came upon Dan Sheadel, a gentleman who understands Gerber standards more than I ever will.  

 

AHA! (Finding the Root Issue)

The fab-houses that I work with use a bit of software called GerbV. It’s free and open source, but it does not completely conform to the Gerber standards. Gerber files are made up of a series of vectors (numbers) and instructions (attributes) that correspond to machine coordinates and movements.

Inside of each file, repetitive sets of vectors and attributes can be clumped in an aperture—a subset of relative vectors and instructions that can be executed in multiple positions throughout the layer—apertures are most often used for pads. The Gerber standard allows apertures to have around a thousand lines of code, however, GerbV does not conform to the standard and limits an aperture to approximately 100 lines of code.

 

 

GerbV Error message indicating that the number of points in the aperture macro exceeds the number that it can handle.

You can read some of my communications with Dan on the subject in my article, Building a Capacitive Touch Interface with the Texas Instruments MSP430FR2633.

 

Solutions

The workaround is to eliminate the apertures entirely and convert the relative vectors in the aperture macros to absolute vectors in the main code. There are no GerbV processing limits in the main code.

 

Gerber files shows a small portion of the flawed files on the left, and the corrected file on the right.

Conclusion

Projects seldom work correctly the first time and no engineer would last very long in the profession without an overwhelming compulsion to persevere in the face of adversity.

When things don’t work, start questioning your assumptions and break the problems down to their simpler substeps—or reach out to experts for help. At the end of the day, we will prevail.

For the rare times that we cannot make a design work, I recommend that you go outside, smash the board with a brick, and then pin the pieces to the office wall as a warning to the next project that dare defy you.

I hope that you enjoy reading about my struggles as you contemplate your own. Happy engineering.