Goom STM32F4 USB Problems

MIDIbox User Projects
, ,
1

Hi All,

I hope this is considered the correct part of the forum for this. I am a novice midi to MIDI and a general tinkerer. Not much of a musician either…

I saw the Goom Synth build on the STM32F4 and thought it looked like good cheap fun. I have managed to procure the board, install MIOS32 and upload the synth “project.hex” without too much stress.

I don’t have a good way of playing the synth (no keyboard ATM) so long term I wanted to try using an old Motorola Xoom as a touch interface, similar to “ttfshtt” or “AVLG”. Currently I have managed to connect to the tablet using the Cntrlr interface created by “Synthy” (for which I am very grateful) on both Win7 & Ubuntu Studio.

All the above was done with two USB cables attached which is a bit of a pain, so I tried the PA9 to 5V trick. Although the board appears to power up, I don’t get the pulsing LED LD4, and LD1 (Com) flashes instead of being solid red. By accident I have just discovered that if I plug in CN1 temporarily whilst CN5 and the jumper are in place, I can get the board to boot.

Interestingly, it is more complex than just getting power on the CN1. If I plug the board into USB power block  whilst connected to my laptop on CN5, it won’t boot. I needs a laptop USB to trigger the board (hope that makes sense).

Has anyone experienced this and have a cure? it is a pain at the moment, and I would like to try playing with MIDI commander on either my Samsung Galaxy, or Motorola Xoom as a control interface. (currently I have managed to at least see the Goom in MIDI commander with my Galaxy and a USB OTG cable).

The board I bought from Farnell is the “STM32F407G-DISC1” which seems to be an updated (but I can’t tell how) version of the STM32F407.

Any thoughts appreciated.

 

2

First of all, Welcome :slight_smile: Good to have you here.

I’m not really the best to answer your question, but I’ll try. As I understand, CN5 can power the board via a USB source( via the PA9 to +5V jumper) when the STM is in Device mode but you need to supply power from an external source when CN5 is in Host mode, as the STM board will try to supply power to the Device that connects to it. Not sure about your tablet/pad, does it connect to the STM as a Device or a Host? Does the STM show up/boot when plugged into a laptop, powered via CN5?

EDIT: I see you tried using a USB wall wart on CN1, Did you try power block to CN1 without the PA9-to-+5V jumper? See J2 and J17 on

http://ucapps.de/mbhp/mbhp_core_stm32f4.pdf

I hope someone will have a better answer, but I would try setting up an external +5V source to J2 such as noted on the MB CORE_STM32F4 page

http://ucapps.de/mbhp_core_stm32f4.html

A wall wart from a USB hub should work as long as it is rated at +5V @ 500mA, a higher amperage would be ok but it must be +5V. Be sure on the polarization when connecting, double check with a multimeter. Or you may try finding a ‘USB charger’ wall wart with the mini-USB connector for CN1 to supply the board.

Yogi

 

 

3

Hi Yogi

Thanks for the pointers, I’ll let you know how I get on. I’ve been too busy to touch this, hopefully the weekend will allow. 

My tablet use is with a USB on the go cable so the tablet acts as a host. So in theory it should run the goom off CN5 no problem. I can’t get the board to run off a laptop with only CN5 either (normal cables).  I have to briefly connect to CN1 (with the jumper place) and on removal of CN1 it will run off CN5 only. 

Roll on the weekend. 

4

Just another thought. Your USB  OTG cable, does it have two microUSB plugs? If that is the case then it’s a A/B cable, meaning that one end is a A plug and the other is a B plug, and either will plug into a microUSB socket. The type of plug that is inserted into a OTG socket signals the device which mode it should run as. So if you plug in the B end on the STM it will assume the Device mode but if you connect the A end the STM will run as a Host. The microUSB cables I have (not OTG types) are marked “B” in the plastic, so a proper A/B cable will probably be clearly marked also.

Yogi

5

hi; i have the same problem with the new stm32f407G discovery; it's installed on a ``CORE_STM``32``F``4 module and i'm running a build of the cv_v2 application.

ST-link utility workes good: i can flash the bootloader; ``LCD shows bootloade``r is up.

I then use the micro usb to install te midibox_cv_v2 app ``with mios studio``: all works fine; osx recognizes the midibox cv midi ports.

when i then power off and connect only with micro usb (and jumper J17) the application doesn’t start; the oleds (that worked before) stay off and osx doesn’t see the midi ports. (The LCD shows black blocks but that may be a different issue)

When I then also re-connect the mini usb cable to the pc wich ran the ST-link utility the application starts oleds turn on, osx recognizes the midi ports. Then if I remove the mini usb, the application stays up.

I just cannot boot up with micro-usb only.

I googled & found this forum discussion which seems about the same issue (concerning the new STM32F407G module)

http://electronics.stackexchange.com/questions/221895/stm32f407g-disc1-not-working-if-not-connected-to-pc

Basically someone has similar problems with the new STM32F407GDISC board, before he used the old discovery board without problems.

A guy answers that he “fixed” the problem by soldering a jumper (SB10) on the back of the pcb ; he says “SB10 forces the ST-link mcu in reset state.” but then warns that you can’t use the st-link utility anymore.

So I checked the datasheet of the new STM32F407GDISC.

http://www.st.com/st-web-ui/static/active/cn/resource/technical/document/user_manual/DM00039084.pdf

It says the 407G has a new ST-LINK >> ST-linkV2-A (Old one of the STM32F4DISCOVERY board was ST-linkV2).

It then talks about a limitation of the new version:

 _ Known limitation: _

  • Activating the readout protection on ST-LINK/V2-A target, prevents the targetapplication from running afterwards. The target readout protection must be kept disabled on ST-LINK/V2-A boards.  

So I guessed this might be the cause of the problem, I did a bit of searching but couldn’t find anything about it.

Anybody knows what to do?

Cheers, marcel

 

6

Hi Marcel & Yogi,

Firstly, apologies Yogi for the slow reply. I meant to reply to say the USB OTG cable is a bit of a red herring. I have the same issue with any cable and the computer.

Marcel, well done, you have found the answer I think. With your lead I did a search and found the link below:

http://searchingforbit.blogspot.co.uk/2012/03/stm32f4discovery-eval-board-with.html

So this guy is commenting on the problem for a completely unrelated application. I have had a moment to try this tonight and I find that with a USB cable on CN5 plugged in to my laptop and if i short SB10, the board boots into the MidiOS and I can get sound out of the Goom with the Ctrlr app (on a Win7 laptop).

I don’t have a core board, but I would imagine that if you either solder a jumper on the board as the link above (which I think I will), solder across the link or you solder a push-to-contact switch on that jumper you will be able to boot the board at will (without the second USB cable). I would note, that for me at least, if you boot the board without the second USB cable & jumper SB10 the LED LD1 will flash rather than turn on solid. The board will still boot properly and LD4 pulses as it should.

Thanks again Marcel, you just made this a bit more fun and now I can start to play a bit more with this board. I might have a go at a core board too.

If I was a cynic, I would suggest that ST saw how much fun people were having, and decided to make things more difficult for everyone.

Best regards.

7

Very good that you found the problem’s solution, seems this answers some of the questions that have been asked as to the changes between the older 'F4 DISCOVERY and the newer 'F407 DISCOVERY boards. This will be of interest to the whole community for all new builds :slight_smile:

Yogi

8

Instead of soldering jumpers etc., try upgrading the “bootloader” firmware to LINK007. This solves the issue of the STM32F407 chip being held in reset when the mini USB isn’t plugged in.