Well that’s interesting.
Can you show me the blades[] array then?
Have you tried swapping the SD cards between the two? Just to rule out the SD card itself.
This is the whole bottom of the config including the last blade preset:
// ****************
{ "Battery;Shared/Boot;Shared/ForceStd;Shared/Functions", "tracks/rey.wav",
// Main Blade:
&style_charging,
// Internal Accent White:
StylePtr<InOutHelper<Blinking<Rgb<125,125,125>,Black,400,500>,300,800,Blinking<Rgb<125,125,125>,Black,2800,500>>>(), "battery"},
// *************************************************************************
};
template<int milliohms = 47000>
struct InternalLED {
static constexpr float MaxAmps = 0.02;
static constexpr float MaxVolts = 3.1;
static constexpr float P2Amps = 0.01;
static constexpr float P2Volts = 3.05;
static constexpr float R = milliohms / 1000.0;
// LED color
static const int Red = 255;
static const int Green = 255;
static const int Blue = 255;
};
// *************************************************************************
// AHSOKA BLADES
// Long - 124 Pixels
// Short - 87 Pixels
BladeConfig blades[] = {
{ 0,
WS281XBladePtr<124, bladePin, Color8::GRB, PowerPINS<bladePowerPin1, bladePowerPin2, bladePowerPin3>>(),
SimpleBladePtr<InternalLED<47000>,NoLED,NoLED,NoLED,bladePowerPin5,-1,-1,-1>(),
CONFIGARRAY(presets) },
};
#endif
#ifdef CONFIG_BUTTONS
Button PowerButton(BUTTON_POWER, powerButtonPin, "pow");
// Button AuxButton(BUTTON_AUX, auxPin, "aux");
#endif
Fernando,
I confess I didn’t try swapping between hilts, but I did replace the SD card in the offending hilt with another one taken out of a brand new unopened Proffieboard. It made no difference sadly.
Might be worth a quick swap, if the short blade has not experienced see what happens when try it in the long and vice-versa. At a minimum it would rule out the card if it still occurs on the long and not the short one. Remove a variable from the mystery.
Pastebin of the entire config, just in case:
Ok, so next step would be to play with the blade lengths.
Like, what happens if you switch the two configurations?
Program the longer blade length onto the saber with the shorter blade and program the shorter blade length on to the saber with the longer blade.
If this is purely a software problem, then the problem with move with the configuration change.
If on the other hand this is a software+hardware progrlem, then the problem might simply go away.
ProffieOS 6.x does some interesting stuff with LED color buffers, which could be related to this problem somehow.
OK, I just tried:
-
Long-blade 6.6 config onto the short hilt - 20 boots, no SD errors;
-
Short blade 6.6 config onto the long hilt - SD error on fourth boot;
-
Restored 5.9 to both hilts - no SD errors on either.
In other words, the fault didn’t move with the config - it stayed with the same board.
So it seems the board is at fault, or it seems that some miniscule variable between boards is getting upset at something in 6.6 but is happy with 5.9. For reference both boards came from KR as part of the Thrawn Hunter kit and were packed in linked, sealed anti-stat bags, so I assume came from the exact same batch of Proffies from the manufacturer.
Sorry Prof. Not what we wanted to hear, I know.
Did you end up trying to swap the SD between the two? Just curious if we can rule it out as well or not. If the SD from the short hilt works fine in long hilt and/or the SD from the long hilt creates the error in the short then we can look at the SD itself as the cause, if not then that would truly mean the long hilt’s board is the issue.
Swapping the SD cards seems like a good idea.
I know you already tried a different SD card, but it doesn’t hurt to be sure it’s the board.
A thought occurred to me though; Can you measure the battery and 3.3v pads to see what the voltages are? A weak or noisy 3.3v supply could easily cause problems for the SD card.
Will try switching the cards tomorrow (it’s late now and my daughter’s alseep in the next room, and I’ll need to do some tearing down as I loaded the hilts back up with 5.9 to get them sent out - but my customer should be OK for one more day). 
In terms of voltages, I only checked the bad hilt, but battery was fully charged and showing 4.14 volts at battery when removed from the hilt. Was also showing 4.14 volts at Batt- and Batt+ pads when the battery was in and kill key was pulled. The voltage was the same both when the saber booted normally and when the SD error was thrown. 3.3 volt pad was also showing correct voltage in both scenarios (well, 3.29 volts).
OK, I just loaded up 6.6 onto both hilts again, tested to ensure the problem still existed (it did) then swapped the SD cards over between the two hilts. The problem stayed with the same hilt/board.
Not sure if that helps or not.
Well, narrows it to the board so another variable off the table. What if you remove (comment out) these defines in your OS6.6 config?
#define DYNAMIC_BLADE_LENGTH
#define DYNAMIC_CLASH_THRESHOLD
#define SAVE_CLASH_THRESHOLD
#define SAVE_STATE
I’m thinking maybe there’s an issue with the board’s ability to write to the SD that might be causing these defines (except SAVE_STATE) are OS6 specific so they’d be the difference between the versions that could create a difference since I don’t know that any SD changes exist between the OS5 and OS6. I’ll defer to profezzorn but I think it’s a hardware issue with that specific board, there’s just more use of the SD in OS6 so it makes it more visible.
1 Like
I’ve had to go back to 5.9 and get these hilts out to the customer (I’d already held on to them a week longer than I should have done). But I’ll go through my other Proffies with the same config and try to find one with the same issue that we can use as a test bed. Will report back.
Have you try bypassing the recharge port? Ie. Not using it or replacing it. Because i have similar issue, same kit (KR Thrawn Hunter), it turned out faulty port (something wrong with its internal switch).
Pretty sure I eliminated the charge port. The problem is there whether you boot the board using battery/charge port or whether you boot using the USB connected to a computer. Also the voltages at the board are the same and in spec regardless of whether it boots correctly or boots with the SD error.
OK, good news (well, sort of) - I’ve just installed another Proffie that’s exhibiting the same problem as before under 6.x.
The config is completely different. Pastebin link is below.
The wiring is pretty standard - charge port, data 1, LED pads 1, 2 and 3 for the main blade. (This character saber has white blades, so I figured the extra mosfet wouldn’t hurt).
After wiring and checking everything with a meter, I pulled the kill key and got the SD card error. Re-insterted the kill key, waited a few seconds, then pulled it again, and this time it booted up fine. Nothing was changed between boots.
I’m in your hands - let me know what you want me to try to help track the problem.
Did we already try #define CONFIG_STARTUP_DELAY (some time) ?
*edit * I see you did. When you did, was it longer than 1000?
I tried it at 500 as the Prof suggested but still had two duff boots out of 10.
Want me to try 1000?
The default is 1000?
That said, this all might be caused by this pull request? :
and then this commit: