Problem when using MSP430G2553 without Launchpad
Started by 7 years ago●7 replies●latest reply 7 years ago●284 viewsHi,
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.
Thanks,
PLT
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.
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.
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.
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.
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.
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.