LED Cube Software Won't Restart on Power Down / Power Up

Using Arduino LEDs and Multiplexing
1

Hi

Not sure whether to post this here or in the LED and multiplexing area, so I'm doing both. I hope that's not a violation of the rules.

I have a working LED cube with working software - I've been modifying the software this evening and when I stopped everything was working fine. Experience has shown that when I power it all down, I have a hell of a time getting it going again and now I can't. So I'm looking for thoughts on what to try.

Until this evening, I had a USB from my computer to the Arduino (a MEGA2560), which sends SPI signals to a circuit board that interfaces with the cube. I have a separate 5V power supply on the circuit board to power the LEDs. With the Arduino powered by the USB, on startup I usually get junk on the cube, but after some time and switching the circuit board power on / off a few times, it seems to sort itself out. Still, I would prefer that that doesn't happen.

Recently, in response to a different post of mine, I was advised by one of the experts here that I should really power my Arduino from my board and not via a separate power supply. So tonight I made a special USB cable that is the same as a normal USB cable, except I cut the USB 5V supply wire and instead connected it to a 5V supply from my circuit board. When I turned it on, I get junk again on the LED cube and it doesn't seem to be going away.

I found this on the troubleshooting forum.

Why doesn't my sketch start when I'm powering the board with an external power supply?
Because the RX pin is unconnected, the bootloader on the board may be seeing garbage data coming in, meaning that it never times out and starts your sketch. Try tying the RX pin to ground with a 10K resistor (or connecting it to the TX pin).

I understand the part about connecting the RX pin to ground. Does the other part mean I should try connecting the RX pin directly to the TX pin without a resistor?

Any other suggestions to get this going again?

Regards

2

Hi

Not sure whether to post this here or in the Troubleshooting area, so I'm doing both. I hope this isn't a violation of the rules.

I have a working LED cube with working software - I've been modifying the software this evening and when I stopped everything was working fine. Experience has shown that when I power it all down, I have a hell of a time getting it going again and now I can't. So I'm looking for thoughts on what to try.

Until this evening, I had a USB from my computer to the Arduino (a MEGA2560), which sends SPI signals to a circuit board that interfaces with the cube. I have a separate 5V power supply on the circuit board to power the LEDs. With the Arduino powered by the USB, on startup I usually get junk on the cube, but after some time and switching the circuit board power on / off a few times, it seems to sort itself out. Still, I would prefer that that doesn't happen.

Recently, in response to a different post of mine, I was advised by one of the experts here that I should really power my Arduino from my board and not via a separate power supply. So tonight I made a special USB cable that is the same as a normal USB cable, except I cut the USB 5V supply wire and instead connected it to a 5V supply from my circuit board. When I turned it on, I get junk again on the LED cube and it doesn't seem to be going away.

I found this on the troubleshooting forum.

Why doesn't my sketch start when I'm powering the board with an external power supply?
Because the RX pin is unconnected, the bootloader on the board may be seeing garbage data coming in, meaning that it never times out and starts your sketch. Try tying the RX pin to ground with a 10K resistor (or connecting it to the TX pin).

I understand the part about connecting the RX pin to ground. Does the other part mean I should try connecting the RX pin directly to the TX pin without a resistor?

Any other suggestions to get this going again?

Regards

3

