Mass storage working with OS6.7 but not OS7.14 (Poffieboard V3.9)

When using OS7.14 on a V3.9 using Serial+Mass storage, after upload the board pops up as USB drive, but when trying to access the data on the SD card an error is reported ‘Please insert disk into USB drive’
Tried several 3.9 boards same effect

Reverting to OS6.7 solves the problem, and board pops up and data is accessible via explorer

Am I missing a setting in OS7.14 that enables the acces of the SD card via mass storage?

Win11
Arduino 1.8.13 & Arduino IDE 2.3.4 tested, same result
Proffieboard 4.6.0 plugin

Did you have the USB Type set to a Mass Storage option in Arduino when you uploaded?

Arduino > Tools > USB Type

Hi @obirobkenobi , welcome back!

This is the first I’ve ever heard of such an issue, and a recreatable one at that.
If I had to guess, I’d say it’s something specific to your computer as opposed to the board, but it is indeed weird that the ProffieOS version seems to be the determining factor.
I’d have to check the history, but I don’t think there were any changes to Mass Storage until after 7.14.

  • Could you try a different PC to see if that makes any difference?
  • Could you try the Github Master to-be-OS8.x version and see if the issue persists?

i have just tried to repeat this with the same setup.
3.9 board
win11
arduino 1.8.13
4.6 plugin
serial + mass storage
i could not replicate the problem you are having, sd card shows up fine

i did find tho that if you don’t have “webusb” included in the usb type then the proffie board is blanked out in the system tray so there is no option to eject it only to eject the sd card

are you ejecting your board and sd before removing the cable

This sounds like a buffer overflow bug.
Basically, something is modifying memory outside of where it is supposed to, and making modifications to whatever is next in memory. To reproduce such a bug, it’s important to have exactly the same settings, therefore:

  1. can you post your config file? (Are you using the same config file with 6.7 and 7.14?)
  2. Are you using “smallest code” in Arduino → Tools → Optimizations

Thank you for all your answers and suggestions!

@Fett263: Yes I had Mass storage & serial set in the Arduino IDE.

@NoSloppy: Different PC’s same result. I pulled the current master from Github and tested with the same result

@Aaron_Hilditch Thanks for the suggestions. I had serial+Mass storage only.

@profezzorn: I was indeed using smallest code. Your suggestion using the exact same config file for both 6.7 and 7.14 triggered some new insights;

On 7.14 this was my first prop for a blaster using the

#ifdef CONFIG_PROP
#include "../props/blaster.h"
#endif

On my 6.7 setup I just tried a generic saber.h prop.

When I comment out the “…/props/blaster.h” part, the V3.9 board is accessable via explorer and all the files can be read and modified. When using the “…/props/blaster.h” I only get the ‘USB drive (D:)’ icon and when trying to acces the files, I get the error to put in a SD-card.

This is happening on both 7.14 ánd the latest master on GitHub. My guess is that there is something wrong with the blaster.h prop definition.

Looking at the blaster.h I see a lot of override of the SaberBase class, although I can not pinpoint the exact member or missing loop that is the culprit of the error.

I tried to add a Loop() override to the blaster.h, thinking the loop might be needed to trigger the SD-card handling, and there is no Loop override in blaster.h But this did not help

void Loop() override {
    PropBase::Loop();
  }

Bare minimum config.h that has the error for SD-card access;

#ifdef CONFIG_TOP
#include "proffieboard_v3_config.h"
#define NUM_BLADES 2
#define NUM_BUTTONS 1
#define VOLUME 2000
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_PROP
#include "../props/blaster.h"
#endif


#ifdef CONFIG_PRESETS
Preset presets[] = {
  // Default basic blast color with red audio flicker on blast
  { "_blstr1", "tracks/mars.wav",
    StylePtr<Lockup<BlastFadeout<BlastFadeout<Black,AudioFlicker<Black,Red>,250,EFFECT_FIRE>,AudioFlicker<Black,Blue>,1500,EFFECT_STUN>,AudioFlicker<Black,Red>>>(),
    StylePtr<Lockup<BlastFadeout<BlastFadeout<Black,AudioFlicker<Black,Red>,250,EFFECT_FIRE>,AudioFlicker<Black,Blue>,1500,EFFECT_STUN>,AudioFlicker<Black,Red>>>() }
};

BladeConfig blades[] = {
 { 10000, WS2811BladePtr<125, WS2811_ACTUALLY_800kHz | WS2811_GRB>(),
   WS2811BladePtr<14, WS2811_ACTUALLY_800kHz | WS2811_GRB, 7, PowerPINS<bladePowerPin6> >(),
   CONFIGARRAY(presets) },
};

