Drawing Current for the Servo Motor Directly from the Arduino board

I was controlling a Tower Pro (MG995) Servo motor through Arduino UNO for a specific application. I connected the Servo Motor as: Orange wire (Data): Pin 9 Brown Wire (Ground): GND Pin Red Wire (Power): 3rd Pin of 7806 IC 1st Pin of 7806 IC: Vin Pin 2nd Pin of 7806 IC: GND Pin

And I powered up the board with the 12VDC 2A Wall Adapter.

When I programmed the board (Example of Servo Motor in Arduino IDE), it started running the motor. When I tried to reprogram with certain changes: It displayed,"avrdude: stk500_getsync(): not in sync: resp=0x00"

Since then, I am not able to program the board anymore, although it is still running the old program properly.

I went through various topics on the forum, but nothing helped me out. I have also Burnt the Bootloader in the controller, but still the error persists.

I took out the microcontroller (ATMega328) from the UNPROGRAMMABLE UNO and put it another UNO Board, it programs perfectly. So the controller seems to be OK, but the board doesn't. But, then I programmed that controller to blink the LED on Pin 13 and put it back in UNPROGRAMMABLE UNO Board, it starts blinking the LED. So, what I could deduce was that the pins responsible for programming the controller are not working properly, but the board is fine. Is it?

Is it all because of the higher current got drawn from the UNO Board while running the servo motor?

Can anyone please tell what has actually happened? Has my board been destroyed? What is the solution for it?

This is my first question, apologies if I have put some irrelevant information in it.

Has this question any connection with your other Thread?

If so, can you explain the purpose of splitting the question?

…R

then I programmed that controller to blink the LED on Pin 13 and put it back in UNPROGRAMMABLE UNO Board, it starts blinking the LED.

When you did this, was the Uno powered through USB or from external 12V power supply?

EDIT added …

Doh, just made the connection with the other thread, Robin :slight_smile:

Assuming it is the same situation sounds like USB power was still working in above situation but external was not.

@rptduino please confirm.

@Robin: No, the problem I have in this thread is what I had been facing since the last week. And the problem in the other thread began today itself on the other Arduino UNO Board I have. Getting on with this thread: I did the exact connections on one more Arduino UNO Board and it showed the very same error: "Not in sync..." just after the first program it burnt successfully. And it is as dead as the other one as it too is not programming anything.

I don't know if boards are totally gone or there is something that can be done to bring them back to life. And if the boards are gone, why are they running the older programs? Also, if the controller is gone, why is it still getting programmed easily on some other Arduino UNO board?

//So much confusion.

@Ray: This interchanging of microcontrollers among the different boards was done while power was fed through USB. I'll try the same on non-USB power as well and will post about it on the forum asap.

Thanks.

rptduino: I took out the microcontroller (ATMega328) from the UNPROGRAMMABLE UNO and put it another UNO Board, it programs perfectly. So the controller seems to be OK, but the board doesn't. But, then I programmed that controller to blink the LED on Pin 13 and put it back in UNPROGRAMMABLE UNO Board, it starts blinking the LED. So, what I could deduce was that the pins responsible for programming the controller are not working properly, but the board is fine. Is it?

It would help a great deal if you give names to each of the Unos that you have - perhaps A and B. Let's assume the unprogrammable board is A and the programmable board is B.

Now, have you any more Unos or can we assume that the board that is causing problems in the other Thread is B?

If so we don't know if you have two good boards, two faulty boards or one good one (but which one?) and one faulty one.

You seem to say that you could not re-program the 'A' 328chip on the A board, but you had no trouble doing so on the B board.

Have you tried programming the B chip on the A board?

I don't understand this

I did the exact connections on one more Arduino UNO Board and it showed the very same error: "Not in sync..." just after the first program it burnt successfully. And it is as dead as the other one as it too is not programming anything.

It seems to imply that you have more than 2 Unos.

What do you mean by the exact same connections? It would be aa good idea to draw a diagram and post a photo of it.

...R

I have 3 UNOs. A, B and C (Suppose)

A and B form this thread while C forms the other one.

Beginning again, Board A displayed the error for "Not in sync.." I took out the Board B, did the same connections as on A, and B too went down. Now I took out Board C and exchanged its controller (Controller C) with Controller B.

Now, Controller B on Board C is functional and programmable. It uploads sketch to Controller B without any hassle. But, Controller C on Board B is functional but non programmable. It shows the error "Not is sync..." while uploading a new sketch.

//Sorry for frustrating you out. I wish I hadn't posted the second thread simultaneously.

Exact same connections mean:

