Have I popped my board-bricking cherry?

Well this one is completely new to me, so I’lll share in case anyone has any ideas…

Just powered up a newly installed 2.2 board without the SD card, and as well as the “SD card not found” message starting, I suddenly got a loud buzzing noise from (I assume) the speaker. Hit the kill switch immediately, went round with a test meter again in search of a short, couldn’t find any, and now the board seems dead when I power it up.

Background
Master metal chassis, lots of accents. The loose board was programmed in advance and all seemed fine. I ran all the wires in up to the point where the tails are just waiting for the Proffie to be wired up. At this point I tested every accent LED and the speaker using my little test rig (see photos at DropBox link). All worked fine, apart from that colour discrepancy I mentioned the other day.

Soldered the Proffie up today, tested with a meter for shorts or anything else untoward. All seemed OK, so I fitted a battery and applied power. Buuuzzzzzzzz! Switched off. Checked everything with a meter yet again. No obvious fault. Powered again, but this time it was completely dead. :anguished:

Current Status
So now when I power the board, I get no boot sound and no lights. I get the correct battery voltage at Batt+ and Batt- pads (4.1 volts from fully charged battery). I also get 3.3 volts at the 3.3 volt pad, the SD pad and the two switch pads - Just no sound, no lights and no response from buttons

Tried connecting USB and Arduino can see the board, but Serial Monitor it seems can’t. No boot or lights from that either.

I guess my question is, is there a component on the board than can cause this and/or fail like this, and if so can it be replaced? Or is the board toast?

I hesitate to say it’s a bad board because it’s never a bad board (it came from KR Sabers so is a reputable supplier) so my gut tells me it must be something I’ve done, but I’ve checked and rechecked everything else and I can’t find anything else wrong. And the fact that I tested every accent circuit with another board (i.e. my test rig) before I wired the main board also seems to suggest that the board is at fault. Either way, I need to nail it down before I fit another one, hence I’m throwing it out to the learned folk here.

Any thoughts welcome.
Thanks as always.

This “buzz”, is it a 1khz tone? (The so called “squee of death”?)

If it is, then it may be caused by a crash somewhere, and I would recommend switching out the SD card and re-program with a super-basic setup and see if that works. If it does, then you didn’t fry anything and you should be able to go back to your setup again, and if the squee-of-death occurs again, then you would know that it’s something wrong with the program.

If on the other hand this “buzz” is not the squee of death, but something else, then I don’t know what is going on here.

Yes, it was that kind of thing. Maybe a bit lower than 1 k, but it was an even tone. I only heard it for an instant. With any new build, I’m always ready to kill power as quick as I can on the first ever boot, precisely for this sort of thing.

Thanks for the advice Prof. I’ll give that a go and report back. Brian also suggested it might be software, but I had just assumed it must be hardware.

Hmmm. Interesting…

With the SD card removed, you get the squeal of death, the port shows in Arduino, but you can’t upload a confg.

With the SD card inserted, there’s no squeal but also no port in Arduino. Been trying the boot/reset thing but no joy so far. Will keep going as I know that sometimes takes quite a few attempts…

Are you checking for “STM32 BOOTLOADER” after boot+reset?
(full instructions here: ProffieOS Documentation: How to recover from a bad programming)

OK, managed to get a simple config on there. All seemed to work normally. Went back to the 7 bladed original config and the squeal was back.

So it looks like there’s something about my config it doesn’t like. Time to get the toothcomb out! LOL! Pastebin link below if anyone is interested in trying to find the gremlin.

Anyway at least it doesn’t appear to be hardware related which is positive.

Thanks for getting me this far Prof. Appreciated as always.
:slight_smile:

Sorry, forgot the link - here it is:

Nothing jumps out as bad in the config file.
Hopefully you can enable/disable one thing at a time until you figure out what’s causing the problem. Just remember that it could be something on the SD card that’s doing it. It can be super-confusing to look for bugs when the bug is actually somewhere you’re not considering…

That’s definitely the lesson from this evening! I was convinced it was hardware - it would never have occurred to me that it could be config. But yes, I just need to be patient and methodical now.

I did find one little thing in the config - I’d left config styles and the endif lines in with nothing in between them. But taking them out hasn’t made much difference.

but a new SD card is formatting as I write this. Then it’s back to simplified blade array and add one blade at a time and go from there.

Thanks again Prof. :pray: For general interest I’ll post the final outcome when I find it. :slight_smile:

OK, figured it out - it was indeed hardware, but software highlighted it…

Started by removing all but one blade preset. No change.
Then used the latest OS from GitHub - no change.
So started peeling out blades from the blade array one at a time. Removing the side strips (i.e. not using Pad 4/Data 1 in the config) fixed it.

So at least I know where to look now.

Pad 4 had two wires spliced together for LED strips each side of the chassis. Started by unsoldering them, then re-uploading the original (squealing) config. All worked.

So I split the wires and ran one of them to the unused pad 6. Reconfigured accordingly. All worked.

So I soldered the one remaining wire back into pad 4, set the config the same as you would for a main blade, i.e. two FETs driving one blade.

Hey presto - sorted!

So it can only have been a stray spur from the pair of twisted wires underneath shorting on something. But it was impossible to see past the wires on the underside. And of course no amount of short testing of pads with a meter would have discovered it.

Thanks as always for the help guys. Very glad not to have toasted my first squealing board.
:smiley:

1 Like

OK, interesting update to the update, just for interest:

