There is a risk that it will overload and burn the 5 volt voltage regulator on the Arduino board. The common way to avoid that is using separate power supplies for the Arduino and the motor Shield. The more elegant way is to internally generate the 5 volt from the higher V in voltage, using a step down converter like the one integrated in the red hat shield and explained in video number 99. More recently, I designed a separate TCC aux shield for that purpose. As shown in video number 113., that design was straightforward and it seemed to work flawlessly until I got news from user. That smoke was coming out of his Arduino welcome to the iot channel. I am Hans Tanner, a special welcome to all new subscribers and welcome back to everyone else. Im happy you made it here well to say I was unhappy about the news is, of course, an understatement. How can that be? After all, I tested it, and everything appeared to be fine, and next thing I hear is that it blew up an Arduino. So there were two questions I had to find answers for what caused the Arduino to fail, and why did I not figure out the problem while testing? The second question was rather easy to answer. When I had another look at my test setup and quite embarrassingly, it was a real beginners error. Essentially, I was not aware that I had a second dc dc converter in the setup which worked in parallel with the ox shield and, as it turned out, made good for all the problems Im now going to analyze.

This second converter was of the same type as the one used on the red hat. So the good news here was that the problem was only with the new dc dc converter, but not with the red hat. So I removed the additional converter from the test system and started the investigation if you are familiar with problem solving methodology, you are also familiar with the concept of a root cause analysis and thats. What I was about to do, if not here, is a short description and summary, as the concept is fundamental for all kind of problem analysis. The starting point usually is not the problem, but a symptom of the problem. Like a user telling me that smoke is coming out of his Arduino, that is the result of the problem, but not the problem itself and typically there is a time delay between the problem to happen and the symptom to appear the so called Escape calls path. So the first step is to identify both problem actually causes the symptoms. In the case of the ox Shield, the symptom description was relatively clear. Everything worked fine when testing with 9 volts, then the voltage was increased to 16 volts and within a split second. After switching on smoke was coming out of the Arduino on board voltage regulator. This leads to the conclusion that the problem is an overload situation of the voltage regulator and that quite intense, otherwise it would first heat up, but for sure survive a little while at least a few seconds.

But here the overload was so significant that it blew up. Almost instantaneously now this is the problem, but to solve it, we need to work back. The occur cause path to understand the systemic root cause. As a general rule, we only understand the problem. If we can intentionally make it come and go only, then we are in a position to actually solve it. Now we start in mind. Let me show you the steps I took to find the root cause so far. I knew that the problem occurs at voltages above 9 volts and during the startup phase, so while the DCTC converter is building up to 5 volt Supply voltage during that phase, obviously the onboard regulator was delivering energy to the point it got overloaded. I actually did my own tests with gradually increasing voltages expecting to see a gradual change of the behavior may be warming up just slightly first. Unfortunately, this was not the case. It went from correct function to fatal overload without warning, so I successfully verified the symptom killing. The first Arduino in the process, but unfortunately not learning anything more about the actual problem. So I decided to have a closer look at the start of behavior and compared it to the startup sequence of the red hat DCTC converter, which I knew was working properly at all voltage levels. This oscilloscope shot shows the two curves when power is applied. Quite a difference: the red hat converter needs about 2 milliseconds to start, while the aux Shield takes about 13 milliseconds to reach 5 volts.

The onboard lto of the Arduino, on the other hand, needs only about one millisecond to provide the 5 volt output once V. In is applied. This slow startup is not about a feature of the converter chip, it is called Soft start and can be controlled using a capacitor attached to the SS pin. The standard value is 0.1 micro farads and leads to a delay of 15 milliseconds. Basically, what I saw on the oscilloscope, so my next step was to remove the capacitor and have another look. The oscilloscope picture looked good and gave some hope. I started the ox Shield several times and increased the voltage until I successfully started it up with 16 and 18 volts DC coded speed is really was the root cause of the problem. I certainly hoped, but pretty soon learned, that it was not with the soft start capacity removed instead of just connecting it to an already powered wire. I connected the shields to a unpowered, lead power supply and switched it on. So instead of getting a clean established voltage, the aux Shield would have to start up on a more realistic Supply voltage following a starter brand as well. It worked fine with slower voltages, so I increased the voltage to more realistic 12 volts and you probably guessed it smoke came out again. So Arduino number two was gone and I had to prove that the soft start was not the problem. But what else? What could happen during the startup phase that causes the onboard audio to overheat? To find out? I had another look at the data sheet and in particular compared the DC DC chip.

I was using with the bond used on the red hat. What I found is a significant difference of the power driver. The mp1584 used on the red hat only has a single transistor to switch the output on and off the mp1484. I am using for the aux shield, on the other hand, features a half Bridge, which means the output cannot only source but also sync current. So if an output voltage higher than the target voltage is detected, the chip can try to lower it by drawing some current. This is the best explanation I have of what happened during the slow startup, the Arduino onboard lto provided 5 volts, and the dc dc converter detected a voltage higher than what should be and started to draw some power. This loaded, the ldo, which led to an overload situation. The solution to the problem was simple, though all I needed to do was adding a diode to prevent current from going into the mp1484, and that should fix the problem. So I reinstalled the soft start capacitor and added a diode into the curtain Supply path. In fact, I built two versions to test the difference. The first version had the diodes before the second version had it as the connection point of the feedback loop. At this point, it is important to understand how the voltage regulation of a DC output works. The converter chip tries to keep the voltage of the feedback input stable by changing the duty cycle of the output to the coil.

