Multiple ProffieBoard v2.2 crashing in KR RVN Hilt

Proffieboards
1

Hello,

I’ve been having several issues with multiple proffie boards in this particular hilt (KR RVN).

Video of Issue occurring: http://jkjunkie.com/misc/proffie_crash.MOV

Symptoms:

When physically clashing with the blade in, the sound will either cut out completely, the idle hum will cut out, or it crashes/freezes with the long beep as shown in the video. When the sound cuts out completely, if I turn it off and immediately back on, the sound is still muted. If I try changing fonts, there is still no sound. If I turn the saber off for a short period and turn it back on, the sound returns. If it crashes, the only way to reset it is by toggling the kill switch.

Specs:

Proffieboard v2.2
TCS WOW 4w 28 mm speaker
Sony Li-Ion 18650 3.7V PCB protected 15A battery
ProfileOS v5.9
24 AWG wire used from TCSS
SanDisk Ultra 16GB C10 A1 HC microSD card at factory defaults from KR Sabers

What I’ve tried:

Two different KR proffieboards with the same results.
Checked wiring of Proffie.
Checked wiring of hilt side PCB
Checked wiring of battery holder
Resoldered battery holder
Firmware version 4.6, 5.7, and 5.9
Arduino version 1.8.13 and 1.8.3
Default Proffie configuration
Different hilt side neopixel PCB
2 Different blades that also works in other hilts
A few different SD cards, some from other working hilts.
Compiling and uploading ProffieOS v4.6, v5.7, and v5.9 on both macOS and Windows (Using Zadig on Windows)

Other things to note:

The config is the default generated from the Proffieboard website setup for 144 pixels as well as for two buttons.
The blade in the video works in other hilts, just not this one
The battery used in the hilt in this video works fine in other hilts that do not have the shown issue.
When clashing without a blade in, everything seems to be working fine.
I put a piece of electrical tape over the blade side PCB just to see if having the blade LEDs off would make a difference. The issue(s) still occurred.
Using the serial monitor works without issues as well. I can’t replicate the issue on the serial monitor because it seems to only occur when I’m clashing with a blade in. If I trigger clashes over and over with the blade out by just hitting the hilt, the issue does not seem to occur.

Here is the test config I’ve been troubleshooting with:

#ifdef CONFIG_TOP
#include “proffieboard_v2_config.h”
#define NUM_BLADES 1
#define NUM_BUTTONS 2
#define VOLUME 1000
const unsigned int maxLedsPerStrip = 144;
#define CLASH_THRESHOLD_G 1.0
#define ENABLE_AUDIO
#define ENABLE_MOTION
#define ENABLE_WS2811
#define ENABLE_SD
#endif

#ifdef CONFIG_PRESETS
Preset presets[] = {
{ “TeensySF”, “tracks/venus.wav”,
StyleNormalPtr<CYAN, WHITE, 300, 800>(), “cyan”},
{ “SmthJedi”, “tracks/mars.wav”,
StylePtr<InOutSparkTip<EASYBLADE(BLUE, WHITE), 300, 800> >(), “blue”},
{ “SmthGrey”, “tracks/mercury.wav”,
StyleFirePtr<RED, YELLOW>(), “fire”},
{ “SmthFuzz”, “tracks/uranus.wav”,
StyleNormalPtr<RED, WHITE, 300, 800>(), “red”},
{ “RgueCmdr”, “tracks/venus.wav”,
StyleFirePtr<BLUE, CYAN>(), “blue fire”},
{ “TthCrstl”, “tracks/mars.wav”,
StylePtr<InOutHelper<EASYBLADE(OnSpark, WHITE), 300, 800> >(), “green”},
{ “TeensySF”, “tracks/mercury.wav”,
StyleNormalPtr<WHITE, RED, 300, 800, RED>(), “white”},
{ “SmthJedi”, “tracks/uranus.wav”,
StyleNormalPtr<AudioFlicker<YELLOW, WHITE>, BLUE, 300, 800>(), “yellow”},
{ “SmthGrey”, “tracks/venus.wav”,
StylePtr<InOutSparkTip<EASYBLADE(MAGENTA, WHITE), 300, 800> >(), “magenta”},
{ “SmthFuzz”, “tracks/mars.wav”,
StyleNormalPtr<Gradient<RED, BLUE>, Gradient<CYAN, YELLOW>, 300, 800>(), “gradient”},
{ “RgueCmdr”, “tracks/mercury.wav”,
StyleRainbowPtr<300, 800>(), “rainbow”},
{ “TthCrstl”, “tracks/uranus.wav”,
StyleStrobePtr<WHITE, Rainbow, 15, 300, 800>(), “strobe”},
{ “TeensySF”, “tracks/venus.wav”,
&style_pov, “POV”},
{ “SmthJedi”, “tracks/mars.wav”,
&style_charging, “Battery\nLevel”}
};
BladeConfig blades[] = {
{ 0, WS281XBladePtr<144, bladePin, Color8::GRB, PowerPINS<bladePowerPin2, bladePowerPin3> >(), CONFIGARRAY(presets) },
};
#endif

