OLED Blank After Running Upload

Proffieboards
1

Hello all. New to Proffie (Literally just got one yesterday). I just did my local setup with Arduino etc… this morning. In case it matters, I am running from Linux and not Windows, but so far that doesn’t seem to have been the issue?

Anywho, I went through some tutorials and stuff online, modifying the instructions slightly based on my OS and that I’m using a SaberTrio blade. I was able to get a sound font installed, no issues there. Everything booted back up just fine, sound font was there, etc… The issue is that now, ever since then, the OLED on my saber doesn’t boot up, it’s just blank.

I thought maybe it was the config I’d set it include (SaberTrio’s provided configs have a series of options you can choose to import), but even trying with the one specified for OLED, still nada. I tried applying some tactics I’d seen online, like toggling which button props to import or adding different imports etc… Still nada. It had happened once or twice previously after charging the power core, but came back on after turning the saber off and on again. Now it’s just… off.

I’m a software developer, so I know my way around code, but the Proffie stuff is still new to me (obviously). I did check through other posts referring to OLED that I could find, but didn’t see anything matching my exact situation that had a solution. I’ll provide some details below, but if other info is needed I can provide that as well. Any help appreciated, thanks!

Lightsaber model - SaberTrio Senza w/ latest ProffieBoard setup from them
Arduino IDE - version 1.8.19
ProffieBoard - version 3.6.0 in the Boards Manager
‘Tools’ menu selections:

  • Board: ‘Proffieboard V3’
  • USB Type: Serial + Mass Storage
  • DOSFS: SDCARD (SDIO High Speed)
  • CPU Speed: 80 MHz
  • Optimize: Smallest Code
  • Port: /dev/ttyACM0

For those familiar with the SaberTrio provided files, I’m using config ‘s3config_v3_Kros_OLED.h’, mostly untouched, just added a font. But even unmodified, I still get the issue. Same thing if I use the default ‘s3config_v3.h’ config file. Also, not sure if it’s related, but originally the SaberTrio power core would make a sound after inserting it when the pommel made contact with the hilt, then another when it screwed in. Now it only makes the sound when it screws in, not on first contact.

Anyway, that’s all I can think of, but let me know if there’s any other settings or files or whatever I can provide to give a clearer context.

2

At first I was thinking that you might not have the right images and stuff on the SD card for the oled to work, but I don’t think that is it, because some of the things that the OLED does (like PLI) is independent of what images and animations it finds.

So, that just leaves configuration. The OLED should work if you have it configured in your config file. There are basically two ways to do that.

#define ENABLE_SSD1306

or:

#define INCLUDE_SSD1306

// This, or something like it would go in some other section in the config file
StandardDisplayController<128, uint32_t, STRTYPE("oled1/")> display_controller1;
SSD1306Template<128, uint32_t> display1(&display_controller1, ID1 /* enter I2C ID of first display here */);

If you have one of these in your config file, it ought to just work. (Unless S3 is doing something special, in which case you would have to talk to them to figure it out.)

You might want to try a super-simple config file without any s3 changes to see if that makes the oled work. (Just make a config file here: Proffieboard V3). If it works, then at least you know it’s not a hardware problem. If it doesn’t, then maybe it is a hardware problem…

1 Like
3

Also @Joe_Bochinski, if you didn’t know already, Sabertrio made their own “ProffieOS” out of the official ProffieOS. Not sure if all their modifications have been made public, so we may not know all of their “tricks”.

1 Like
4

Word, I’ll give that a shot and see what it comes up with. If it is hardware, it might be annoying but I can probably contact SaberTrio to get it resolved, I’ve heard pretty good things about their customer service.

I did see ENABLE_SSD1306 in the ProffieOS.ino file, so I’m pretty bamboozled. I’ll post results once I try the dumbed down config.

Also, props to y’all for the snappy replies - I was fully expecting to have to wait for a day or two based on past forum experiences

5

It’s rarely more than a few hours, except if we are all on holiday at the same time.

1 Like
6

Okay, so I tried the dummy config, same issue. I did end up determining that it’s not a hardware issue, but is something with the images themselves, though I’m not sure what.

I enabled diagnostic commands and some more verbose logging so I could ping stuff off of the serial command terminal. From there I was able to spot that it was kicking an error about image formatting:

Playing common/idle.bmp
Unknown image format. a=-1 b=-1 pos=574
read image fail

So to test the theory, I wrote up a quick Python script to rename every bmp file in the SD card to .bad. Booting it back up, the OLED powered back up and showed the text displays for the fonts, so it’s not hardware. So I think now it’s a matter of trying to hunt down which image is the bad one, or maybe just reformatting, unless you’ve seen this error before and know a quick fix for it or if it’s another issue entirely or something.

7

So to test the theory, I wrote up a quick Python script to rename every bmp file in the SD card to .bad.

Should be [‘name].bmp’

Didn’t realize it’d eat the angle brackets as markdown/HTML tags, whoops lol.

