Help, I keep frying Arduinos

Hi, I am working on a class project for my Mechatronics class and am having circuit problems.

I am trying to control a robot using two BLDC motors, BLDC motor drivers, and an Arduino Uno.
BLDC Motor Driver Specs and Diagram:

https://myosuploads3.banggood.com/products/20190508/20190508220426SKU600181WS55-1801.pdf

Here is the connection diagram:

The arduino is powered using an external battery that came with it in a kit in which I have used many times without issue. The motor drivers are being powered by a power supply of around 23-24 V (I did not include in the picture, but before the splice there are Voltage step downs that will reduce 36V/48V down to 24V, but it does not matter as our testing power supply only reaches 24V).

The motor drivers turn on and work fine, and the arduino is powered and able to upload code. The problem occurs when both the motor drivers are turned on and the arduino is on and code is running (we only had both on once code was uploaded already). In the first two instances, the motors were moving but eventually stopped. Then after a few moments the lights on the arduino went out. The third instance there was no motor motion and moments later the lights went out too. For all three arduinos when powered separately with external battery, the LEDs work fine but the RESET button does not work. We then tried uploading code to the arduinos and the computer detects their COMs but displays “Uploading” forever. Eventually it ends and displays a long error concerning “avrdude.”

There must be something wrong with my circuits/connections, or code that is killing them. Here is my code:

#include <Arduino.h>
#include <avr/wdt.h>
#include "DeviceDriverSet_xxx0.h"
 
// #define Max_Distance 200 // in centimeters
#define SV1 7  // Motor1 Direction
#define SV2 6  // Motor2 Direction
#define ALM1 5 // Motor1 Speed
#define ALM2 4 // Motor2 Speed
#define EN1 3 // Driver1 On/Off  
#define EN2 2 // Driver2 On/Off 
 // #define FR1 __  // Motor1 Forward/Reverse            // Will use if ALM does not work
 // #define FR2 __  // Motor2 Forward/Reverse

DeviceDriverSet_ULTRASONIC myUltrasonic;

int (n); // Min distance from obstacle by sensor in cm
int (tempda_f);
int (tempda_l);
int (tempda_r);

void setup() {
  Serial.begin(9600);
  myUltrasonic.DeviceDriverSet_ULTRASONIC_Init();
  pinMode (EN1, OUTPUT);      // Will use if declaring EN pins is not enough 
  pinMode (EN2, OUTPUT);
  pinMode(SV1, OUTPUT);
  pinMode(SV2, OUTPUT);
  pinMode(ALM1, OUTPUT);
  pinMode(ALM2, OUTPUT);
  // pinmode(FR1, OUTPUT)    
  // pinmode(FR2, OUTPUT)
  digitalWrite(EN1, LOW);
  digitalWrite(EN2, LOW);
}

void Stop() {
  digitalWrite(SV1, HIGH); // May or may not need here
  digitalWrite(SV2, HIGH); // May or may not need here 
  analogWrite(ALM1, LOW); 
  analogWrite(ALM2, LOW); 
}

void Forward() {
  digitalWrite(SV1, HIGH);
  digitalWrite(SV2, HIGH);
  analogWrite(ALM1, 100);  // Can change speed if needed
  analogWrite(ALM2, 100); 
}

void Backward() {
  digitalWrite(SV1, LOW);
  digitalWrite(SV2, LOW);
  analogWrite(ALM1, 100); 
  analogWrite(ALM2, 100); 
}

void Right() {                 // May need to change label if reversed
  digitalWrite(SV1, HIGH);
  digitalWrite(SV2, LOW);
  analogWrite(ALM1, 100); 
  analogWrite(ALM2, 100); 
}

void Left() {                  // May need to change label if reversed
  digitalWrite(SV1, LOW);
  digitalWrite(SV2, HIGH);
  analogWrite(ALM1, 100); 
  analogWrite(ALM2, 100); 
}

// void loop() {
//   n = 10; // Minimum distance from sensor to obstacle in cm
//   if (tempda_f <= n) {           // If front sensor is less than or equal to n, stop
//     Stop();
//     delay(1000);                      // Can choose to get rid of delay if result is smoother motion
//     if (tempda_l > tempda_r) {        // If left sensor distance is greater than right sensor, go left
//       Left();
//     }
//     else {                            // If not, go right
//       Right();
//     }
//   }
//     else {                       // If not, go forward 
//     Forward();
//   }
// }


// // Preset Test motion without sensors:
//   void loop() {
//     delay(5000);
//     Forward();
//     delay(3000);
//     Stop();
//     delay(2000);
//     Right();
//     delay(1000);
//     Stop();
//     delay(2000);
//     Left();
//     delay(2000);
//     Stop();
//     delay(2000);
//     Backward();
//     delay(3000);
//     Stop();
//     delay(2000);    
//   }

void loop() {
  Forward();
}

There are two other code files but they are only for the the eventual usage of ultrasonic sensors, but before we tried those we just wanted to see if we could get it to run simple direction commands. The only command we tested was the final void loop() Forward. Some of the code is for ultrasonic sensors but that is not of concern right now. (Note: EN must be LOW to initialize driver).

What I think it may be is too many Amps, or something going on with the GND from drivers to arduino, or the code. I made sure they were all outputs though so nothing should be coming in. Also, although the motor drivers work off of 10V and the arduino can only output 5V, other groups have no problem controlling the drivers from direct wiring from arduino to drivers.