I was controlling a Tower Pro (MG995) Servo motor through Arduino UNO for a specific application. I connected the Servo Motor as: Orange wire (Data): Pin 9 Brown Wire (Ground): GND Pin Red Wire (Power): 3rd Pin of 7806 IC 1st Pin of 7806 IC: Vin Pin 2nd Pin of 7806 IC: GND Pin

And I powered up the board with the 12VDC 2A Wall Adapter.

1st Pin of 7806 IC: Vin Pin

You probably need to supply the vin directly from the 12v. If vin goes thru the uno onboard regulator chip, the voltage to the board may be significantly below 5v due to voltage drop across the regulator chip.

rptduino: I have 3 UNOs. A, B and C (Suppose)

A and B form this thread while C forms the other one.

Beginning again, Board A displayed the error for "Not in sync.." I took out the Board B, did the same connections as on A, and B too went down. Now I took out Board C and exchanged its controller (Controller C) with Controller B.

Now, Controller B on Board C is functional and programmable. It uploads sketch to Controller B without any hassle. But, Controller C on Board B is functional but non programmable. It shows the error "Not is sync..." while uploading a new sketch.

EDIT - NOTE - followin @Hackscribble's comment I realized I had made a mistake in my notation which I have now corrected. The error also meant that my deductions were wrong and I have corrected them also - the problem seems to be with the Boards, not the MCUs. It seemed too complicated to try to keep the old and new versions.

I'm going to be very pedantic and try to restate this with large A for the board and small a for the Atmega328 MCU chip.

First problem was with Aa - it became unable to load software, but otherwise worked OK. Then the same problem arose for Bb after connecting B in the same way that A had been connected.

Then the MCUs were swapped so that you have Cb which works completely normally and Bc which works but can't be programmed - in other words it behaves the same as Aa and Bb. It would be interesting to try Ac - my guess is it should also have problems, and Ca - my guess is it won't have a problem.

This suggests that something has happened to the Boards A and B and no damage has been caused to MCU b (and maybe not to MCU a).

Now the $64k question is what sort of thing could have happened to the now-faulty Boards?

Before speculating any further I think you need to draw a clear diagram of how everything was connected and post a picture of it. A diagram is much easier to follow than a written description.

...R

Now, Controller B on Board C is functional and programmable. It uploads sketch to Controller B without any hassle. But, Controller C on Board B is functional but non programmable.

I took this to mean that Cb is functional and programmable, while Bc is functional but not programmable, which would suggest that b is OK but B is damaged. Damage affecting the USB interface but not the main part of the board.

But my head hurts and I'm very confused, so could well be wrong :)

The OP needs to supply an accurate schematic of how the power circuitry was arranged. In particular there's no mention of decoupling capacitors on the 7806, and there should be clarity of which pins were connected to what, the 7806 has a GND pin, a Vin pin and a Vout pin.

It sounds like one or more boards has had its USB-serial chip fried, and this is possibly due to inductive spikes from the servo damaging something. Don't share power supplies between large inductive loads and delicate electronics is the advice always given, and this sort of issue is the reason.

Then the MCUs were swapped so that you have Bc which works completely normally and Cb which works but can't be programmed

@Robin: Nope.. Cb works completely normally. While Bc works but does not program. I am attaching the picture, just give me sometime.

As rightly pointed out by Hackscribble..

I took this to mean that Cb is functional and programmable, while Bc is functional but not programmable, which would suggest that b is OK but B is damaged. Damage affecting the USB interface but not the main part of the board.

This is the exact scenario.

And I'm really very sorry for this:

But my head hurts and I'm very confused

@MarkT: I did not use decoupling capacitors. But Cc (Board C with controller c) worked fine that way.

It sounds like one or more boards has had its USB-serial chip fried, and this is possibly due to inductive spikes from the servo damaging something. Don't share power supplies between large inductive loads and delicate electronics is the advice always given, and this sort of issue is the reason.

Yes, this seems the reason. So, is there anything that can be done for the A and B boards to bring them back to life??

rptduino: And I'm really very sorry for this:

But my head hurts and I'm very confused

Don't be sorry :) I often get confused!

Hackscribble: I took this to mean that Cb is functional and programmable,

I think you are right and I have changed my earlier post - and not just the Cb/Bc stuff. I would appreciate it if you would review the revised version.

This error reassures me that a very pedantic approach is essential to get everything clear !

I still don't see any basis for moving forward until we see a detailed schematic of the actual wiring.

Edit ... I missed @MarkT's post. The fried USB-serial chip sounds like the best explanation so far. It may be possible to verify that by uploading a sketch using the working Board C which writes stuff to the Serial Monitor and then moving the MCU to one of the faulty boards.

...R