Probable issue with axoloti due to user's Windows permissions


#1

Hi - I successfully can connect the Axoloti board to the Axoloti app, but compiling patches and uploading them to the board does not seem possible. I suspect my user's permissions on this corporate windows PC so I will try to do it on a local admin account in a sec.

I suspect, based on past conversation, that the Axoloti Windows MSI tries to create a directory in the user's Documents folder but on my (strange) setup it is not possible - so that folder is missing. The missing Axoloti content in the documents folder is most likely key to my patch upload errors.

Just for extra info here is the full log after running the app and trying to "go live" with two tutorial patches:

USB device found
connected
Cannot validate authenticity, no signature present.
search path : objects
Axoloti says: exception: soft watchdog
Axoloti says: pc=0x20011000
Axoloti says: psr=0x61000000
Axoloti says: lr=0x800DB4F
Axoloti says: r12=0xF
Axoloti says: cfsr=0x10000
Firmware version: 1.0.0.1, crc=0x2B8D2015, entrypoint=0x20011000
finished loading objects
upgraded object by SHA : math/*c
java.io.FileNotFoundException: \Documents\axoloti\build\xpatch.cpp (The network path was not found)
Generate code complete
Start compiling patch
java.io.IOException: Cannot run program "C:\Program" (in directory "\Documents\axoloti\build"): CreateProcess error=267, The directory name is invalid
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048)
at java.lang.Runtime.exec(Runtime.java:620)
at java.lang.Runtime.exec(Runtime.java:450)
at qcmds.QCmdShellTask.Do(QCmdShellTask.java:114)
at qcmds.QCmdProcessor.run(QCmdProcessor.java:183)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.IOException: CreateProcess error=267, The directory name is invalid
at java.lang.ProcessImpl.create(Native Method)
at java.lang.ProcessImpl.(ProcessImpl.java:386)
at java.lang.ProcessImpl.start(ProcessImpl.java:137)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029)
... 5 more

Compiling patch failed ( C:\Program Files (x86)\Axoloti\app\patches\tutorials\01_sine_oscillator.axp )
Start uploading patch
bin path: \Documents\axoloti\build\xpatch.bin
FileNotFoundException
Disconnect request
Done uploading patch
Start starting patch
USB device found
connected
Cannot validate authenticity, no signature present.
Done starting patch
Axoloti says: exception: soft watchdog
Axoloti says: pc=0x20011000
Axoloti says: psr=0x61000000
Axoloti says: lr=0x800DB4F
Axoloti says: r12=0xF
Axoloti says: cfsr=0x10000
Firmware version: 1.0.0.1, crc=0x2B8D2015, entrypoint=0x20011000
java.io.FileNotFoundException: \Documents\axoloti\build\xpatch.cpp (The network path was not found)
Generate code complete
Start compiling patch
java.io.IOException: Cannot run program "C:\Program" (in directory "\Documents\axoloti\build"): CreateProcess error=267, The directory name is invalid
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048)
at java.lang.Runtime.exec(Runtime.java:620)
at java.lang.Runtime.exec(Runtime.java:450)
at qcmds.QCmdShellTask.Do(QCmdShellTask.java:114)
at qcmds.QCmdProcessor.run(QCmdProcessor.java:183)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.IOException: CreateProcess error=267, The directory name is invalid
at java.lang.ProcessImpl.create(Native Method)
at java.lang.ProcessImpl.(ProcessImpl.java:386)
at java.lang.ProcessImpl.start(ProcessImpl.java:137)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029)
... 5 more

Compiling patch failed ( C:\Program Files (x86)\Axoloti\app\patches\tutorials\02_keyboard_controlled_sine_oscillator.axp )
Start uploading patch
bin path: \Documents\axoloti\build\xpatch.bin
FileNotFoundException
Disconnect request
Done uploading patch
Start starting patch

will update after trying the local admin account.


#2

indeed, we obviously have to assume some kind of 'defaults' for a new users setup, so that we don't have to have a complex installer, asking 100's of questions smile

anyway, it is however possible to override these things... as I anticipated some have particular setup requirements.

if you need to place the axoloti home directory somewhere else (this is where its stores its preferences/builds etc)

you just need to define the environment variable:
axoloti_home

this can be set to any valid directory, that you have write permissions...

if you run Axoloti from the command line, you will see it reports which directories is using.
(I've a bug in 1.0.1 that doesnt validate these correctly, but in 1.0.2 it will report if it has an issue with this... I'm also now going to fix it so it checks for write access to the home area :))

(Ive not detailed these yet in the docs yet, as i don't want to new users, to start moving things around without some guidance, it would create a support nightmare when we have so many new users about to come online in one go!)


#3

It works completely fine on the Local Admin account without having to reinstall the app. Great!

personally I am not going to mess with the environment variable since I don't intend to use the Axo on this weird windows account anyway, but nice to know the reason for the error.


#4

cool, Im improving the error reporting now, so its obvious when you start the application, rather than waiting to build something
so all working now? hope so... and have fun!


#5

Yep all good!

note: I also suspect the Axoloti will work perfectly on my main machine at home (which has the DFU drivers for STM board configured) since I will not need DFU for firmware flashing and the axo board has its own drivers.
I assume I will still have to reinstall the WinUSB driver for the Axoloti Bulk Interface, but since the board is now recognized as Axoloti Core and Axoloti Bulk Interace there will be no problem with connecting my Discovery board version of the beta axoloti.


#6

If you have now flashed the released version of 1.0 to the Axoloti board, and have not previously connected it to your machine at home, it should just work... plug and play style.

the issue was do with how the VID/PID were reported by firmware prior to official 1.0 version, and how windows caches this in the registry... and can only be removed by some 'registry diving', which is not user friendly.

fortunately, zadig/libusb could cope with the pre 1.0 format* , winusb can't, so its less error prone for users to use this, rather than hacking the registry.

(*this was also the reason we didn't spot it, till just before the official 1.0 firmware was released... and I installed on a 'virgin' windows machine and then johannes could resolve the issue)


#7

oh awesome! Really happy with the work that was done with the windows stuff. thanks guys. Always a big bonus if i can leave out linux from the studio since I am on Ableton at the moment (am a bitwig tester but don't have a fully dedicated ubuntu machine for it since BW isn't "good enough" for me yet)