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?
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.
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?
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!
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?
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…
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?
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:
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?
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?
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.
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…
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:
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.
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.
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.
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!
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?
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.
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.
