Just came across this post on the Arduino forums which sounds like a very similar, if not identical, issue. The fix was to allow the OLED sufficient time to initialise itself before sending data to it. Hagiwo’s code doesn’t appear to allow a significant delay between the start of setup() and the call to OLED_display(). So it might be worth adding a
delay(500);
just before the OLED_display() statement in setup()
Hope this may help!
Wow, thanks Clarionut to look into yhis further. Glad that i’m not the only, and absolutely the only one having this. As soon as i get home, im gonna check this. I’ll let you know👍
Just added the code and build in the module. It works but lets see for how long.
I did notice the small delay for the oled startup and when I press reset, it takes a bit longer to refresh
so this means that I’ve placed the code in the right spot.
I keep y’all informed on how it goes from here but I have good hopes so. Thanks a lot for this tip.
If it keeps working I will let @HAGIWO know so he or she (I don’t know 
) can adapt the original code.
That’s the wrong way round. The delay(500) should be before the OLED_display() statement to give the display time to initialise itself before the Arduino communicates with it.
If this is the issue, it’s not related to how long the module has been running, it’s just related to timing on startup. So you should be able to test it quickly by powering it off and on again a few times.
Agreed, its the wrong way around
Hi,
I just changed to code as you advised. Delay comes BEFORE the oled_display statement (sorry I didn’t read well)
when powering up my rack, I now see some gibberish (a few milliseconds) and then the normal gate sequencer layout as usual.
I assume that the gibberish is the delay that is doing its part.
so lets play with it and see if this solves the issue.
The gibberish is just that the command to initialize the display has not been executed yet, so whatever is in the framebuffer of the display is usually shown on the screen until that command is issued, so the delay allows you to see what you couldn’t before by giving you a 500mS window before it clears.
If anything, seeing this initialization is pretty encouraging.
And here we go again. Unfortunately the delay(500) line added to the code didnt solve my issue. Again dead! If the oled doesn’t work the rest should keep on working. Right? So if the oled stays black after power on the module, and i see no triggering happening at my drum modules, i suppose its still the Arduino Nano failing. Im starting to think about the order i switch on my system because if it occurs, it occurs when switching on the rack with the drum modules in it last. I sometimes dont need drums so i leave it powered off, and when i need drums for any reason, switching on that rack, then it happens. Gonna test that out if powering on in some order does make any change.
That’s a pity. I guess the focus perhaps falls back on the power supply. How heavily loaded is it, particularly when switching on the last rack? There’s an instantaneous heavy load until all the smoothing capacitors in your modules are charged.
I still don’t understand how this would deprogram your Arduino though. Once it’s failed does it stay failed even if you power up that rack first?
Just re-uploaded the sketch. Everything works again. Try later this evening testing if power on my 4 racks in a specific order changes anything.
Only thing i did different was using opamps for each Nano output with diodes. Because then my drum modules responding. In Hagiwo’s version, he uses clamping diodes and a 470R resistor.
Can you confirm that the diode and opamps are ok? Or is it possible that they do something when switching on? The diode should block reverse current back to the Nano’s output. Right?
It’s fine to buffer the outputs from the Arduino with an op-amp, I don’t like the diode and resistor that Hagiwo uses either. You shouldn’t need a diode if you use an op-amp, just a non-inverting buffer configuration with appropriate gain for the trigger level you want to achieve. I used this circuit in my version of the Euclidean Rhythms module:
and similarly for the other three outputs.
Did you use the Arduino Pico Mini for the Euclidean?
It’s a pro mini, which uses the same ATMEGA328P chip as the nano.
Ok cool. But not the same pinout or footprint. That means that i need to build from scratch. No biggy either.
Changing to a different Arduino board feels like a bit of a ‘Hail Mary’ solution. I’d check out the potential power supply issues (startup order of your racks and total current draw) first.
Strangely my other 5 Arduino Nano based modules are having no issues. I wonder why this particular one has….
Therefore im not quiet sure if its the power or power consumption but hey, at this point my mind says, everything is possible. I have used this module as the Euclidean sequencer in the past. Also with no issues. I switched to the 6chn gate seq. because the Euclidean lacks to save presets. So everytime i switch on the rack, i need to dail in those dots and rotate the squares, triangles, hexagons etc etc. 
But for testing i could upload the euclidean sketch and see if this better than the 6ch gate seq.
Particularly strange if the same hardware worked problem free running the Euclidean Rhythms sketch. It’s hard to think of a truly logical next step at this point…
Update!!
I tested the module with the Euclidean loaded. Switched it on and off for 1 hour straight. Sometimes with short breaks, sometimes longer interuptions and guess what?? It stays and keeps on working. This could mean that something in the 6chn sequencer code is messing things up. I mean same hardware different sketches.
On the other side im not happy with the euclidean because i get frustrated when i need a kick pattern (square) with hits all the way round, and the fact that the rotary knob is sensitive i easily mess up things, skipping or unintentionally change things that i dont want.. need to go through the whole menu to get back to P1 to change something and boom. Apperantly i was changing something on P3 instead. Aarrgghh!
That was the main reason i changed to the 6chn gate sequencer. Works waayy better imho.
To bad that things that don’t work for me, never breaks and keeps on working, and things that works for me, somehow are not working. Well. What can i do?.
I think im gonna build that mthrfckr all over again but then with a Pico or whatever
I’ve never heard of an Arduino sketch that can self-destruct like that, it’s really weird.
In my opinion there are issues with both the hardware and the original code for the Euclidean Rhythms module and IIRC the drum sequencer uses the same hardware. If you are going to build a new one it might be worth looking at some of the changes I made to my E.R. module, e.g. hardware SPI OLED, using an interrupt to monitor the trigger input, buffered outputs, a more compact graphics library & getting rid of slow digitalWrite calls.