I don’t have many arduinos left and I don’t know how to figure out the problem without testing with more. Help would be greatly appreciated.

I will take a SWAG and say you got a nasty pulse from one or both motors when it switched off. Connect all of your grounds together at the power supply and run only ONE to the Arduino. Put something like 500 Ohm resistors in each logic line going to the motor drivers and see if you can get it to work. Add all the power connections to your drawing, nothing shows how the Arduino is getting power.

Do the dead Arduino do anything?

That is/was not shown in the wiring diagram.

Wait - it is there, on the USB (like a 'powerbank' or similar)

So we can see all the interconnections, show us good images of the actual wiring.

1 Like

Here is an updated photo of the wiring diagram:

The batteries that power the arduino are at the bottom left corner.

I forgot to mention that we tried two different batteries: One ELEGOO 7.4V battery that came in this arduino robot kit: https://www.elegoo.com/products/elegoo-smart-robot-car-kit-v-4-0

and another battery that was bought by my professor specifically for our project. I wouldn't be able to find the specs until I go into the lab tomorrow. We of course did not power simultaneously, but tried the second battery after the first thinking it may have been the problem but it was not.

I will able to try what you suggest when I am in the lab. The dead arduinos light up (as shown below) on LEDs 'L' and 'ON', but not on TX or RX even when pressing RESET button. The computer recognizes the arduino through USB connection but does not upload code. Also, the microcontroller immediately starts becoming hot when powered.

I added a new picture replying to another user.

I can send when I have access tomorrow.

Going by your wiring diagram, the ground path between the two motor drivers runs right through the Arduino, between the ground pin by pin 13, and the ground pin by 5V. That would be my first suspect as to why you keep frying the board.

The first thing that comes to mind as a possible fix is to hook the grounds on the motor drivers to each other, and then run a single ground wire back to the Arduino.

2 Likes

Ok I will try that. Would making this change to one ground back to arduino decrease voltage or amps? Would that mean the two GNDs to the arduino are doubling the voltage to the arduino?

It's just a hunch at this point. @gilshultz may be onto something when he says that you're getting a nasty pulse when a motor shuts off. The way things are wired now, if it's getting onto the ground line, it has to go through the Arduino to get to the other motor driver.

1 Like

You should tie all the grounds together in one spot. It will look like a "star" with individual grounds going from single connection to each board.
In series with your motor drive I/O add a 1k on each. Goal is to reduce the effect of transient voltages or wiring errors. The 1k should not adversely the low level signals.

I do wonder if the GND on the motor drivers are connected internally to the negative of the batteries.

It could just be that the GND is a protective mains ground and that the battery is in effect floating.

Hi mike; I'm assuming from the data sheet that the GND is the reference for the control signals.
However the "5V" seems to be internal to the controllers, Perhaps the OP should check the value as it doesnt seem to be mentioned in the data sheet?

Yes, the GND is for the motor driver control signals. The drivers came with attached potentiometer and EN switch that were grounded at the motor driver ground (which I removed). I was actually wondering why nothing was happening when we tested before when we didn't even notice we forgot to ground the drivers (This is where a floating battery may have existed but it did not damage the arduino). The 5V on the arduino is an output from arduino if one wanted to power something from it. My 'S' and '5' look similar in my handwriting so it may look like '5V' on the drivers but it is actually 'SV' like in the data sheet.

What voltage are you applying to the USB socket?
Your program pin defines do not match datasheet, SV pin requires 0 to 10V for speed control, not a HIGH / LOW 5V signal.

My page here may help you understand why the layout of grounds is important.

1 Like
  1. As others have stated, "star ground" in motor and other high power applications is very important.
  2. The BDLC spec you linked to says the 10v control power is necessary. They don't give a range of voltage, so I would expect to provide 10V. Not anything else, at least until it's all working.
  3. Your SV input is expected to be a 0-10V signal, not digital logic.
  4. Your initial sketch showed "Arduino Battery" applied to the USB. Must not be > 5VDC, or you will damage your Arduino. Vin can handle up to 12V, but your 7.4V is ideal.

For testing, I would start by supplying 10V and a potentiometer, to ensure the controller is good, then decide how to proceed.
EDIT
Looks to me like the 10 V control power(Provide power for control,the Current is very small) sources the power for the Hall sensor, "V+ can't be used for other purposes." So without that, your signal outputs are faced with unpowered logic in the motor control. This can damage your Arduino.

I've seen worse technical info, but it's a close call. Without the drawings, it would be completely unintelligible.

Alarm on that board is an output, you have the alarm pin configured as an output but it should be an input. That's the first thing wrong, but I would expect that worst case it would just blow those two arduino pins (or the motor board, by having it source into a grounded output) and the rest of the board should keep working.

Also double check your control wiring between the board and arduino (not shown on schematic). Since you say it works, then I'd assume the pins are just named incorrectly. This can lead to confusion.

You show two power supplies, both labeled Arduino Battery (one on USB, one on VIN). I make it a practice to use ONLY ONE POWER SUPPLY on the Arduino.

In your schematics you named a connection: F/R, while the datasheet says V+. Which one is right? Or is this datasheet from another version?

It is possible that the EN-input runs from the +24V. That would explain the frying.

Measure the voltages at all connection points while not connected to your Arduino, and try to manipulate the side switches while measuring to see what they do.