USB Host support for MBHP_CORE_STM32F4

[TK.]

This was a nice challenge for the weekend: I implemented a driver for USB MIDI Host mode into MIOS32 for STM32F4 :smile:
(LPC17 and STM32F103 don't support USB Host mode...)
 
Tested with following devices:
CME X-Key:


Waldorf Blofeld:


MIDIbox (here MIDIbox SEQ V4L):


Ploytec GM5x5x5


USB MIDI Host mode just replaces USB MIDI Device mode via the USB OTG socket.
The update will be available with all future MIOS32 applications, it's always available without special configuration.

A special USB Micro-B -> USB 2.0-A adapter is required to connect the MIDI device.
 
Such an adapter is for example available at Reichelt (DELOCK 83183) for 5 EUR:
http://www.reichelt.de/DELOCK-83183/3/index.html?&ACTION=3&LA=446&ARTICLE=126860&artnr=DELOCK+83183&SEARCH=DELOCK+83183
 
Pluck this adapter into the Micro-USB socket of the STM32F4-Discovery board, reset (or power-cycle) the core, and MIOS32 will automatically switch to USB Host mode.
 
 
Limitations:
- USB hubs are not supported, the MIDI device has to be connected directly.
- USB based Power-Supply is weak (limited to ca. 200..300 mA), which means that it might be required to power the MIDI Device with an external PSU
- the MBHP_CORE_STM32F4 module has to be powered from the USB debug socket
 
Please let me know if you are interested to beta-test this enhancement, I could provide a preliminary version of a MIOS32 application.
 
Best Regards, Thorsten

[Shuriken]

Cool, does GM5 also work?

[BEBDigitalAudio]

Absolutely great work Thorsten !!!

I think that it will work without problems with the GM5, since the GM5 is class compliant (like the XKey). Basically, 90% of MIDI devices should work with that (the 10% remaining devices requiring proprietary USB drivers, especially the MOTU or Behringer devices...)

Edited July 6, 2014 by BEBDigitalAudio

[TK.]

It was an interesting experiment anyhow.
 
Yes, of course it works :smile:
 
But if the STM32F4 Discovery board is powered by the Debug USB Socket, the Micro-USB will only output ca. 4.3V which is not enough for the GM5
 
Solution: plug a 5V PSU to J2 of the MBHP_CORE_STM32F4 module, and let the USB PWR jumper J17 stuffed:


 

All 5 MIDI IOs of the GM5 are recognized, and can be used for MIDI message processing.

 

Best Regards, Thorsten.

[mono]

looks very interesting to me! normally i would volunteer as a beta-tester, but unfortunately i havent got the usb-cable (yet). but if you want, you can send me already the beta-mios32 and then i have a reason to get one. excellent work! :D

[TK.]

Since you know how to build MIOS32 applications by yourself, it's sufficient to update the SVN snapshot :)

 

Best Regards, Thorsten.

[mono]

thanks tk, have done that! btw. even found a cable. its a usb-otg cable, which i bought for my nexus7. i think it will work with that. photo is attached...:D

[Shuriken]

thanks tk, have done that! btw. even found a cable. its a usb-otg cable, which i bought for my nexus7. i think it will work with that. photo is attached... :D

Yeah, that cable should do the trick.

[sneakthief]

This is really, really great. I'll test it out with my Yamaha DTX-Multi 12 percussion and Virus Snow after I get an OTG cable.

[mono]

yeah! it does work with my m-audio axiom25. power from the usb-port is not enough for that, so it will need an external power supply, but yes it works. the only problem is, that you cant use the usb-port for mios-studio anymore, because, windows cant detect it as a mios32-device, but i guess this is normal...

[TK.]

the only problem is, that you cant use the usb-port for mios-studio anymore, because, windows cant detect it as a mios32-device, but i guess this is normal...

 

Yes and no.

 

Yes: a code upload won't be possible, because the Bootloader doesn't support USB Host (not enough memory available in the 16k boot section)

 

No: MIOS Studio contacts the core via SysEx messages, which should also be possible via a USB device which is connected to your PC/Mac via another MIDI interface.

 

I just tried following setup:

- MBHP_CORE_STM32 USB connected to a GM5x5x5

- MIDI IN1/OUT1 of the GM5x5x5 connected to MIDI OUT1/IN1 of a second GM5x5x5

- the second GM5x5x5 is connected to my Mac

 

After a robustness update in the MIOS32 USB MIDI Host driver a Query and terminal access are possible! :smile:

 

Please update your repository to get the changes

 

Best Regards, Thorsten.

[mono]

ok, that seems to work! have re-compiled the bootloader-update-application. it runs in usb-host-mode and it works in the terminal via a 2nd midi-interface.

unfortunately the behringer bcr2000 is my only usb-midi-interface and it doesnt allow me to transfer sysex for the code-upload. when uploading code mios studio says: "Bootloader mode cannot be entered". looks like i need another usb-midi-interface for that..:-(

 

also i noticed that compiling with #define MIOS32_DONT_USE_USB_HOST in mios32_config.h doesnt work. the application will still be compiled for usb-host-mode.

 

kind regards,

mOnO

[TK.]

As mentioned before, USB host mode doesn't fit into the 16k bootloader range, there is no need to try this out - it won't work.

Accordingly, code upload via USB host won't work as well.

 

Bootloader update application != bootloader.

 

So: whenever you want to upload code via MIDI, you've to connect the STM32F4 USB port directly to your PC

 

Best Regards, Thorsten.

 

P.S.: I just have improved the MIOS32_DONT_USE_USB_HOST switch, so that it excludes parts of the STM32F4 driver - bootloader should fit into memory again (with support for USB MIDI Device mode only...)

 

[niklasni1]

This is a great improvement, hope to try it out soon.

[mono]

thanks for clarification! have updated my svn and re-compiled the bootloader-update-application. gcc gives now 2 warnings in usbd_req.c, but it compiles anyway. i do need that application, because after uploading a program in usb-host-mode, i have no access with mios-studio anymore, as mentioned before. the only workaround is to re-flash the bootloader with the st-link-utility, which obviously deletes all my mios-parameters. for that i need the bootloader-update-application. im using 2xdogm-graphic-lcd on my stm32f4-board, so without that i cant see anything on my displays. but when compiling the update-application with the MIOS32_DONT_USE_USB_HOST switch it still doesnt do that. have managed to change the mios-lcd-parameters after uploading the application, so it seems to work somehow, but after a storing and reseting i cant connect to mios-studio anymore...

 

kind regards,

mOnO

[TK.]

You can't upload a program in USB Host mode, because the upload takes place in the bootloader!

 

Upload process:

- MIOS Studio requests a reset, so that the bootloader will be started

- Once the bootloader replied (which again can't work in host mode), MIOS Studio starts to upload the code

 

Hope that this clarifies the reason why it doesn't make much sense to continue on this topic...

 

While I developed the USB host mode, I always uploaded the application via USB MIDI in Device mode.

 

It wasn't a big deal to:

- remove the USB host cable

- plug-in the USB device cable

- press the black reset button so that MIOS32 reboots in device mode

- press the upload button in MIOS Studio.

 

Of course, under MacOS I've the big advantage that I don't need to restart MIOS Studio when the USB MIDI Device was temporary not available.

If you are working under Windows, it might be required to restart MIOS Studio...

Alternatively you could initiate the upload from the command line (see "mios_studio --help") to automate this.

 

Or consider to develop your application without a USB Host connection, find another way to connect your MIDI device during the implementation phase, and use it only when you are not working with a computer (e.g. while making music... ;-)

 

Best Regards, Thorsten.

[mono]

finally i got it! seems like the usb works much better on MacOS than on windows (like it is with other stuffl..). but i did exactly the same as you have described. after the reset, you have to restart mios-studio on windows, which is normal, and than the mios32-device disappeared in mios-studio. as my last resort i decided to re-install the mios32-driver and now it works a treat!

 

i know, sometimes it can get a bit annoying to describe something, especially, if we have 2 different operating systems, but we definetely have excluded all the options to get it to run under windows. hope that will help others, who may come across the same problem and many thanks for your patience anyway...

 

kind regards,

mOnO

[stuartm]

Just discovered this topic while I thought "maybe TK can implement USB MIDI host on the new Core board"  - he already has!

 

I've been looking for a way to integrate the Korg NanoKontrol with the Octatrack and other MIDI gear and didn't want to spend 100EUR on a Kenton MIDI USB host.

 

Got to get that STM32F4 core now - you'll likely get another Beta tester :-)

[TK.]

Cool! :)

I've released a new version of the usb_midi_2x2 and usb_midi_4x4 application which supports the USB MIDI host mode. It's the most simple application for this purpose.

 

Best Regards, Thorsten.

[BlueXav]

Hello  Thorsten !

I'm very happy you made that USB host midi driver ! I've tried to write one which is roughly working and that I use in my Dekrispator machine (http://youtu.be/fcLrcDCaI7w)...but I have some disconnection problems.

At the moment I'm a newbie with your MIOS32 concept,

however I've managed to compile MIOS Studio on my Debian 7.4 Linux PC and compiled your usb_midi_2x2 (SVN) with Eclipse Kepler and the GNU ARM tool chain.

 

But no luck, I can't make my stand-alone Discovery board work in Host mode : neither with Korg Nanokontrol (v1) nor Roland UM-2G.

I've uploaded on the board my compiled application and your binary too (v1.10).

The green vbus led (led7) flashes once and remains off.

It works in device mode when connected to the PC as I see in MIOS studio.

Any idea ?

Sincerely, Xavier

[TK.]

Hi Xavier,

 

welcome on board! :smile:

 

I just have doublechecked the usb_midi_2x2 application, it's working with various USB MIDI devices.

 

Debugging: in this application the green LED should flicker whenever a MIDI event is received or sent, regardless from which MIDI port.

Use it to check if your USB MIDI device sends messages, and that you are able to receive messages from a MIDI IN or OUT port.

 

If this doesn't work, you could recompile the application with:

#define MIOS32_MIDI_USBH_DEBUG 1

added to the mios32_config.h file

 

This will enable some debug messages in mios32_usb.c which are sent to the MIDI OUT1 port and can be displayed by the MIOS Studio terminal.

E.g. you should see a notification about the USB MIDI Device name, manufacturer, ID when the device is plugged in.

 

Best Regards, Thorsten.

[BlueXav]

Thank you very much for your answer.

The strange thing is that the midi device is not even powered by the STM32F4 board.

It's like the host mode was not enabled here, maybe a configuration problem ?

I have not a MIDI_IO board for debugging on another port...

Xavier

[TK.]

Are you using the MBHP_CORE_STM32F4 module, or a bare STM32F4DISCOVERY board?

 

STM32F4DISCOVERY: you've to bridge the PA9 pin to the 5V input with a short cable:

http://www.ucapps.de/mbhp/mbhp_core_stm32f4_standalone.jpg

 

If MBHP_CORE_STM32F4 module: you've to stuff a jumper at J17

 

Best Regards, Thorsten.

[BlueXav]

Oh great great great ! It works now ! Thank you Thorsten !

It was just the cable problem... (I have the stand alone Discovery board)

I was just on the point of giving up !

So, with OTG mode  can't you switch on the USB Vbus ? There is a pin (PC0) called OTG_FS_PowerSwitchOn for this.

I've also made a simple MIDI out port but that remained quiet with the no power issue.

 

I was also confused about the UART0 / UART1 namings :

UART0 out <-> PA2 (USART2)

UART1 out <-> PD8 (USART3)

 

Anyway it works with the NanoKontrol V1 and Roland UM-2G.

When I'll have time I'll try to transpose my Dekrispator on MIOS32...

Thank you for that excellent and monumental MIOS32 !

 

Xavier

[TK.]

Great that you got it working, looking forward for playing around with your synth app! :-)

I gave you access to the Programmers Lounge where you can find more informations about the projects.

 

 

VBUS: this is what I copy&pasted from the STM32F4 implementation example into mios32_midi.c - it seems that external components are required:

 

void USB_OTG_BSP_DriveVBUS(USB_OTG_CORE_HANDLE *pdev, uint8_t state)
{
#ifndef MIOS32_DONT_USE_USB_HOST
  /*
  On-chip 5 V VBUS generation is not supported. For this reason, a charge pump 
  or, if 5 V are available on the application board, a basic power switch, must 
  be added externally to drive the 5 V VBUS line. The external charge pump can 
  be driven by any GPIO output. When the application decides to power on VBUS 
  using the chosen GPIO, it must also set the port power bit in the host port 
  control and status register (PPWR bit in OTG_FS_HPRT).
  
  Bit 12 PPWR: Port power
  The application uses this field to control power to this port, and the core 
  clears this bit on an overcurrent condition.
  */
  if (0 == state)
  { 
    /* DISABLE is needed on output of the Power Switch */
    GPIO_SetBits(GPIOC, GPIO_Pin_0);
  }
  else
  {
    /*ENABLE the Power Switch by driving the Enable LOW */
    GPIO_ResetBits(GPIOC, GPIO_Pin_0);
  }
#endif
}

 

UART (MIDI port) assignments: I can't use STM32F4 USART0 and USART1 because the appr. pins are allocated by other functions.

Therefore the MIOS32 specific UART0..3 mappings don't match with the hardware indices.

 

MIOS32 UART2 I even had to use two different USARTS for IN and OUT.

See also http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fmios32%2FSTM32F4xx%2Fmios32_uart.c

 

Best Regards, Thorsten.