Problems running app on new STM32F407G-DISC1 pcb

[illogik]

Hi,

i replied to this discussion:

http://midibox.org/forums/topic/19987-goom-stm32f4-usb-problems/

but i guess the board is a better place for it? Maybe someone could move it here.

In short, the original poster and me both have similar problems with the new stm32f4 discovery pcb (STM32F407G-DISC1). The app will not run if only powered from micro usb; i think it has to do with a new ST-Link (ST-LINK V2A compared to the old ST-LINKV2)  that is on the newer boards. According to the datasheet the new ST-Link has a know 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.  

See the original thread for more details.

So is this an issue or are we doing something wrong?

thanks in advance,

marcel

 

[yogi]

I think you are right with the solution of holding the ST-LINK/V2 in reset. I had seen this feature on the STM page:

Quote

• USB ST-LINK with re-enumeration capability and three different interfaces:
• Virtual com port (with ST-LINK/V2-A only)
• Mass storage (with ST-LINK/V2-A only)
• Debug port

but with no mention of the limitation you quoted ( no big surprise, as I'm sure others using the Disco boards are not real happy with the change.). Perhaps the LINK V2 is waiting for re-enumeration for one of it's modes and stalling MIOS from booting ? At least the workaround is easy; and once the bootloader is installed the ST-LINK isn't needed any longer.

Yogi

[TK.]

According to the linked post, jumper SB10 has to be bridged with a solder blob.

Could you please try this out - I guess that this will solve the issue.

And could you please create a picture for documentation?

Best Regards, Thorsten.

[illogik]

Hi Thorsten!

I didn't notice your reply until now. Thats what i did (well actually i soldered the points of jumper SB10 to a pinheader so i can put a jumper on or off. Here is a pic.

The reason why the pinheader/jumper isn't connected to the the actual pads of SB10 is that when i tried to do that, one of it's pads came off due to overheating. So i checked the schematic and found out what SB10 does is shorting out capacitor C11. Capacitor C11 is connected between the NRST pin of the STM32F4 ic, and GND. So if you use jumper S10 you short the NRST pin to GND

So as you can see (kinda); i soldered a wire to the top contact of C11 and took a ground pin from the P1 port.

It works, but i immediately got stuck again. I'm planning to use this core for a mbcv_v2 system, and the lcd is not working, i posted on this in the MIDIbox CV V2 concept thread. I guess the issue has something to do with both this particular STM board and the CV_V2 app; because the LCD does work properly when i only have bootloader or when i upload other app (tried mbseq_v4) on this core.

cheers, marcel

 

 

[latigid on]

I have an STM32F4 board (about a year old from Mouser) with MB997C above the ST logo on the topside.

My newer Disco boards (a few weeks old from RS) have MB997D.

I haven't needed to test these yet, but I found a thread that may be of help:
https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Discovery/DispForm.aspx?ID=15970&RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2FSTM32Discovery%2FSTM32F407G-Discovery-STlinkV2(V2.J25.M13)%20%20-%20Boot%20fail%20using%20external%20power%20supply

Quote

Hello all,

I have bought STM32F407G-Discovery evaluation kit its "STM32F407G-Disc1- MB997D". Apparently I was unable to boot kit after programing  using external power supply e.g mobile phone usb charger or +5V to applied to 5V pin. It boots up fine with PC usb port as well USB port of oscilloscope but not with external +5V supply. 

After scratching head for while I found on powering kit using PC there is some communication going on between debugger (stm32f103) and USB host(PC). After this communication on board debugger (stm32f103) pulls NRST going to STM32F407 and also puts MCO out pin in high Z(guessed). This MCO from stm32f103 supposed to output 8Mhz to MCU xxF407 on PH0 pin.

Without initial communication between debugger and host PC above two things don’t happen so booting never happens. My debugger has version of "V2.J25.M13 STM32 Debug+Mass storage". 

So way around is disconnect NRST pin by removing SB11 solder bridge and disconnect MCO pin by removing R68. Schematics on page no 32 of user manual (UM1472).

After above trick my board boots up fine using external power supply. I am not sure this initialisation functionality is intended on V2.J25.M13 firmware or its bug? can some buddy try to replicate this issue?

 

Hope that can be of help.

[latigid on]

Today I experienced the same behaviour on my board marked MB997D. The fix noted above works perfectly, just remove link SB11 and resistor R68 (100R). Both are on the underside of the Discovery board. LED1 now blinks red (perceived lack of USB host I assume), but it still boots into ST LINK okay (I didn't try flashing the bootloader).

Maybe to clarify: I had already gone through the MIOS bootloader process, but afterwards, unless the mini USB (ST LINK side) was connected the computer wouldn't recognise the micro USB, i.e. it wouldn't show up as a MIDI device in MIOS Studio. This confirms the poster's theory that an absence of USB on the ST LINK side holds the board in reset. SB11 and R68 are still present on the MB997C revision and I can't see any other layout or jumper configuration differences, so it must be down to firmware (?) on the STM32F1 side. No problems here using an LCD on J15A.

I don't recommend bridging SB10, because that will negate the effect of a power on reset (pin is low while capacitor C11 charges) and also renders the RESET button useless.

Edited August 24, 2016 by latigid on

[latigid on]

In fact, it's easier than this. ST released a new firmware for ST LINK (STSW-LINK007) that removes the requirement for USB host to be present. If your device exhibits problems, try upgrading the firmware (mini USB side). It only deals with the "bootloader" side; it's not necessary to re-flash the F407 chip.