STM32F4 communication issues with MIOS Studio: no USB-MIDI available

[smaudio]

Hi everyone,

 

I have a strange problem with my STM32F4 Discovery not being able to communicate with MIOS studio.

 

I flash the STM32F4 with the mios32 bootloader no issues via ST link, but then if I reboot the core and connect through the left Micro-USB, the USB MIDI driver doesn't come up on either windows or macOS (so I can't connect it to MIOS studio). If I boot the core in boot hold mode, the USB-MIDI driver comes up on both Mavericks or Win7 (MIOS bootloader) the core gets recognised and can upload an application (ID=0), but when I then upload midibox_seq_v4_086 and reboot, even though it works on the displays of my MbSeq4, no USB Midi drivers again in either Win7 or Mavericks.

 

To test further, through boot hold mode I uploaded midio128_v3_019, reboot, and the drivers do come up and I can use the terminal, but I get 'No response from MIOS8 or MIOS32 core' (I've checked with all Device ID values, none works). If I now try to upload midibox_seq_v4_086 I get the 'Warning: no reponse from the core' message half way through and the core doesn't seem to send an upload request after booting.

 

I have done this when the STM32f4 Discovery board is not connected with the MBHP_CORE_STM32F4 module and it exhibits the same behaviour.

 

Is this midibox_seq_v4_086 messing up the USB midi drivers somehow? 

Or perhaps some residual code somewhere if it connects under boot hold?

 

Any help is much appreciated!

[TK.]

Hi,

 

very strange, especially since this even happens under MacOS (which is the least problematic OS with the most robust MIDI drivers)

 

Could you please doublecheck that you are using the right STM32F4DISCOVERY module?

There is a downstripped version available with a similar name and pinout, but it's only stuffed with a STM32F401

You need a STM32F4DISCOVERY board with STM32F407

 

> Or perhaps some residual code somewhere if it connects under boot hold?

 

No... only difference: it's a separate USB MIDI driver without USB Host support, and it's located in the first flash sector which also exists in the STM32F401 - therefore the assumption above.

 

Best Regards, Thorsten.

[smaudio]

Hi Thorsten,

 

Many thanks for looking into this (and for all the awesome projects)!

 

I do appear to have a STM32F407 core on the STM32F4 Discovery board (STM32F407VGT6 MCU 168 MHz/210 DMIPS), so no luck there.. 

 

I should also say that when I flashed the core for the very first time on my PC, I did get the 'good' USB host showing up as 'MIOS' and everything seemed to work as planned (and I've been able to achieve this once again after flashing), but the host just stopped working somehow after I power-cycled again :(

 

Other than that I don't know what else it could be.. it's very strange. Perhaps it's my STM32F4 then and I need a new one?

[TK.]

I don't think that you need a new STM32F4.

 

It would be interesting if you still notice the same issue under MacOS.

Please use one of my latest prebuilt binaries for reference, e.g. this one: http://www.ucapps.de/mios32/midibox_ng_v1_032_pre4.zip

You can upload the .hex file directly with the ST Link tool (under Windows) - it contains the bootloader + the MIDIbox NG application.

 

If no success: we should continue the troubleshooting under MacOS (I will give you further instructions in this case)

 

If success: try also under Windows.

If the USB device is not recognized, you could uninstall the MIDI driver assigned to the USB port somewhere in the system settings, and re-connect the USB cable. This enforces a driver re-installation which might help.

 

Btw.: did you already try another USB cable?

I remember that there a Micro-USB cables which are only intended to supply power, e.g. for recharging mobile phones. They can't be used for the USB connection itself!

 

Best Regards, Thorsten.

[smaudio]

Thanks for that.. I successfully flashed the core with the midibox_ng_v1_032_pre4 STM324F/project.hex file through ST-Link 3.4.0 Win7, but I'm getting the same behaviour again: the Midibox NG app works fine on my MBSeq4 (READY.) but the drivers don't come up on either Win7 or Mavericks. Only the MIOS Bootloader driver comes up when I boot hold.

 

I tried to find the saved USB MIDI driver in my PC device manager, but I didn't seem to be able to find something that fits - I looked in the same place where the boot hold 'MIOS bootloader' driver comes up and anywhere else I could think of. On the mac I deleted the MIOS Bootloader (the only thing that comes up) to no avail.

 

I have used 2 different micro USB cables interchangingly, but I'm not sure they'd be just power cables as the boot hold MIOS bootloader seems to come up ok. I have tried everything both powering from ST-LINK or USB-MIDI (by stuffing the jumper on the module).

 

The only thing difference I've noticed from your instructions image is that the ST-LINK utility Memory display size used to be 0x020CE8 and now it is 0x4DAD8 (not 0x12700). Would this give any clues to what is wrong?

 

Many Thanks again

[TK.]

It's normal that the size has changed, because you've flashed a different (especially larger) .hex file.

 

Next steps under MacOS:

 

1) download the "USB Prober" app: http://www.ucapps.de/tmp/USB_Prober.zip

It will display the USB devices, the list will be automatically refreshed whenever something changed in the system.

Check if you can find the MIOS32 device in "normal mode", and when the bootloader is selected.

If the device is displayed in "normal" mode, but not recognized by MIOS Studio (means: no MIDI available), we will continue debugging with this tool.

 

2) try a MBSEQ release which is using an older USB device driver in MIOS32: http://www.ucapps.de/mios32/backup/midibox_seq_v4_083.zip

