Problem when using MSP430G2553 without Launchpad

Started by PLT 6 years ago7 replieslatest reply 6 years ago279 views

I am trying to build a capacitive touchless sensor with an MSP430G2553 to control a small DC motor. When the chip is on the launchpad, everything goes well. The sensor works, it sends a signal to the Mosfet and it activates the motor (and deactivates it after 1 second as it supposed to). However, I don't want to use the chip on the Launchpad (I want to operate it on a breadboard first then a PCB later when things work). I found a way to connect the chip on the breadboard. It seems to work well except the the motor won't turn off once it starts spinning for the first time(it spins non-stop until I remove the power). When I use a LED instead of the motor, it works fine. It detects proximity, activates the transistor and the LED for 1 second then it turns off. 

On the breadboard, the chip is connected to the source (batteries) and the reset is linked to the + with a resistor. 

So, I don't know why this problem appears only when the chip is not on the Launchpad. Do you have any idea why this happens? I tried many different way to fix the problem. What bothers me is that it works perfectly fine when the chip is on the Launchpad. It also works on the breadboard if I use a LED instead of a motor. 



[ - ]
Reply by MarkDSylvaApril 1, 2018
I don't have time to figure out what the schematic would look like, but I noticed that you don't have any decoupling capacitors in the circuit.   The problem is most likely due to electrical noise  ( back EMF) from the motor.   I would try adding a 10uF capacitor in parallel with the battery,   and a 0.1 uF across the motor leads.
[ - ]
Reply by Tim WescottApril 1, 2018

If it's not the lack of decoupling caps, it's the 3.3V line into the circuit sagging when the motor turns on and screwing up program execution.  The motor's going to pull a lot more current than the LED, so it'll have a much greater effect.

It's general good practice for this sort of prototyping to put an LED on the board, and blink it from software.  Blink it from the same software that's reading the capacitive sensor and controlling the motor -- the idea is that if the software fails then the light stops blinking (or blinks oddly) and you know something's wrong.  That's why so many products have blinking lights on them.

[ - ]
Reply by trmittal24April 1, 2018
I am assuming that while using the Launchpad you are powering it through your PC.

So, I think what is happening is when you are using some external supply for the chip on Breadboard, it's unable to provide enough current.
Try using a ammeter to measure the current when motor is connected.
If it is less, you might want to use a motor driver like L293d.

Let me know what happens.

[ - ]
Reply by rustywoodburyApril 1, 2018

Are you using a P-channel or N-channel MOSFET?

I can work out the schematic from your picture but I need the MOSFET part number so I can verify what the way you are doing it correct.

Good luck.

[ - ]
Reply by BVRameshApril 1, 2018

As per your input it works well for LED, but fails with motor what I find is it is power supply getting drooped in standalone mode.

Isolate the power supply.

The Motor and mosfet source pin should have a separate 3.3V supply, and micro-controller another separate 3.3V supply. Both supplies should have common ground. Try the breadboard circuit in this way. It should work.

Also as mentioned by MarkDSylva, it needs decoupling caps. Put a 1uF and 0.1uF decoupling cap between VDD & VSS of controller. Also add a 1nF cap from Reset pin to ground.

If this works, and if your design need a single supply only, then isolate the two supplies using Schottkey (BAT54A) diodes.

Best of luck.

[ - ]
Reply by mr_banditApril 1, 2018

Better to use a scope.

(NOTE: Rigol has a scope https://www.rigolna.com/products/digital-oscillosc... for $350. 50 MHz. I am not going to mention you can find a tool on the interwebs that will change a byte in EEPROM to make the scope 100mHz..)

If you can, always put a scope on the VCC line. When something weird happens, set your trigger for VCC dropping below the CPU voltage. You can also (most times) see the dip.

In your case, also put a scope probe on the motor VCC.

The problem with meters is they integrate the input && can lie to you. Had this happen at a client. the (young) EE had a meter - everything looked good, but was failing. I hooked up a scope to VCC - the problem was obvious.

But all of the advice about decoupling caps && a separate supply (with H-bridge) for the motor is sound advice. AND - be careful with your grounds. Either have a common ground, or completely isolate the circuits, using an optoisolator link to trigger the FET.

[ - ]
Reply by CustomSargeApril 1, 2018

Big YUP on decoupling. I'm a fan of separate voltage regulators to Really decouple branches. This is more $, but you can start there and see which branches are more & less sensitive.