8

Welp, I used ImageMagick to reformat the idle.bmp file in common and it appears to be working now.

However, I also discovered while mucking around in the serial monitor terminal that it can get finicky while doing things when the SD card is mounted as a drive. Which I had been doing when I was uploading the arduino updates, so it’s possible there was some kind of issue during the compilation process maybe?

Idk, but it’s working now so I’m not gonna complain too much lol

9

It’s best to have the ProffieOS folder on your computer and not the SD card, if that’s what you mean. There’s more than a few reasons having the sources on the SD leads to issues.

Otherwise the SD card is irrelevant for compilation and upload.

10

With older ProffieOS (older than OS8.x still in beta testing), you should always un-mount the sd card before uploading a config or “unselect” Mass Storage from Arduino. From OS 8.x, there is a new #define MOUNT_SD_SETTING which will only mount your SD-card if in serial monitor you type “sd 1” to mount and “sd 0” to “unmount” it.
More info here:

Since you are using Sabertrino’s ProffieOS, always “safely” eject your SD-card before uploading a config, or before unplugging your Proffieboard from your computer or you might cause SD-card corruption.

1 Like
11

To clarify: this is only if accessing the SD through the proffie USB. I’m not sure how @Joe_Bochinski has it set up right now, but thought I would add that. :slight_smile:

1 Like
12

He said he does use Mass Storage

1 Like
13

Yep, I learned those few nuggets after noticing some odd behavior

Yeah, I learned that pretty quickly. Being a programmer, I realized there might be issues being caused by having the updated source configs on the drive itself. So now I have them in a dedicated folder in my computer along with my other coding projects.

And yeah, I figured out the first part of this after playing around a few times, specifically the serial monitor terminal. I kept wondering why I was getting weird errors from basic commands until I noticed some error logs about mounting/unmounting and the SD card being busy and had a little “Oooh… yeah that would make sense” moment. But good to know about the new features coming down the pipe.

Oh yeah, I work with mass data storage and servers and stuff all the time, so I’m hyper paranoid about mounting/unmounting. I always triple check before unplugging; unmount the device either from from the UI or terminal with sudo umount /dev/sdX, then check that it’s not visible in the file explorer, then run lsblk from the terminal again to really make sure it’s not mounted anymore, then unplug.

But yeah, you were both essentially right, I think, about how I was initially doing it. I had already self-corrected most of it, but I appreciate all the extra info

1 Like
14

That’s why I get for skimming! You’re more on top of it than I am.

1 Like
15

A further update:

Saber worked for a bit, then started having weird issues again with the blade ceasing to function after a few swings or certain conditions happening. I think one condition was the KyberDial feature that SaberTrio sabers have (or at least that they have; I don’t know if that’s a specifically them thing or if it’s a standard feature available to Proffie boards).

From what I could tell, it seemed like conditions involving the OLED would cause an internal error, and sometimes the OLED screen would get all screwy.

So, I think my issue was the image files, and my guess is that something about how I did my first round of flashing the drive or two with Arduino probably messed up something in the bits on the bmp files since I hadn’t yet figured out the proper procedures to use. I’m not sure exactly what happened, but based on my own coding experiences, it feels like something got screwy after I did my first upload or two with Arduino, so I think maybe it was some combination of the whole mounting thing, modifying and deploying from the onboard config files, and/or running everything from Linux that caused something to go pear shaped.

My next step is going to be to reformat the SD card and do a ‘factory reset’ effectively and start fresh. If that works, then I’ll move on to more carefully adding the sound fonts and changes etc… now that I have half an idea of what I’m doing.

I’ll post back here with results in case it works and maybe someday down the line some other poor schmuck runs into the same issue lol

P.S. - Also, in case it does actually help anyone down the line, the command I used to reconvert some of the erroneous bmp files was: convert image_name.bmp -resize 128x32\! -threshold 50% -type bilevel -define bmp:format=bmp3 BMP3:image_name.bmp but with the actual path to/file name of the image instead of ‘image_name.bmp’

ImageMagick version info: 6.9.12-98 Q16 x86_64 18038 executed from Ubuntu 24.04

16

It is a “them thing”, I have heard of it but I know nothing about it.

That would have been my next suggestion, re-format the SD-card, use this

But you are using Linux, so in your case:

It is usually recommended to make large modification to your SD-Card from an SD-Card reader rather than from your Proffieboard as it is much faster and less susceptible to SD-Card corruption.

  • always “safely eject” the card before unplugging it from the reader,
  • always “safely eject” the card if it is in your Proffieboard (if Mass-Storage is used) and the Proffieboard is connected via USB to your computer before you disconnect the Proffieboard
  • always “safely eject” the card before flashing a new config if Mass-Storage is used
  • never flash a Proffieboard from a folder on your SD-Card but always copy that folder to your hdd or ssd and run it from there.

