EDIT: Solved this one myself… Was going down a hardware rabbit hole for a software problem, as per my usual arrangement. Copied fonts and BMPs to a new SD Card and didn’t correctly rename the files.
I’m ready to lose my mind here… Working on a build that has been a cascade of one problem after another all weekend. The latest iteration of trouble today is with my OLED screen. I have animation files loaded up to the SD card, but I only get the default OS6.5 splash screen/battery monitor… UNTIL I desolder a + wire that runs three accent pixels and a crystal chamber motor. As SOON as I take that wire off and put the battery back, my OLED animations show right up.
Location of the wire (5v, board+, battery terminal) makes no difference. I verified that my OLED is wired correctly and that there are no bridges. What am I missing???
Is your test scenario accurate? Disconnecting a positive wire from some accent pixels made incorrectly named .bmp files show?
I know you posted a resolution, but I’m super curious as to what was going on actually with that whole first part. Does not seem possible.
Hey bud, youre absolutely right, i did leave out a few things. The last few days trying to get this thing back up and running are a bit of a blur tbh, but I’ll try to fill in the gaps.
The 5v line in question was feeding a 3px blade, consisting of an arc reactor and a 2px crystal. The crystal in question is removable and has not only the npx power pins but a blade detect pin as well.
Now here is where things get a little goofy. For my font that relates to the No Blade state, I had the BMPs in the folder correctly, named correctly according to the config. I did not, however, have the naming of the fonts for the Blade Present named correctly, meaning ofc that the board couldn’t access either the sounds or the BMPs. The speaker on the build in question is magnetically attached to the bottom and uses contacts to operate, so with the build torn down I had no way for the board to tell me what was wrong via the speaker.
It seems as though having the 5v line attached completed the circuit all the way up to the crystal (even though I didn’t have the px installed in it yet) and caused the saber to (attempt to) boot into the first blade present font. Removing the 5v line broke the circuit and caused it to boot into the No Blade preset where everything was labeled correctly. I began testing with every wire in the sequence and the smoking gun was when removing the blade detect line fixed it as well.
I feel like there’s something I’m not remembering correctly, as I have no idea why the problem would manifest as it did with the crystal holder in place but empty, as there was nothing to complete the circuit. Im sorry if this doesn’t completly answer the question or solve the mystery, but I was plowing through this thing into all hours of the night all weekend and my entire day off yesterday and had a bad case of tunnel vision from it, as well as running on a completely fried brain.
It was definitely a humbling moment when I realized what I had done, as I had completely disassembled a fully functional (and giant PITA) build for no reason. The build is 100% back together and functional now (except ofc for one bug which was the reason I had torn it down in the first place of course… might post on that topic later) and I’m now taking a short sabbatical from working on sabers to clear my head. This one issue was FAR from the only problem of my own making on this project.
I hate that.
You can use #define CONFIG_STARTUP_DELAY x, where x is milliseconds to delay the boot sequence, giving you time to attach the speaker and hear errors/ boot sounds.
Oh…unless your USB is only accessible without the speaker pod, in which case some creative alternate microdean connector wired in parallel would help .