If this one is working, we've to continue debugging by setting certain options in MIOS32

 

Best Regards, Thorsten.

[smaudio]

Hi Thorsten,

 

1) the 'normal' driver didn't seem to appear in the list of USB sources here, only the bootloader driver when boot holding, so seems like the latest driver doesn't get transmitted at all from the core when in normal mode but....

 

2) some success!! the midibox_seq_v4_083 driver does display the USB driver ('MIDIbox SEQ 4') on both Win and Mac, and also the other 3 MIDI drivers ('MIDIIN2 (MIDIbox SEQ 4)','MIDIIN3 (MIDIbox SEQ 4)', 'MIDIIN4 (MIDIbox SEQ 4)' )! However, I'm still getting 'No response from MIOS8  or MIOS32 core' and it won't get the core details listed underneath. The core does send a f0 00 007e 32 00 0f 4d 4f 53 33 32 f7 message though every time I query.

 

So it seems like we need to configure the options in the new driver?

 

Many Thanks

[TK.]

Hi,

 

It seems that even with the old driver USB communication is failing, which indicates that something is wrong with the hardware.

 

E.g. the message which is sent by the core contains the "MIOS32" string as expected. MIOS Studio would thereafter request the board string, but it seems that the core doesn't respond anymore.

I never heard about a similar case in the past.

 

Next experiments:

 

3) keep the bootloader mode (don't depress the blue button after the reset has been triggered with the black button), restart MIOS Studio and select the USB MIDI interface of the bootloader. Then press Query again, does it work?

 

 

4) I also need to learn more about how you've built the core module.

Are you using the MBHP_CORE_STM32F4 PCB, or a selfbuilt version?

 

Experiment: unplug the STM32F4DISCOVERY board and connect the PA9 pin to the 5V input with a short cable like shown here:

 

Try the Query with the MBSEQ application - result?

 

Best Regards, Thorsten.

[smaudio]

3) Yes, the query has always worked without issues under bootloader mode, I get the core information and everything in the device info window as expected.

 

4) It's just a MBHP_CORE_STM32F4 PCB from SmashTV's shop that I've put together with the components from Reichelt

 

With the core working standalone like in your pic above, the same thing happens ('no response from MIOS8 or MIOS32 core..' in the device info box) however, I get information in the MIOS studio communication box underneath: Init DHCP, SD card not found, and when I type help in the command line, I get the welcome message and commands list, so it seems like the core communicates in normal mode, it just doesn't send the device info somehow...

[smaudio]

Here are some images from my core and MIOS studio to go with the points above too ;)

[TK.]

This case really puzzles me!

 

The MIOS Studio based MIDI IN/OUT monitor log was actually the most useful input, because it shows me that during the query STM32F4 responses with a delay of more than 1 second, which means that something really strange is going on in the application; actually the response should happen within 1..2 mS

 

Let's continue to check different applications, here some prebuilt ones:

http://www.ucapps.de/tmp/stm32f4_usb_test_files.zip

 

Please report your observations on all three .hex files.

(you can upload a .hex file in bootloader hold mode via MIOS Studio).

 

app_skeleton_r2023.hex: minimal application with the old USB MIDI driver

app_skeleton_unmodified.hex: minimal application with the new USB MIDI driver, USB Host and Device mode enabled

app_skeleton_without_usb_host.hex: minimal application with the new USB MIDI driver, only Device mode enabled

 

After the app has been started, just check the response by pusing the Query button, that's sufficient.

(the MIOS terminal won't work since it isn't supported by the application)

 

Best Regards, Thorsten.

[smaudio]

Thank you, here are the results:

 

app_skeleton_r2023.hex: works, query works and core info come up in the window (like in bootloader mode)
app_skeleton_unmodified.hex: loads without a warning, but after loading no USB driver comes up, and thus no communication can be achieved
app_skeleton_without_usb_host.hex: driver comes up and query works!

 

So do we deduce that there is something in the new USB host that messes up the communication in this core?

 

I have attached the result after loading app_skeleton_r2023.hex and 4 screenshots of the messages exchanged while loading app_skeleton_unmodified.hex, in case they are useful.

 

Best Regards

[TK.]

Thanks for testing!

 