As mentioned above, this problem appeared to be sorted. So as it is my normal custom, I was going through all the fonts checking everything was working as it should, when I got to my diagnostic preset. This is a very simple preset which cycles through all the blade colours and highlights any misbehaving pixels.

Ths is the code, replicated for every pixel accent:

StylePtr<InOutHelper<Cyan,300,800,ColorSequence<1250,DodgerBlue,Green,Rgb<28,255,28>,Red,Magenta,Rgb<255,80,154>,Yellow,Orange,Azure,DeepSkyBlue,Blue,Cyan>>>(),

When the above happened…

All of the quotes are boot files. So the board was constantly rebooting itself every few seconds for no reason.

In the video it always happens on magenta, which, being two channels, suggests a power thing, but when I tried it the next day, it was doing it more randomly on all colours.

I thought maybe one of the FETS was damaged from the first incident, so I rewired and recoded both strips to FET 6. But when I hit the kill switch, the whole core was completely dead. So I snipped the negative wire to the right hand strips, and suddenly everything else worked again.

So it appears to be one of the side strips causing the problem, which I guess is good as it’s relatively easily sorted.

But I’m just curious to know the tech behind it, as I didn’t think LED strips could prompt total reboots like this.

Why did the accent strip work fine when animating a single colour on every other preset, but cause problems when cycling through lots of colours in sequence?

Do the FETs have some kind of automatic safety cutout?

Is there an overall Proffieboard safety cutout mechanism, like in a home consumer unit (fusebox)?

If yes to either of the above, what’s the criteria for prompting a reboot?

And why is it every time I think I’ve seen every fault it’s possible to have within a lightsaber, I suddenly find myself facing a new one?! LOL! :smile:

I have also decided off the back of this that I’m going to attempt to produce a Proffieboard trouble-shooting flow chart, though I think it may take a while! LOL! Will post here as and when I’ve done it. :smiley:

No, but the battery does.
So draw enough power, and the battery protection circuit cuts the power, which can cause a reboot. Not sure how you would do that by changing the color of a nepixel though…

Yeh, that occurred to me too, but I thought you had to put the battery on a charger to reset it. But maybe not.

But as you say, quite how 13 pixels upsets it enough to trip when there isn’t a short and it works fine on other colours, I really don’t know. But now posting this, I think when I get home I’ll try another battery just to eliminate it from the enquiry.

Depends on the battery, some auto-reset, some don’t.

1 Like

Update to the update which was previously updated, along with some answers… sort of…

Yesterday I concluded that the right hand strip had a fault, but it turns out if I disconnect either the left or the right hand strip and just run one strip or the other, the problem goes away. But it always returns with both strips connected (which is 26 pixels in total). Swapping the battery out makes no difference.

The reason the problem doesn’t manifest on any other preset is because on all other presets, I only run the LEDs at around one quarter power (full blue is Rgb<0,0,62>), except my diagnostic one, which runs at full colours.

So when I recode the diagnostic preset to quarter colours like the rest of the presets, the problem goes away.

So to conclude, something about those very thin KR strips upsets the Proffieboard or battery when they are run at full power. But since quarter power is plenty bright enough for accent LEDs, it’s easily coded around.

As for the technical reasons for why this happens, I guess only the Force itself knows the answer to that.

:slight_smile:

I don’t suppose you’re powering these strips from 3.3 volts or something?

As a matter of fact I am.

It did occur to me to move the strips’ positive to Battery positive, but the reason I didn’t was because from a wire management perspective, the only way I could do it would be to make that connection hard to the battery, before the kill switch. Since the main Proffie neg is also hard to the battery, I was concerned that the strips would try to draw current via the Batt+ and data line, even with the kill switch off. Indeed when troubleshooting this, I would disconnect one of the strip negs, but the first couple of pixels on that strip would still glimmer slightly, meaning they must have been getting some kind of neg via the data line. (They are fed from Data 1, so no additional resistor added).

But I take your point that most strips prefer 5 volts. Could the lower voltage cause the symptoms we’ve been seeing?

If you’re connected to the 3.3v, you’re connected to the Proffieboard’s regulator, not directly to the battery. When you do that you’re basically siphoning power away from the CPU (among other onboard components) and the regulator on the proffieboard, which is not meant to power much, can’t keep up.

So, you’re straining the regulator, which is less than ideal, and when that can’t keep up the proffieboard just dies because it doesn’t have enough power to operate. The next bit is conjecture: It’s possible it drops specifically when changing colors because of current spike from the CPU itself as it processes what it needs to in order to switch the colors, but it could also just be current variances as the new set of LEDs is turned on… I can’t imagine it would take much.

So, TLDR, move those strips to be connected to the battery, powering them from 3.3v is scary (And, depending on the regulator the PB uses, which I’m not familiar with, doing this could wear it out and cause it to fail prematurely)

That all does make sense I must say. My preference for 3.3 volts for accents is because kill keys/switches kill the 3.3 volt pad completely. Plus it means the LEDs don’t have to cope with voltage variations, though admittedly that’s not really issue with pixels, only conventional LEDs.

For the most part it’s not an issue because it only drives one or two LEDs - clearly asking it to power two strips of 13 pixels (26 in total) was just too much for it.

Well, if the accents are wired normally (BATT+ and LED pads), then they’ll still get killed just fine with a kill key, same as the main blade. If the kill key/switch properly breaks either the + or - lead of the battery going out to everything, no current can flow. Perhaps I’m misunderstanding what you mean by killing the 3.3 pad completely though.

Yeah, NeoPixels are, relatively, super high current components.