I have migrated MIDIbox FM V2.0 from the LPC17 core to the STM32F4 core and re-christened it “MIDIbox FM V2.1”. Everything went more smoothly than I was expecting, but I’ve run into one strange problem. FYI, MIDIbox FM V2.x is a copy of MIDIbox NG, with an extra module driver for the OPL3 module, a bunch of custom code for the synth engine, and some additions to mbng_file_c and so forth to support the new configuration options. When I ported it, I used the latest version of MIDIbox NG, and copied my edits into that. Everything else seems to work fine, from OPL3 control to loading patches from the SD card.
The problem I have is that when the USB cable is connected to my computer, but MIOS Studio isn’t running and connected to the synth, the synth hangs whenever there would be a debug message sent to MIOS Studio. If I open MIOS Studio, the debug message gets through and the synth immediately starts working again. If the USB cable was not connected when the synth powers up, the synth works fine forever. Once the USB cable is connected to the computer, on the next debug message the synth hangs again. If the USB cable is disconnected while the synth is on, it also hangs on the next debug message.
It seems like the core is dynamically picking which port to send debug messages to, and defaulting to USB (which is good). But it also seems that, only if it’s using USB, it blocks until it receives an acknowledgement of its message. I’m not sure if this acknowledgement comes from the OS or MIOS Studio, but I think it’s the latter, because if I have another program open that connects to the synth but not MIOS Studio, the synth still hangs. Do you have any idea what could be going on?
I haven’t messed with any debug port allocation code from MIDIbox NG, so I would imagine that this problem exists there too–however, it might be hard to test, because I’m not sure if the default MIDIbox NG sends any debug messages unless requested to by MIOS Studio, and because MIDIbox NG controllers are intended to be USB powered, so they would never be running while disconnected from USB!
Are you working under Windows, and does the application enable more than 1 USB port?
Then this is a known (Windows related) problem, and MIOS Studio has a workaround to overcome this (it sends a lot of dummy messages to the core until it unlocks the communication).
Workaround: enable the “single_usb” option with the bootloader update app, and power-cycle the core so that Windows takes over this single port configuration.
No, I’m using Linux (Ubuntu 14.04 64-bit), and I did not have this problem (with the same OS) when using the LPC17 core. In fact I didn’t have that problem in Windows either with the LPC17 core, and I’ve always had the default four USB ports.
Now testing the app with Windows 7 64-bit, it behaves almost the same as in Linux, except that the synth un-hangs itself whenever the USB cable is plugged in again, even without connecting it to MIOS Studio.
I will try setting the single_usb option tomorrow and see how it reacts in both OSes. Still, it seems strange that the synth should hang if there’s something wrong with the OS enumerating the USB device–it might mean USB does not work, but it shouldn’t block on a high-priority thread like that. (MIDI receiving, MBNG event handling, and background tasks [updating the OPL3] get interrupted, but scanning DOUT continues to work, since the LED matrices continue to appear correctly.)
It’s new to me that it also exists under Linux, you are the first guy who reports this.
It’s also new to me, since I was using (nearly) the same app with the exact same OS on a different core and it worked fine. Maybe I did mess something up? I had to go through and delete all references to the SCS, since the OPL3 module uses J10A/B for a parallel connection, and I know there was a bunch of stuff in app.c that referenced it, I may have commented out some things I shouldn’t have. I’ll take a look there as well as try single_usb.
It’s always a good idea to try out one of the prebuilt binaries which can be downloaded from http://www.ucapps.de/mios32_download.html such as MBSEQ, MBNG, MIDIO128.
These apps are some kind of reference, because they have been tested at my side (with different operating systems and with different computers) and they are used by multiple people who haven’t reported such problems yet.
All these applications output debugging messages after power-on (-> this is no exotic case)
That’s actually also the reason why I think that the problem is located somewhere in your application, and not in MIOS32 itself.
There are a number of jumpers on the STMDISCOVERY module itself, was I supposed to change them? It’s being powered by an internal PSU so I removed “USB Power”, but other than that I didn’t change anything.
Could there be a problem with the BSL_Hold jumper/button? When does it check to see if that is set?
I hope that I found & fixed the issue (-> update your repository)
You did! It works like a charm now. USB cable plugged or unplugged, one or four USB “devices”. Thanks so much for the quick fix!
Speaking of updated versions of old MIDIboxes, I see someone has been very active on the MIDIbox SID V3 front… You’re not running JUCE on the core, are you?!
MBSID: project is still in hypersleep mode, I just migrated the AU and VST to a newer Juce version in the hope that it works more robust, but the VST still seems to be unstable - nothing for a public release, going into sleep mode again
You’re not running JUCE on the core, are you?!