Last thing, check that your battery is fully charged, there are cases of “weird things starting to happen” when the battery is depleted enough, even though “not yet empty”.

I think that should cover the basic do/don’t.

1 Like
17

I think I was already doing most of that - but I did read through and double check to make sure I didn’t miss any rookie mistakes. I did end up having some weird issues with the SD card where the proffie board couldn’t read it, but then I swapped it to another device and it was fine. And I used a different SD card in the Proffie board, and it was fine… so I don’t know what that was about. But whatever.

At any rate, I did get it reformatted properly using the linked tool there. Got the configs reloaded and the saber mostly working. I also started working on a Bash script to fire off the upload so that I could have it check and safely unmount the SD card before doing the upload. Because while I’m hyper paranoid about unplugging without unmounting, I have a bad habit of forgetting when I go to run the upload. Still working out a couple kinks with recognizing the DFU stuff though.

The OLED is still not showing up consistently, and I’ve had some issues with certain sound files not being found while the saber is on. And with having the board think my button is a blade and the blade sock the button (for lighting purposes - the actual button still does button things). But I think now it’s mostly down to tinkering with the configs and reading the docs until I get everything lined up right.

18

I found this in my notes:
"ProffieOS7 requires SD card preformance to be 1200kbps read speed with 12 simulatenous audio streams.
Subpar or poor performing SD cards will cause the saber to lag or freeze.
If you experience lag or slow response you need to run ‘sdtest’ in Serial Monitor.
Even if SD is labeled as high performance you should run sdtest to be sure.

First, remove DISABLE_DIAGNOSTIC_COMMANDS define from your config.
Upload new config (you may temporatily need to remove some presets if exceeding FLASH memory)
With saber connected go to Arduino > Tools > Serial Monitor
Type ‘sdtest’
If you do not have 1200kbps read speed and 12 simulatenous audio streams you will want to replace your SD
with a better performing card.

You can also improve SD performance via formatting and file structure,"

For the file structure, if I remember correctly:

  • no spaces in font folder names
  • max 8 characters for font folder names
  • max 16 fonts in the root of sd-card (if you have a common folder, put in root instead of one of the 16)
  • if you want more than 16 fonts:
    • 15 fonts in root and an extra folder with 16 more fonts
      or
    • 14 fonts in root and 2 extra folders with 16 more fonts each
      or
    • 13 fonts in root and 3 extra folders with 16 more fonts each
      or
    • etc, etc
  • freshly format your sd-card, copy first your 16 or 15 or 14 or … most important fonts, then copy your additional folder or font folders one by one in order of which one you want to have fastest access first and slowest access last.
  • then you can also optimize each font folder with this tool:
    https://www.soundfontnamingconverter.com/
    • select Proffieboard to Proffieboard
    • select your font folder (or folder of font folders, then don’t forget to select Multiple fonts)
    • optional (specially if you got some free “floating around” fonts from the internet), you can select Enable High-Pass Filter (this will cut some inaudible frequency stuff that are know to potentially cause problem with your saber speaker - it is too small to reproduce those frequencies but it will try anyway)
    • click rename and download zip.
    • if you have sound files that are not .wav 44100 rate & 16 bits (the only format that ProffieOS can read), like an .mp3 or .wav 48000 rate, you can use Convert Audio Only.

I think that is it.

19

What version of ProffieOS do you use ? This has been fixed in ProffieOS 8.x (still in Beta testing) from github master with #define MOUNT_SD_SETTING

For the latest OS, go to:

Click the Green “Code” button
Click “Download ZIP”
Then extract the ZIP file to your computer
Save your previous configs to the /config folder of the new extract.
Update the new ProffieOS.ino to define your config
Launch ProffieOS.ino for OS8 in Arduino and upload as usual

20

Ah, good stuff to know. I was already on to some of that - I’ve had the DISABLE_DIAGNOSTIC_COMMANDS commented out for a bit so I could run tests in the serial monitor terminal, but I didn’t know about the sdtest one. I’ll check here in a second, but that’s probably part of my current problem with the audio lag. And I was actually just reading up on the folder/file structure thing and in the process of adjusting that. Though I’m currently only loading a handful of fonts to keep it simple. I’ll definitely take a look at that sound font naming converter tool, that seems super helpful.

And I’m using version 7.12 I think, that’s what SaberTrio has listed on their website so I figured I’d use what they used. Though if you think it will work still, I may try the 8.x version. Generally I prefer to use the latest versions of whatever I’m doing, but often when it comes to compatibility and configuration when using something someone else built, I tend to use the exact versions they did. But if there’s no compatibility issues then I have no problem personally updating to 8.x

Also - as a side note, I’m very familiar with GitHub, I have probably 30-40 repos up there on my account and regularly use git professionally and recreationally lol. But I also understand most people aren’t familiar, so I appreciate you taking the extra time to mention the exact instructions for how to get stuff from there. You guys have been providing pretty top-notch support and advice so far, so that’s pretty awesome of y’all.