Jump to content

Waiting for response from MIOS Studio?


Sauraen
 Share

Recommended Posts

Hi TK,

 

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!

 

Thanks,

Sauraen

Link to comment
Share on other sites

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.

 

Best Regards, Thorsten.

Link to comment
Share on other sites

Hi TK,

 

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.)

 

Thanks,

Sauraen

Edited by Sauraen
Link to comment
Share on other sites

but it shouldn't block on a high-priority thread like that. (MIDI receiving, MBNG event handling

 

Of course, and this is the reason why I added a timeout loop into MIOS32_USB_MIDI_PackageSend() some years ago, which works reliable.

 

I spent an immense (!) effort to reverse-engineer the issue which users only noticed under Windows so far.

I used several methods (such as trace points in MIOS32, USB sniffer, different implementation methods, etc) to get more informations about the issue.

Believe me (or not) but I think that the problem is at the OS side.

 

It's new to me that it also exists under Linux, you are the first guy who reports this.

 

Best Regards, Thorsten.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

 

Best Regards, Thorsten.

Link to comment
Share on other sites

It appears to be a hardware problem, or else some recently-introduced bug in all of MIOS32.

 

I set it to single_usb, no change in behavior. (I've been testing entirely with Linux now, since that's where I have the toolchain set up.)

 

I uploaded the bootloader update app, and noticed that app behaves the same way. If the USB cable is connected, when the synth powers on, it says "Bootloader Updater / © 2014 T.Klose", and sits there forever until I open MIOS Studio, at which point is checks the bootloader and says "Bootloader is up-to-date! :)". I had compiled it myself, so I thought I might have accidentally changed something in the MIOS32 source, so I downloaded the prebuilt MIDIbox NG, and this gives the same behavior. If the synth starts up with the USB cable unplugged, it says "MIDIbox NG V1 / © 2014 T. Klose" and after a second runs the NGC script and shows other text on the screen as it should. But if the USB cable is plugged in, it stays on the splash screen forever until I open MIOS Studio, at which point it continues.

 

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?

Link to comment
Share on other sites

I hope that I found & fixed the issue (-> update your repository)

 

It's related to a bug in the STM32F4 driver as described here: https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy%2est%2ecom%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex%5fmx%5fstm32%2fYet%20another%20STM32F1057%20USB%20OTG%20driver%20issue%20%28VCP%20device%29&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=2734

 

I was only able to reproduce it with my 10 years old Linux laptop, and even there it didn't always happen, but only sporadically.

Therefore I hope that this helps at your side - otherwise I've to give you some hints how to continue debugging (requires a scope to monitor the IRQs)

 

Best Regards, Thorsten.

Link to comment
Share on other sites

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... :P You're not running JUCE on the core, are you?!

Link to comment
Share on other sites

Great that this fix solved the problem! :smile:

 

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 ;)

 

Best Regards, Thorsten.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...