In the case of the mp1484, this voltage is kept at 0.925 volts if it sinks below that value. The duty cycle is increased to bring it back up and if it is higher than 0.925 volts, the duty cycle is reduced to make it come down. As a result, the output voltage can be set by the voltage divider formed by the resistors or 8 9 and 10 in the schematics. With that in mind, installing the diode between the coil and the feedback connection had two advantages. First, it resulted in a much simpler modification of the board and second, it would make the feedback resistor values independent of the forward voltage of the diode. So it would be possible to change the type of the diode without changing the resistor values of the feedback loop. The risk, on the other hand, was an additional element in the feedback loop, with potentially unwanted effects on the quality of the resulting output voltage. I tried both versions and both versions apparently worked. It looked that the protection diode really prevented the overload of the Arduino on board regulator and for the first time I saw some light at the end of the tunnel. That is until I killed another Arduino. Here is what happened for video number 114. I put together an Arduino stack to demonstrate the configuration of the powershield to simplify wiring. I powered V in from the power shield and used the DCC aux Shields to provide the five volt power supply for the Arduino.

Everything went well until I did the overload test with the automotive bulb towards the end of the video. I had the dccx overload protection set to about 6 amps, but the whole stack was powered by the lead power supply with a maximum output of current of 5 amps. As soon as the bulb was connected, the current Rose to more than 5 amps and the power supply reduced the voltage to limit the currents to 5 amps. After removing the bulb, the power supply re established the target voltage, and that is where it happened. More smoke. Coming out and Arduino numbers Recon, unfortunately, this new problem was not systematic, but in some situations I noticed that the DCC aux Shield did not re establish the 5.25 volt output voltage as it is set to, and it looked like this was typically happening. If the voltage from the power supply was re established slower than usual, so I did. A series of test starts with a very slow voltage increase rate and indeed the DCC aux Shield sometimes did not re, establish the correct output voltage, but remained below 5 volts, which then would make the Arduino onboard regulator engage and become overloaded. Interesting to note that this overload did not result in the immediate stance of the Arduino regulator, but resulted in a typical heat of cycle before to regulate the diet, which was another confirmation that the protection diode worked. Also interesting. To note that only about half of the boards I tested showed this Behavior, the author has started off normally all the time.

This is an indicator that some of the components around the converter chip were in a Range that led to a malfunction depending on component tolerances. So I went back to study the data sheet and indeed found an error in my design. The reference design suggested that 10 microfarad output capacitor next to the coil to stabilize the output voltage thats what I used, but what I overlooked was the times two node. Next to it, so I used only 10 microfarad compared to the 20. The reference design really suggested. I therefore added a second capacitor and the problem was eliminated. So as the client, some testing and three arduinos later, I had clearly identified two root causes. First, the missing protection diodes that is needed to prevent the tcdc converter to draw a high amount of current during the start of phase and second, a wrong capacitor value which prevented the start of cycle from happening in case the input voltage was raised very slowly. Luckily, both problems are relatively easy to fix by some small board modifications and the oscilloscope finally showed a perfect startup sequence. We in is applied. The ldo provides 5 volts immediately and, as the dissolved start phase of 15 milliseconds, we can see the voltage increase from 5 to 5.25 volts when the DC DC converter kicks in. That is the case when V in reaches about 7.5 volts, so a safe range for the Arduino onboard regulator and no risk for overloading it.

Now the title of the video talks about killing five arduinos, but so far I only reported destroying three of them. What about the other two? Well, I indeed killed two more in the process, but for other reasons, basically use stupidity, kill number four really was an accident that happened during my powershields tests. I simply dropped a track power wire and the alligator clip fell on some chips of the Arduino, resulting in some nice Sparks and ending the arduinos life. Of course, what we can learn from that is that we should always switch off the power before making changes to the wiring of the setup telling that to myself, but it is so convenient to make changes just on the fly. So maybe an occasional kill is just the cost of convenience. Well, thats up to you to decide, kill number five was a user error as well, but more interesting as it shows the effectiveness of using a DCTC converter to power. The Arduino stack here is what happened to simplify testing. I powered the stack from a power Shield sitting directly on the Arduino. The DCC aux shield, on the other hand, was on top of the stack, so it is easy to access. Furthermore, I only installed parts of the Arduino headers, mainly the pins needed for the power transferred between the boards, while taking measurements. I loaded the Arduino on one side causing it to bounce this caused to be in pin to disconnect while the 5 volt pin still remained connected.

So the Arduino was now getting the 14 volts from V in, but not the 5 volts from the dc dc converter, causing the onboard ldo to kick in. On top of the stack, I also had an iot stick, which Drew about 200 milliamps from 5 volts. So the total load of the onboard ldo was about 250 milliamps, with a voltage drop of about 9 volts, so the ldo had to burn a little more than two Watts. It took a few seconds and then the magic spoke appeared again here. The learning point is that proper dieting makes the difference, but it also demonstrates the effectiveness of using a bug converter, which allows powering the entire Arduino DCC stack with one single power supply for the track power and the Arduino board to simplify the wiring and thats it. For this video, I hope this information was useful, or at least interesting for you, and it gave you some ideas for your own development and troubleshooting activities. If so, please click the like button below to. Let me know every like helps to promote this video and the iot channel in general, as it motivates YouTube to suggest this video to other model railroaders, and if you want to share your own experiences with electronics development. Please do so by leaving a comment in the comment section below.