STM32F407VGT6 China Board not working - Tips?

[robert offner]

Posted on March 25, 2017 at 19:16

I have a Discovery F4 Board and purchased recently a China Board from *bay (Ebay-Artikel Nr. 272501820584?) with the same uC (STM32F407VGT6). I thought a cheap way to test my code and put it into my project. I have a sample code which works on the Discovery and i flashed the code with my Nucleo Board as programmer into the China Board which was a success. I tried two ways, first the SWD Header on the Nucleo like here: (

https://community.st.com/external-link.jspa?url=https%3A%2F%2Fdeveloper.mbed.org%2Fquestions%2F7974%2FF401RE-C

...) i also soldered a cable to the RESET Pin and connected it to the Nucleo Header Pin 5. I flashed with ST Link utility, read back and compared - no differences. Second i put a jumper on BOOT1 (BOOT0 and BOOT1 have Pullups) which pulled it low and entered the Bootloader, flashed with ST Flash Loader over UART1 which also worked (read back and compared). I then put a second jumper on BOOT0 - so both BOOT Pins are LOW, and the uC SHOULD start from Flash - but nothing. I am really stumped because i searched a lot and it should work. The code is definetely working, it is in the flash memory, the uC is alive through the SWD interface (i can see the Device, DeviceID, RevisionID,.. in the ST Link Utility) the Revision corresponds with the Chip (it is 2.0). Anybody any tips???

[S.Ma]

Posted on March 27, 2017 at 09:59

Maybe the SW do start and hangs when say trying to communicate with other devices which might be different...

Try with a simple test SW that is supposed to toggle LEDs... This will validate the internal MCU has started and its SYSCLK is working fine.

[AvaTar]

Posted on March 27, 2017 at 10:25

The code is definetely working

...

On the F407-Discovery - that doesn't mean too much for other boards.

What about the clock source?

Has your China-board a quartz, or a MCO input from the ST-Link ? I guess not. Perhaps you need to swap to HSI.

[robert offner]

Posted on March 27, 2017 at 10:45

The clock source is the same as on the Discovery (one 8MHz crystal), no MCO output though. I already put a lot of work into debugging including other firmware which only flashes a led (didn't work) but come to the conclusion that the board has some problems with soldering or defective portpins. 

[S.Ma]

Posted on March 27, 2017 at 11:09

Get an oscilloscope and check the supply lines, the external crystal oscillations, the reset and boot lines. Qwant/Google around for this board problems.

[AvaTar]

Posted on March 27, 2017 at 11:29

Power supply and buffering caps would be my second guess.

You can check for misplaced, reverse populated, or unpopulated components. The low price might have other reasons as well, not only the alleged low Chinese wages.

And, as other posters suggested, check the supply voltages and ext. clock statically and dynamically.

Perhaps modifying the source, and check if 8 MHz / HSI works.

[Tesla DeLorean]

Posted on March 27, 2017 at 21:33

Would definitely make the code in system_stm32f4xx.c use the HSI, either by not changing the clock, or using HSI (16 MHz) for the PLL source clock. The crystal won't work in BYPASS mode.

Remove the call the SetSysClock() in SystemInit() and the part will just use HSI

Run across the board you mention a few times, not one I've tried personally

http://www.ebay.de/itm/STM32F407VGT6-ARM-Cortex-M4-32bit-MCU-Core-Development-Board-STM32F4-Discovery-/272501820584

 

I prefer this board

http://www.ebay.de/itm/Mini-core-board-STM32-minimum-system-version-STM32F407VET6-/182309828654?hash=item2a7283382e:g:SecAAOSwnNBXXpV5

 

If you break in the debugger you should be able to determine where it is hung up. SystemInit() is called prior to main(), so 'run to main' won't get there if it is stuck in a loop waiting for HSE or the PLL to come ready.