if i’m reading the code correctly anything other than
0x22 would get it reintiailized, so if it became corrupted in such manner it would load with blank scenes. but yeah, i’ve never heard of anything like this happening, and i can’t think of a scenario the firmware would do it other than after reflashing it. that part of code only gets called from the boot up code and only when it’s reflashed.
if i’m reading the code correctly anything other than
@tehn I did not witness it. They just weren’t there anymore. Will back up!
Actually, it might be a good thing to start from scratch
I was hesitant to post, as I don’t have many details. But, when I updated to 3.0 I noticed something similar. The first time I powered the TT on I was greeted with the stock/ demo scenes, but they all disappeared after a few power cycles. It’s hard to say just when as I might not have noticed immediately.
(At the time, I just assumed it was user error somehow and decided to keep a lookout here for similar reports.)
edit: for what it’s worth, I just reflashed 3.0 and the stock scenes have persisted through multiple power cycles.
I’ve recently updated to 3.0, the default scenes are there and haven’t saved any of mine yet since I’m still in the explore/study stage but I’ll keep an eye on it.
thanks for testing! when it happened that time do you remember if you saved any scenes at any point, or was it still just loaded with the release scenes?
I don’t think that I had saved anything yet, it was fairly soon after I updated. For sure a no on the calibration ops.
I haven’t used calibration ops ever (unless I know them as something else?)
that would be
i’m doing some testing as well, so far not able to reproduce it, will go over that code tomorrow as well to see if i can spot anything.
so far i’m unable to reproduce the issue. if anybody else ran into this at some point - could you post as many details as you remember?
i’m also not seeing anything in the code itself. perhaps other developers could take a look and see anything i’m missing in the following analysis?
here is what we know:
- this happened with the official 3.0 release with the default scenes included
- at some point (after several power cycles) all scenes are blanked out.
this implies that at some point flash was written to.
f is local to
flash.c so the only way it could’ve been done would be through the functions exposed in
flash.c. i’ve looked at all of the places where these functions are called.
flash_prepare gets called each time a module is powered, and if
f.fresh is not
0x22 it will blank out all of the scenes. the only way for this to happen should be flashing tt with a non release firmware (the official release would already have it set to
0x22, otherwise the default scenes would also get overwritten on the 1st power up, which we know didn’t happen).
flash_prepare is not called anywhere else.
f.fresh somehow gets overwritten when something else gets updated (last mode being the primary candidate as it gets updated whenever a user navigates to a different page). i’ve double checked all of the places where flash is written to and all
flashc_memcpy calls are done with proper
sizeof. also if this was the case then we would see this happening a lot more. i’ve also tried saving from every mode to see if i can reproduce - no luck.
3rd possibility: something calls
fresh_write (which writes an individual scene) with a blank scene looping over all available scene slots. the only place other than
flash_prepare that does this is when it reads from USB - but it only does it if it finds a valid scene file. you would have to use a USB stick with files specifically named for reading for each scene for this to happen - not very likely.
flash_prepare seems to be the most likely candidate, which means it’s back to
f.fresh getting corrupted somehow. but i don’t see how it could possibly get overwritten - it only gets updated in
flash_prepare. so it would be either it getting corrupted by itself at some point or getting overwritten when something else is updated. could there be some tricky possible issues due to using
flashc_memcpy with structures? padding not being accounted for somehow? but
sizeof would take that into account…
I am fairly certain that when I installed the official 3.0 release, I did not get any default scenes - just had empties. I had just assumed it didn’t include any. Not sure if that’s helpful or applicable here or not.
I have not had any trouble with losing any since then.
@scanner_darkly @EqualTemperament I’m working on trying to get your two teletype/grid integration scenes (morphing faders and base controller) to work and I am having trouble getting the 301 to recognize commands from teletype. I’m on Teletype 3.0.0 firmware (plus a few keyboard fixes) and 0.3.25 on the ER-301 (revision 10 board, did not have to solder i2c pins). I am using a 3-pin to 3-pin cable to connect between an i2c backpack on the teletype and the 301 (no twists, like the wiki says). I have enabled teletype integration and am using the first address (0xBO) in the device settings on the 301.
On a clean scene, I can not get the 301 to recognize the commands
SC.CV 1 V 5 or
SC.TR.P 1 when the port is set to 1 for either device in the 301. By not recognize, I mean that you don’t see the oscilloscope present on the ER-301 screen respond to the changes. Any ideas? About to try a 3x2 -> 3x2 ribbon cable I have to see if it happens to be the cable.
you have to set the address to
0x31 (doesn’t matter which). details here: https://forum.orthogonaldevices.com/t/i2c-communication-with-monome-teletype/743/466
Ah awesome, thanks, the Wiki’s info about addresses here might not be up to date. It mentions 0xB0 for ports 1-100. http://wiki.orthogonaldevices.com/index.php/ER-301/Teletype_Integration#Configuring_the_ER-301
Changing to 0xB1 works perfect, thank you!
@scanner_darkly @yoyosandshoes @tehn I’m still running 3.0 RC5 on my Teletype - not yet upgraded to the release version - and all my scripts are backed up… Is there some testing I can do here that might help? A specific version to upgrade to, specific steps to take, things to check / note along the way etc.?
thanks for the offer - this would be really helpful! the 2 cases we know of happened with the release version, so probably best to test with that as there is a small chance it was something introduced since RC5. it’s hard to say what to test for though as it’s not clear at which point it happened, so maybe just use it as you normally would and keep an eye on the scenes, and if you are able to reproduce it see if you can remember what you did just before it happened - this would help narrow it down.
No worries! I’ve upgraded to 3.0.0, and so far everything is fine; Teletype boots as TELETYPE 3.0.0 22D6CE8, default scripts were present (but script 08, previously “ORCA TELETYPE VERSION” has been replaced by a script named named “TEST”).
I replaced all scripts with my backed-up scripts. I’ve power-cycled a few times, started up with & without the keyboard connected, loaded different scripts: all scripts are still there. I’ll let you know if it all goes pear-shaped.
Just noticed this happened with mine that’s on the latest release. All saved scenes blank.
In a makenoise powered skiff. Didn’t have anything plugged in or out.
I’d updated a few weeks ago and things were fine. Just noticed it today and hadn’t used it in the last week or so.
Sorry not more details.
do you remember if you saved any scenes at any point before it happened, or was it just the default scenes that come with it?
Yes, I saved a couple scenes (3 or 4) before it happened. I’ll reinstall a pay a bit of attention when turning it on and off.