Meanwhile I think that you are probably using a wrong Micro-USB cable, but I don't have enough experiences with the different cable types yet so that I'm not 100% sure.

 

The cable should show a B (for USB Device), and not A (for USB Host):

 

Do you see a B letter on your cable?

 

Independent from this, it seems to be possible to enforce B mode.

Probably this wednesday I could give you some new test applications (the mini-app and a MIDIbox SEQ build) which fakes the B type.

 

If this solves the issue, I will make it available as an option.

 

Best Regards, Thorsten.

[smaudio]

Hi TK, 

 

You're right, it seems that I'm using an A-type USB cable (it's got the letter A on it).. hm that'd be very interesting if that's the culprit. I've used another 2 cables but I don't know if they're type B as they haven't got a letter on them. Thanks for building the apps, if it's not easy to fake it in software, I can get a B cable later in the week and test it with that. 

 

Many Thanks :)

[TK.]

Great! :)

 

Let's try it step by step - I hope that with a minor modification it's already possible to fake a B cable:

 

http://www.ucapps.de/tmp/stm32f4_usb_test_files.zip

 

Try app_skeleton_enforced_usb_device.hex

 

If the query button is working with this version, try this MIDIbox SEQ release where device mode should be enforced as well:

http://www.ucapps.de/mios32/midibox_seq_v4_087_pre4.zip

 

Best Regards, Thorsten.

[smaudio]

Wow, Seems like we got a result!!

 

Here are the results:

app_skeleton_unmodified.hex: No drivers come up after upload and reboot.

app_skeleton_without_usb_host.hex: Works! Query works too :)

app_skeleton_enforced_usb_device.hex: Works! Query works too

app_skeleton_r2023.hex: Works! Query works too

 

midibox_seq_v4_087_pre4: Works like a Charm!

 

Thanks so much for all the work and for an awesome OS for the MBSeq, I played around v 4.084 yesterday for the first time and it's an awesome system. Have a beer on me, it's the least I can do!

[FelixSchoenstein]

I’m trying to get my F4 core working. I recompiled Tutorial 001 (after changing the path variables to STM32F4 values), and eventually got it loaded into the F4 (I’m not sure now whether it was with the USB or MIDI connection) with MIOS Studio 2.4.6 on the Macintosh.

 

Next, I tried the same thing with Tutorial 002. Now I’m getting “File contains invalid ranges for MIOS32 LPC17!†And it won’t load with either USB or MIDI. I wonder where the reference to LPC17 is coming from.

 

The when I try to reload the .hex file for Tutorial 001, I get the same invalid ranges message. I’ve gone through the suggestions offered to smaudio, but they don’t seem to apply to my situation. What should I do next to troubleshoot this issue?

[TK.]

Are you using the latest MIOS Studio release 2.4.6?

 

With this version the message should only appear if after the invocation of MIOS Studio the communication to a LPC17 core was successfully working, and thereafter you tried to connect to a STM32 core and the communication was failing.

 

Best Regards, Thorsten.

[FelixSchoenstein]

Are you using the latest MIOS Studio release 2.4.6?

Yes. And I believe the boot loader is version  V1.017 . Is that the latest one?

With this version the message should only appear if after the invocation of MIOS Studio the communication to a LPC17 core was successfully working, and thereafter you tried to connect to a STM32 core and the communication was failing.

That sort of figures. Because the only way I was able to load the new application was to try to load one that was not compiled for the F4 (but was for the LPC17). It only loaded partway and then stopped. After aborting that load, I was able to load the new .hex file. In the course of trying different things, I got an interesting variety of error messages. I didn't write all of them down, but I will do that if it will help to understand the difficulty.

[TK.]

Yes, V1.017 is the latest one.

 

Could you please try the following:

press & hold the blue button on the STM32F4DISCOVERY board, and then shortly trigger the black button (to reset the device)

Keep the blue button pressed! This enforces bootloader mode.

 

Now re-open MIOS Studio. Maybe you've to select a new MIDI IN/OUT device (but mostly the previous setting will work as well).

 

Check query (blue button still pressed) - does this work?

Upload a firmware (blue button still pressed) - does this work?

 

Release the blue button after firmware upload so that the application will be started.

 

Best Regards, Thorsten.

[FelixSchoenstein]

Hi Everyone: Thanks TK for the suggestions.

press & hold the blue button on the STM32F4DISCOVERY board, and then shortly trigger the black button (to reset the device)

Keep the blue button pressed! This enforces bootloader mode.

That happens OK when using the USB interface to MIOS Studio 2. However, with the MIDI interface, I get the following results:

Check query (blue button still pressed) - does this work?

No. The left panel shows "No response from core"

Upload a firmware (blue button still pressed) - does this work?

No. This message is returned: "WARNING: No response from core. Please reboot . . ."

Release the blue button after firmware upload so that the application will be started.

The previous program is started.