#endif

#ifdef CONFIG_BUTTONS
Button FireButton(BUTTON_FIRE, powerButtonPin, "fire");
#endif

And commented out blaster.h, reverting back to a standard saber.h prop, that gives full acces to the SD card using explorer

#ifdef CONFIG_TOP
#include "proffieboard_v3_config.h"
#define NUM_BLADES 2
#define NUM_BUTTONS 1
#define VOLUME 2000
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_PROP
#include "../props/blaster.h"
#endif
*/

#ifdef CONFIG_PRESETS
Preset presets[] = {
  // Default basic blast color with red audio flicker on blast
  { "_blstr1", "tracks/mars.wav",
    StylePtr<Lockup<BlastFadeout<BlastFadeout<Black,AudioFlicker<Black,Red>,250,EFFECT_FIRE>,AudioFlicker<Black,Blue>,1500,EFFECT_STUN>,AudioFlicker<Black,Red>>>(),
    StylePtr<Lockup<BlastFadeout<BlastFadeout<Black,AudioFlicker<Black,Red>,250,EFFECT_FIRE>,AudioFlicker<Black,Blue>,1500,EFFECT_STUN>,AudioFlicker<Black,Red>>>() }
};

BladeConfig blades[] = {
 { 10000, WS2811BladePtr<125, WS2811_ACTUALLY_800kHz | WS2811_GRB>(),
   WS2811BladePtr<14, WS2811_ACTUALLY_800kHz | WS2811_GRB, 7, PowerPINS<bladePowerPin6> >(),
   CONFIGARRAY(presets) },
};

#endif

#ifdef CONFIG_BUTTONS
Button FireButton(BUTTON_FIRE, powerButtonPin, "fire");
#endif

So by temporarily commenting out the blaster.h, I am able to access and modify the soundfonts on the SD card. Re-flashing it with the blaster.h enabled makes my blaster go ‘ZapZap’ (as it is an Arcane inspired blaster) :slight_smile:
For now this is a workaround that I can live with, but for other blaster builders this might be an issue?

I think maybe I know what is happening here…

Blaster defaults to “on” in some cases, which means that the hum of the font will start playing immediately. In those cases, accessing the SD card from the proffieboard isn’t really possible anymore, because the SD card is busy. (ProffieOS is using it to play the hum.)

Probably the best solution to this would be to make it so that the idle timeout works even when the blaster is “on”. That way the sound would turn off after a while. Also, issuing “sd 1” from the serial monitor would turn the sound off, so that you could access the SD card from the computer.

After some testing I can confirm that you are 100% correct.

Blaster.h turns the prop on, when selecting the preset (so also at startup)

  // Pull in parent's SetPreset, but turn the blaster on.
  void SetPreset(int preset_num, bool announce) override {
    PropBase::SetPreset(preset_num, announce);

    if (!SFX_poweron) {
      if (!SaberBase::IsOn()) {
        On();
      }
    }
  }

Commenting out the ‘On()’ results in normal access to the SD card via explorer.

To test the ‘‘sd 1’’ functionality, I added this to config top

#define ENABLE_DEVELOPER_COMMANDS
#define MOUNT_SD_SETTING

And after uploading using the blaster.h prop, the USB drive shows, but is not accessible. After typing ‘sd 1’ in the serial monitor, feedback is given ‘SD Access ON’, but the USB drive remains in-accessible (‘please insert a disc’ error)

Trying the same with the saber.h as prop file, shows an initial Removable drive (in-accessible with ‘please insert disc’ error). After setting ‘sd 1’ the drive is accessible, and files can be modified.

As most of this is now related to the blaster.h prop file, it might be helpful to change the name of this topic to ‘Mass storage not working correct for blaster prop’. But I can not see how to modify the title of a thread.

Also there is a test-request for the 8.x alpha testing, this phenomenon might relate to os8.x as well? (Removable disk showing but no acces, only after ‘sd 1’ disk is accessable). It would be nice if the drive does not show when SD access is not set?

(This is all tested using the current master on Github)

If you do off before sd 1, then does it work?

Yes and no. The blaster prop turning on and staying on, making it impossible to read the SD card from the computer is not a new thing, so technically not an 8.x feature, but that doesn’t mean we shouldn’t try to fix it of course.

MOUNT_SD_SETTING is new, and is possibly the fix for this problem, but maybe it needs to turn things off and/or forcibly close all open files in order to make the sd card actually accessible.

“sd 0” could potentially initiate a preset change to make things go back to normal again.

Not sure if that is possible, it’s certainly a lot more involved than what the current sd setting does. (Which just makes the SD as busy so you can’t access it.)