#ifdef CONFIG_BUTTONS
Button PowerButton(BUTTON_POWER, powerButtonPin, “pow”);
Button AuxButton(BUTTON_AUX, auxPin, “aux”);
#endif

2

Any chance the board is contacting metal anywhere in the hilt? Maybe around the Blade’s LED pads, so when the blade is in there’s a short?
Or perhaps the connector in the hilt it slightly off-center or has some “play” and the pins are able to shift enough to cause a short when hit? I’d check if the connector (or blade) is able to shift at all in the hilt, it’s possible the blade or connector are shifting just enough to misalign.

1 Like
3

At one point I even tried to put a piece of electrical tape over the blade side neopixel PCB and try it with the blade in. The crash still occurred. I did the same with the Proffie board and put electrical tape over it. The board is glued in the chassis, and with the electrical tape over it, the crash still occurred.

I’m stumped.

4

Well this is a weird one.
The 1000-hz ‘squee-of-death’ indicates that ProffieOS is crashing. That is usually the result of a software bug of some sort. However, if it was a software bug, then why would it only happen on this hilt? Another hilt with the same config should also experience the crash.

It is possible for crashes to be caused by shorts and other issues, but when that happens, the result is usually unpredictable, meaning that sometimes you get a squee-of-death, other times the saber just reboots or does something completely different.

Another possibility is that this hilt is just very “vibraty”, meaning that loud noises, clashes and other vibrations might cause more clashes than other hilts. If this is the case, then the problem would exist on other hilts too, but require a lot more work to trigger than on this hilt.

What version of the arduino-proffieboard plugin do you use?

5

Oh, and does this problem occur on all presets, or only some presets?
Are you using the original “proffieboard sdcard” fonts? Or some other fonts?

6

On both my Windows and macOS machine I’m using version 1.0.0
It seems to happen on any preset that I select. I originally had a custom SD card with custom fonts and such on it, but then when the ‘squee-of-death’ (I like that term lol) started happening, I placed a default original proffieboard SD card that I got from KR sabers into the ProffieBoard and used a default configuration generated from your website. Sadly, the ‘squee-of’death’ still occured.

7

I recommend upgrading to the 2.2.0 version of the plugin and see if that helps.

8

I’ll update that now.
I gutted the saber last night and am going to rebuild it from the ground up while taking detailed photos of the build process. If it resolves the problem, then sweet! If not, I’ll post links to the pics here so that maybe somebody here can see something that I am not.

Stand by.

Thanks for the help btw. =)

9

Have you got any photos of the board installed in the chassis? I’m wondering if something in there is shorting…

10

If it were me, since it seems that the presence of a blade seems to be a determining factor, I would start the analysis at the hilt PCB. Also, your clash threshold is really low.

11

Okay, here we go:

I’ve completely rewired the saber, but unfortunately, the “squee-of-death” is still occurring. :frowning:

What I’ve tried now:
Updating the Arduino Proffie Plugin to 2.2.0 and re-compiling and uploading the v5.9 firmware. You can find the new config below.
There is a small plastic spacer that goes in between the pommel and the speaker at the bottom of the chassis. I figured if the saber is vibrating too much to try replacing this spacer with a piece of foam instead.
Placing electrical tape over the ProffieBoard to prevent shorts against the side of the hilt interior.
Placing electrical tape over the blade side PCB again to see if it may be related to powering the LED strip.
Unfortunately, all of the above attempts still resulted in the squee.

Here are the images of the build process with some detailed pictures of the saber

http://jkjunkie.com/misc/proffie_issue

Config

#ifdef CONFIG_TOP
#include “proffieboard_v2_config.h”
#define NUM_BLADES 1
#define NUM_BUTTONS 2
#define VOLUME 1200
const unsigned int maxLedsPerStrip = 144;
#define CLASH_THRESHOLD_G 4.5
#define ENABLE_AUDIO
#define ENABLE_MOTION
#define ENABLE_WS2811
#define ENABLE_SD
#endif

#ifdef CONFIG_PRESETS
Preset presets[] = {
{ “Revan”, “tracks/Revan.wav”,
StylePtr<Layers<RotateColorsX<Variation,Red>,LockupTrL<Layers<AlphaL<AudioFlickerL,Bump<Scale<BladeAngle<>,Scale<BladeAngle<0,16000>,Int<4000>,Int<26000>>,Int<6000>>,Scale<SwingSpeed<100>,Int<14000>,Int<18000>>>>,AlphaL<White,Bump<Scale<BladeAngle<>,Scale<BladeAngle<0,16000>,Int<4000>,Int<26000>>,Int<6000>>,Int<10000>>>>,TrConcat<TrInstant,White,TrFade<400>>,TrConcat<TrInstant,White,TrFade<400>>,SaberBase::LOCKUP_NORMAL>,ResponsiveLightningBlockL<Strobe<White,AudioFlicker<White,Blue>,50,1>,TrConcat<TrInstant,AlphaL<White,Bump<Int<12000>,Int<18000>>>,TrFade<200>>,TrConcat<TrInstant,HumpFlickerL<AlphaL<White,Int<16000>>,30>,TrSmoothFade<600>>>,ResponsiveStabL<Orange,TrWipeIn<600>,TrWipe<600>>,ResponsiveBlastL<White,Int<400>,Scale<SwingSpeed<200>,Int<100>,Int<400>>,Int<400>>,ResponsiveClashL<White,TrInstant,TrFade<400>,Scale<BladeAngle<0,16000>,Int<4000>,Int<26000>>,Int<6000>,Int<20000>>,LockupTrL<AlphaL<BrownNoiseFlickerL<White,Int<300>>,SmoothStep<Int<30000>,Int<5000>>>,TrWipeIn<400>,TrFade<300>,SaberBase::LOCKUP_DRAG>,LockupTrL<AlphaL<Mix<TwistAngle<>,Rgb<255,200,0>,DarkOrange>,SmoothStep<Int<28000>,Int<5000>>>,TrWipeIn<600>,TrFade<300>,SaberBase::LOCKUP_MELT>,InOutTrL<TrWipe<300>,TrWipeIn<500>,Black>>>()
}
};
BladeConfig blades[] = {
{ 0, WS281XBladePtr<144, bladePin, Color8::GRB, PowerPINS<bladePowerPin2, bladePowerPin3> >(), CONFIGARRAY(presets) },
};
#endif

#ifdef CONFIG_BUTTONS
Button PowerButton(BUTTON_POWER, powerButtonPin, “pow”);
Button AuxButton(BUTTON_AUX, auxPin, “aux”);
#endif

12

My only comment, and unrelated to your issue, is you should try to shorten the amount of exposed wire on the kill switch and shrink wrap the connections. While a short here would really just bypass your switch, it’s just good practice.

13

Before tearing it apart, I had electrical tape on the middle post.

14

I must admit that I don’t understand what is going here.
I have a few things we could try, but they are mostly grasping at straws:

  1. maybe it’s a something that only happens at certain levels of optimization? What level of optimization do you use?
  2. Does the problem change or go away if you change maxLedsPerStrip to 200 ?

However, there is a sure-fire way to figure out what is going here, but it’s not particularly simple. Basically we would need to connect an ST-link V2 to the board after the crash. Then we can see where in the code it’s actually stuck. An ST-link V2 debugger only costs a fewof dollars, and wiring up the SWDIO/SWDCLK pins so that they can be connected to the debugger isn’t all that difficult. If you’re interested in doing this, I will can try to help figure out some step-by-step instructions for you.

15

I mean, that could be a factor here…

16

I would add shrink wrap to connections such as the kill switch. It would help avoid potential shorts and strengthen the joints.

17

The only joint that isn’t covered by heat shrink tubing is the kill switch and speaker. I tried the speaker, but it wouldn’t fit in the chassis. I covered the joints with electrical tape and tried it with the same crashing as a result. Even before the rebuild, I had electrical tape on the kill switch middle pin. That made no difference. I have torn apart and rebuilt this saber 3x now, and I’ve even gone as far as to replace the Proffie and hilt side PCB with no behavioral changes. I’ve even tried clashing the saber with the blade in without sound as well as without a connection to the blade (by covering the blade side PCB w/ electrical tape) and it still crashes. Only difference without sound is I don’t get that squee of death, but it still freezes. I’ve built 3 other sabers that do not have this issue, it’s just this one.

I’ll invest in the ST-Link, could be useful in the future for other things too.

18

Just a thought, what does the back side of the hilt PCB look like? Any exposed wire that could come into contact with each other perhaps? I didn’t see the wired backside in your pics.

19

Ok, let’s start some step-by-step instructions then…

Step #1, what you will need:

  1. An st-link v2 (these seem to be $7 on amazon, and you can find them even cheaper on ebay)
  2. A 3-pole connector of some sort

The simplest thing you can do for a connector is simply 3 header pins. It’s possible to solder the header pins directly to the board, but if you do that it will probably not be possible to close the hilt anymore, so it might be better to solder some wires to GND, SWDIO and SWDCLK and then connect those to some header pins which could then be glued somewhere accessible.

Another alternative would be to buy some pre-wired connectors, sort of like these:

Whatever connector you use, remember that the ST-link V2 has header pins that it will need to connect up to somehow, and the wires can’t be too long because that will cause problems for the SWD protocol. Up to 30cm or should be fine.

I’m going to do a little testing to make sure I know exactly how to get all this working on a Mac before I write up step 2… :slight_smile:

20

This is true, I took pictures of it, but forgot to post them, my apologies.
Here is a pic:

image
image3024×4032 1.03 MB