Enabling IWDG globally seems a bit risky as it can be left on in a FW release accidentally.
Also, it’s possible to have a version of bootloader that only enables WD after reading firmware header that enables it as an option. I’m planning to use that approach for Daisy, however that would mean that IWDG would be started by bootloader at a later stage.
Sorry I got confused about Device/Host…
To be clear, my IWDG problems were on v20.7 only. IWDG was working properly in my develop branch build (efaaa7661bde). I saw IWDG problems when I reverted to efaaa7661bde midiboot + v20.7 magus.
I will do a build with OpenWare git:d6c58cf8ec6126 + Libraries git:ec27ac127a9 (ie current develop head) and test tonight.
Can you clarify:I still have #define USE_IWDG added to MidiBoot/Inc/hardware.h and Magus/Inc/hardware.h. Should I remove these two changes, now that there is one in Source/device.h? Or leave them where they are?
C preprocessor accepts duplicate defines, leaving them or deleting won’t make any difference.
Also, it’s probably a good idea to make sure that Build directory is empty before building. I think that recent update to libraries prevents “make clean” from deleting files, so made a PR that should fix this. I wonder if it could be that you’ve made a build with some of the object files that didn’t have IWDG enabled because of this issue.
I think I was pretty careful about running git clean -xffd when I was working with efaaa7661bde. I didn’t do it last night, but that would have left me with files from efaaa7661bde (which worked with IWDG). I’ll make sure to do it tonight.
What I saw tonight:
d6c58cf8ec612 from develop with the appropriate Libraries submodule.git clean -xffd (well, an hg purge --all but same difference)make for midiboot and magus.efaaa7661bde. I boot up, I see “ERROR: Failed to start progr am task”, if I go to the PRESETS pane none of my patches are there. If I open https://www.rebeltech.org/patch-library I get “failed to connect to owl”. If I run OpenWareLaboratory I get “Failed to connect”. I assume MidiBoot is working, but I cannot get into MidiBoot (if I could upload a patch that crashed I could get into MidiBoot, but I don’t know how to upload a patch without USB!)I did try something I didn’t think to try last time: I looked in Device Manager, I saw an OWL-MIDI device but it doesn’t seem to be able to talk to it.
Also this second “Unknown USB device”; I don’t know what that is.
Any suggestions?
(Also, is it weird Windows thinks it’s a USB audio device and not a USB midi device? Is it possible after the USB changes you made, I need to somehow change the driver? Are you testing on Windows or Linux?)
The new driver is definitely supposed to create an audio device - the point of current updates was to add support for USB audio. Current build on Magus sets number of audio channels to zero, but it’s still present as a class-compliant audio interface. On LInux it works without any issues, I wonder if Windows wants you to enable that audio interface before MIDI is usable.
MidiBoot uses different driver - I think that one is only present as MIDI interface. Actually there was some commit when it was using audio driver too, but it got reverted.
USB Audio sounds nice as a feature. But maybe Windows doesn’t support 0-channel usb audio devices.
More information:
The second screenshot, “Unknown USB Device”-- this is something else. This is present even when Magus is not plugged in.
If I look in the Driver pane and request Driver Details, I see
If I look in the Events pane I see 3 events within the same minute. In order the events are:
Device USB\VID_1209&PID_DADA&MI_00\7&11b12b6d&0&0000 was started.
Driver Name: wdma_usb.inf
Class Guid: {4d36e96c-e325-11ce-bfc1-08002be10318}
Service: usbaudio
Lower Filters:
Upper Filters:
Device USB\VID_1209&PID_DADA&MI_00\7&11b12b6d&0&0000 was configured.
Driver Name: wdma_usb.inf
Class Guid: {4d36e96c-e325-11ce-bfc1-08002be10318}
Driver Date: 07/17/2020
Driver Version: 10.0.18362.997
Driver Provider: Microsoft
Driver Section: USBAudio
Driver Rank: 0xFF2002
Matching Device Id: USB\Class_01
Outranked Drivers:
Device Updated: false
Parent Device: USB\VID_1209&PID_DADA\386E365C3337
Device USB\VID_1209&PID_DADA&MI_00\7&11b12b6d&0&0000 was not migrated due to partial or ambiguous match.
Last Device Instance Id: USB\VID_047F&PID_C008&MI_00\6&13deb44e&0&0000
Class Guid: {4d36e96c-e325-11ce-bfc1-08002be10318}
Location Path:
Migration Rank: 0xF000FFFF0000F120
Present: false
Status: 0xC0000719
It turns out that Windows’ USB audio driver has error logs, but you can only read them if you are using USB Audio 2. If you are using USB Audio 1 the driver produces logs that MS can only read internally. https://twitter.com/mvaneerde/status/1320034391003852800
ONnnne more update: I don’t know why I didn’t try this earlier, but I plugged in to a mac and it worked (rebeltech.org “patches” WebMIDI app was able to connect) on the first try. So this is good because my bootloader problems seem to be resolved, since I should now be able to force into bootloader mode using the mac. However, I think it is still worth debugging the Win10 problem as OWL/Magus ought to be able to support Win10.
I will test “USB host” (IE plugging MIDI keyboard into Magus via USB) once I’ve screwed the device back together…
Ok, well the same device ID could be reused by different vendor in this case. The point, it’s not belonging to Magus, so the issue is likely related to switching USB audio devices.
As for enabling audio channels, this in hardware.h should do the trick:
#define USB_AUDIO_CHANNELS 2
I think you won’t be able to use it with main OwlProgram branch yet, but worth testing if that resolve the device migration issue.
Hm, OK. I don’t think I have any Plantronics devices. Possibly one of my other audio devices is reporting itself as Plantronics. My audio output is usually set to my LG monitor.
I have performed several tests. Note these are separate from the problems with using Magus as a USB Device with Win10 I described above. All tests were done with git:d6c58cf8ec6126 MidiBoot + Magus, with IWDG.
Test 1: Unit back unscrewed, plugged in to Win10 machine through USB hub. Patch selected: https://www.rebeltech.org/patch-library/patch/YM2413_Synth
Result: Plugged in Korg microKEY Air to Magus port labeled “Usb Host”. Playing keys had no impact on the patch. The Korg appeared to not be receiving power (arpmode button did not light when pressed).
Test 2: Unit back screwed in, plugged in to Win10 machine through USB hub. Patch selected: https://www.rebeltech.org/patch-library/patch/AndiSaw4
Result: USB “freaked out”. Windows 10 reported several devices (Rift headset) had lost connectivity, the magus screen flickered, the monitor flickered (probably caused by Rift disconnection), and other devices plugged into the hub (mouse) lost connectivity. Exact same symptoms as my Oct 12 post when I had plugged the white board in to the wrong pins. Tried again-- this time it ran for about 3 seconds, then the flickers and USB problems happened again. Rebooting did not restore USB functionality. Unplugging the hub and plugging it back in did restore functionality (IE my mouse and hub are not damaged).
Test 3: Plugged Magus in to wall outlet using DC power. Patch selected: https://www.rebeltech.org/patch-library/patch/AndiSaw4
Result: Plugged in Korg microKEY Air to Magus port labeled “Usb Host”. Playing keys had no impact on the patch. The Korg appeared to not be receiving power (arpmode button did not light when pressed).
Conclusions:
d6c58cf8ec6126. It does not even appear to be supplying power.Unless y’all think Test 2 is “suspicious” and something dangerous may be happening, I can try again with the hub power plugged in to see if the USB freakout recurs.
I will try the USB_AUDIO_CHANNELS test tonight or tomorrow.
Here’s the “final” version of my tutorial (in that, I’ve now followed all the steps and they work… at least to the point above)
@mars, would you be willing to link this from Tutorials – Rebel Technology ? It might be helpful to someone.
Also, I’d wonder:
Got to test current code on Daisy with a Windows laptop, result was getting a “Driver error” from OS. Same thing after reconfiguring it to create 2 audio channels. I guess it’s better than straight BSOD, but still not very good.
Since you have performed the Windows test with USB_AUDIO_CHANNELS I will not attempt to perform it then (unless one of you tells me it would be useful).
I managed to get into a conversation with someone on “Twitter” from Windows’s USB Audio team yesterday, he asked me to send him a log of the connection failure event. He looked at it using the MS internal log decoder and says that inside the log he found:
I was able to decode the usbaudio.sys logs and found “USBHwLogStartFailure - Could not Select a device configuration, 0xc0000182(STATUS_DEVICE_CONFIGURATION_ERROR)”
Does this help any?
Note: The problem on Win10 with the USB hub and USB “freaking out” I described above was NOT the fault of OWL/Magus. I was able to reproduce it just now just by plugging in too many non-OWL devices to the hub. It was just a problem with the hub exceeding its power abilities.
On more update…
Because I could not get the USB “host” port to work with git:d6c58cf8ec6126, but I could not get v20.7 to work with IWDG, I tried arbitrarily selecting git:732ceac17cb, a commit from just before the IRQ changes, and building that, to verify my USB “host” port was not fried. (My tests with v20.7 had only verified the USB “client” port). Building this required doing the IOC file “generate” step and also merging in svin PR commit a447765258d9.
I can report that
732ceac17cb the USB “host” port worked fine.732ceac17cb I did not experience the MIDI dropouts I had been experiencing before.So… my Magus now works the way I want it to!! I can install custom firmware via the web page, and I can use MIDI devices, and the knobs behave correctly!! So that is great!! However, USB “host” is broken in d6c58cf8ec6126.
EDIT: USB “client” will not talk to Windows in 732ceac17cb. It gives me the same error icon in Device manager that d6c58cf8ec6126 does. However, this is not a blocker for me using the Magus day to day because it will still talk happily to my Macintosh.