First and foremost, what part of "not for problems with your project" at the top of this forum section was unclear? This is a problem with your project, not the arduino itself. Don't start a new thread (that violates forum rules) - I would suggest using the "report to moderator" link for your post to request a mod move it to a more appropriate section.

  1. Using the USB interface if the external power like that is not connected could damage the serial interface chip (I wouldn't be particularly concerned if it was a CH340G, but I would on an official board or clone that used a 16u2) - be sure not do let this happen.
  2. The RX pin issue is irrelevant on boards that plug into USB, it is only an issue on a pro mini, or custom boards where you connect to external serial adapter instead of on-board one. TX pin of adapter (hence RX pin of micro) is pulled high by adapter.

That said:

If you press the reset button on the Arduino after powering it on, does that fix the problem? If so, try putting a delay at the start of the sketch before initializing the LED controller.

Do the driver chips for the LED cube have a reset pin?

If so, I would connect those to an I/O pin, and have the sketch pulse that, wait a bit of time, and then start sending data to it.

Can you confirm that the sketch is actually running? You should see the pin flicker when sending SPI data, as that's the SCK pin...

Do you have an external pullup on the CS pin? If not, install one - 10k is sufficient. While bootloader is running, the data lines would be floating, CS as well, and if that line happened to be low when the SCK line was pulsed to blink the LED for the bootloader, that would confuse the SPI controlled chips by sending a few random bits... If CS was hard-wired low instead of controlled by the microcontroller, that SCK blink would definitely confuse it.

4

This is indeed a violation of the rules as not every person that answers your questions reads both forums so if two different people answer your different version of the same query with what will most likely be the same information, you have received more than your fair share of attention and wasted the time of one or the other (or both?).

Further, you are even cross posting on this form as you have made a new post about the same project and problem, requiring people to go and find the other (previous) topic if they wish to know adequate details regarding what on earth it is you are doing as a prerequisite for a sensible answer!

5

Thank you for your response.

First and foremost, what part of "not for problems with your project" at the top of this forum section was unclear? This is a problem with your project, not the Arduino itself.

I posted here because my project is working perfectly...it just won't start when I power off and restart the Arduino. That seemed like more of an Arduino problem to me, especially seeing when the troubleshooting guide suggests I start connecting Arduino pins I don't understand together.

I don't want to violate any rules so I will indeed contact the moderator.

If you press the reset button on the Arduino after powering it on, does that fix the problem? If so, try putting a delay at the start of the sketch before initializing the LED controller.

If only it were as easy as pushing the restart button.

Do the driver chips for the LED cube have a reset pin?

No.

Can you confirm that the sketch is actually running? You should see the pin flicker when sending SPI data, as that's the SCK pin..

Can't see any flickering except when I upload a sketch. Couldn't see any flickering when it was working before though.

Do you have an external pullup on the CS pin? If not, install one - 10k is sufficient.

By CS pin, do you mean the SPI SS pin? I just have a direct connection from the SPI pins (51, 52 and 53) to my board.

6

OP here.

It is... choose one, and click report to mod in the other one as ask for its removal.

This is indeed a violation of the rules as not every person that answers your questions reads both forums so if two different people answer your different version of the same query with what will most likely be the same information, you have received more than your fair share of attention and wasted the time of one or the other (or both?).

Sorry chaps. Newbie here and I suspected it might be a violation which is why I noted that right up front in my post - so I could get feedback on it for future reference. I have contacted the moderator in the other forum to fix it. This is my going forward thread.

Further, you are even cross posting on this form as you have made a new post about the same project and problem, requiring people to go and find the other (previous) topic if they wish to know adequate details regarding what on earth it is you are doing as a prerequisite for a sensible answer!

It's the same project yes, but it's not even close to the same problem - that's why I started a different thread about it. I thought it's like taking your car to the shop for an oil change. If the car breaks down later that day because the cooling pump stops working, is that the same problem even though it's the same car?

And, I thought, there are enough details in this new thread to understand what the issue is. The thing works perfectly - it just doesn't restart on power up.

Now that I've been suitably admonished, I would sure appreciate some helpful suggestions. I am happy to post more info here if needed.

Thanks.

7

Duplicate topics merged

8

Have you tried reducing the SPI speed? I seem to remember from your previous topic that was set to 8MHz, the fastest available on Mega and below the limit for 74hc595 chip, but maybe the circuit board or the length of wires between the board and the mega are causing problems at that speed. Try 4MHz or 2MHz.

9

Have you tried reducing the SPI speed? I seem to remember from your previous topic that was set to 8MHz,.....

When it doesn't start it's not always the same. Sometime no LEDs come on and sometimes they almost all come on with some flashing at the back, and then it may or may not start flickering.

I keep thinking there's been a hardware failure of some sort and it's done for, but then I somehow seem to get it working properly again (no idea how) and my fear of hardware failure recedes. I had it going earlier today and then it crapped out again. So I was almost convinced (again) that it's a hardware issue.

I tried your suggestion. Your memory is correct - it was set at 8 MHz. I set it to 4 MHz and it started up, ran for a few seconds (so maybe the hardware is good), then crapped out by turning almost all the LEDs on and sitting there, flickering away.

I can't remember if I set it to 2 MHz and tried again, but I thought I should do this in a systematic way and report back. So I set it to 16 MHz because that's where I originally put it (based on something I read about the Mega's speed) and I was then going to record what happens, reduce to 8 MHz and record, 4 MHz and then 2 MHz.

And when I recompiled my software with the setting at 16 MHz, it started working. Right now I'm afraid to even look at it in case it craps out again. If / when it does, I'll complete my SPI speed tests.

Thanks for your suggestion or I wouldn't have tried this - at least it's going again. Fingers crossed that it will keep doing so. I'm not going to turn it off tonight.

FOLLOW-UP (ABOUT 10 MINUTES LATER)

Looks like I spoke too soon. Uploaded a revised sketch, it ran properly for two animations, then crapped out and started displayed all LEDs and then flickering again. So frustrating.

ANOTHER FOLLOW-UP

I've now tried various SPI speed settings. It either turns on most LEDs or none of them, and then it may or may not start flickering.

I'm thinking it must be the timing signals aren't arriving properly. Maybe I should rewrite it using shiftOut and some different pins. Any thoughts?

AND ANOTHER FOLLOW-UP

I switched it to shiftOut and I still get the same kind of flickering. Not good.

Regards

Neale

10

As I said, 8MHz is the fastest mega can go. No matter how high you set the speed, it will be limited to 8MHz. You wouldn't want to go beyond 10MHz anyway because the that's the limit for 74hc595.

You could try 1MHz also.

I'm reposting your schematic for you, since you forgot to include it in this topic.

20200306_072754.jpg
20200306_072754.jpg1305×734 226 KB

I wanted to check you had 0.1uF bypass caps on each chip, which you do. It might be worth trying some larger caps also, e.g. 10uF electrolytic next to each chip, or 100uF somewhere on the board. Maybe the sudden changes in current as the layers switch is causing data signal corruption and these caps could help satisfy those demand spikes.

11

Paul

Thank you so much for the time you have given me. I think I may have found the problem.

Because of the intermittent behaviour and the fact it was just the same when I used shiftOut, I figured it had to be a problem with the timing signals and that problem is on the circuit board I made. So I disconnected the board and gave it another good going over, and I found something.

I was on the point of giving up when I noticed a very tiny bulge in one of the ground wires. You can see it on the photo of my circuit board if you still have access to it - and if you want to. Assuming you do, and with the photo oriented such that the red input jack is in the upper left corner....look at the row of shift registers closest to the bottom of the photo. The leftmost shift register has two wires to ground (the ones with black insulation). If you look closely at the rightmost of those two wires (zooming in on the photo) near the end towards the centre of the two rows of shift registers, you can see the tiny bulge. It's right next to the centremost part of the capacitor to the right of the wire, or two holes down from hole where the bare wire portion of the ground wire disappears through the board to its soldering connection underneath.

This bulge is caused by a jumper wire underneath the board that daisy chains the two registers rows together. I had to use a jumper here because of the row change. When I soldered that jumper in place underneath the board, part of the bare wire end protruded through the hole I was soldering it to and touched the insulation of the black ground wire on the topside of the board. It melted that insulation and the bulge is caused by that data wire.

I'm hopeful that this explains the issue - it does if an intermittent connection with the ground wire is assumed. That would explain why sometimes it works and sometimes it doesn't, and also why it stops working when I turn it off - because turning it off means I have to touch the circuit board which moves it a little, and that could affect the quality of this connection.

After I fixed it and put it back together I was a bit anxious about turning it. When I started it up it didn't work - the same response as before. So I turned it off and on again, and then it started to behave properly.

I've learned a lot from this project (my very first electronics thing ever - I'm a nuclear guy actually), and if I ever do something like this again I'll be sure to pay a whole lot more attention to jumper wires under the board. I gather from reading what others have written that there are better ways to make these things - it took me days to make the board what with having to cut all the right size wires and paying careful attention to soldering the connections, jumpers and bus lines, all very close together in such a small space. I'll have to learn about those better ways some day.

So it seems like I've wasted your time and I'm sorry for that, but I have learned other things from your responses. Fingers crossed it keeps working now and thanks again.

Neale

12

Well done finding the fault.

I normally build a circuit first on breadboard and test thoroughly before I think about perfboard/stripboard/triboard and soldering. But this would be quite a large circuit to build on breadboard, you would need to clip many of them together to make a large enough are to build on.

13