DC motor humming troubleshoot
This type of problem (where you have two supposedly identical "channels" and one is working but the other is not working) is easy to solve when you have the equipment in your hands. Find the difference(s). There must be difference(s) between the two channels, otherwise their behaviour really would be identical!

It is worth noting that difference(s) might be hidden due to a faulty assumption. For example, in your case, you are assuming that the motors have identical specifications and so are identical. In fact, one motor might be different than the other e.g. mislabelled, faulty manufacturing, damaged by previous use, etc. So always check and list your assumptions.

Two approaches to find differences which are quite suitable for beginners include:


Move devices/modules, one at a time, from the "failing" channel to the "working" channel and test whether:

(a) the problem stays with the original "failing" channel (then the problem is not the component you moved to the other channel), or 

(b) the problem moves with the component to the other channel (then the problem is related to the component which you moved, although it might not be the component itself, but connectors, wiring etc. that were related to the move).

One risk to this approach, is that by disturbing the electrical connections to move components between channels, you might change the problem, or it might disappear, without you knowing why (e.g. you might fix a high resistance connection when you move a wire).

Or:
Make relevant measurements between the two channels, to find where the difference is. In your case, this would include measurements with DMM and 'scope to see if the supposedly identical PWM signals being sent to drive the two motors really are identical, If not, then you can use additional measurements to narrow down whether the cause is hardware or software (PWM generation).

This approach has less risk of disturbing the cause of the problem than option 1 above (it is bad news if the problem "goes away" without you knowing why, because it could return in the future!) but it requires test equipment and ability to interpret the measurements.


Troubleshooting is not taught enough in many engineering courses. Learn fault-finding techniques at every opportunity and add them to your personal library for use later. Some good formal techniques are taught by Kepner-Tregoe and others. I have (over-)simplified their approach in my example above. Those simplified techniques would often not be appropriate in more complex cases.

An (unofficial) example of the Kepner-Tregoe "IS/IS NOT" approach is available here: http://www.itsmsolutions.com/newsletters/DITYvol6iss19.htm Although that is a software (IT) example, you can see how the possible causes are tested to see whether they match the problem description and other data.