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.
thanks for the additional info!
at this point i can’t tell from the code itself how it could possibly happen, and we don’t have solid steps to reproduce to help with the investigation. obviously, this is very concerning. here is what i propose to do:
i will update the code so that the flag that indicates that all scenes should be blanked out will get reset whenever flash is updated
@tehn’s idea - i’ll add a confirmation so that if it somehow decides to overwrite scenes it will ask you to confirm first. you’ll never have to confirm in normal use but if something somehow triggers this at least you’ll get a chance to cancel.
Could this corruption happen due to
flash_write getting called somehow with a
preset_no arg equal to
flashc_memcpy((void *)&f.scenes[preset_no].scripts, ... to overwrite the next few members of
nvram_data_t? The calls to
flash_write from flash.c and usb_disk_mode.c are in for loops bounded by
SCENE_SLOTS, but grid.c and preset_w_mode.c call it with the global variable
preset_select, which gets set a number of places. Those include the SCENE op (via
tele_scene()) and the function process_preset_r_preset, which in turn is called with calculated values based on grid coordinates and an ADC read. Seems like a preset save would have to be triggered from grid mode or preset write mode for this to explain it though.
this is a good guess! the grid calculations should be okay as it applies constrains before the calculation, and from what i can tell the ADC value shouldn’t cause it either but still possible, of course. in any case we should add a boundary check in