Friday, August 28, 2015

Getting started with the STM32F7 Discovery board

The other week I got a brand new STM32F7 Discovery board, the fabled Cortex M7 had arrived and performance bliss was at hand ...

... except there were a few minor stumbling stones on the road to paradise ...

this is not an ad for ST, I did pay the full Mouser price.

  • ST programming tools for the ST-Link interface are not available for Mac OSX, and the board does not expose the JTAG/SWD of the Cortex M7, it is only available through the onboard ST-Link adapter chip. The GGC ARM Embedded toolchain https://launchpad.net/gcc-arm-embedded/+download was happy to generate code after importing some system defines and startup code from STM32Cube_FW_F7_V1.1.0 library and a bit of tweaking to Makefiles and linker scripts. It was possible to flash the binaries to the board using the USB file system interface, but then there is no debug connection, and it refused load code that was linked to use fast ITCM flash access.
  • With some some work it was possible to add the chip and flash configuration details to the free stlink utility https://github.com/texane/stlink and also tweak the stlink RAM based flash writing code to handle the 64 bit flash access so flash is correctly written, all running on Mac OSX.
  • The example code in the STM32Cube_FW_F7_V1.1.0 library does not by default use the external 25MHz crystal clock, only the onchip internal 16MHz oscillator. The PLL is also not configured by default, meaning the chip runs at 16MHz, and not the 196 or 216 Mhz that should be possible.
  • For optimal performance the linker settings should be configured to make the code use the ART accelerated ITCM flash access at 0x0020000 instead of the normal, slow, flash access at 0x0800000. When the linker was configured this way the ST onboard USB flash loader refused to load code into flash, but stlink utility worked.
  • The external SDRAM for the Discovery board has a different configuration than the one in the "system_stm32f7xx.c" supplied from ST. It seems ST has used the settings for another STM32F7 board and not been careful to make the changes for the F7 Discovery board.
Virtual USB com port was quite easy, it turns out that the USB subsystem is almsot identical to the the one on STMF4 chips.

After these tweaks I was able to run some simple tests where the chip executed between 200 and 300M instructions/sec. I think this can be a great chip for audio synthesis.

Next will be the big LCD display, but that must wait for when I have lots of free time again.

3 comments:

osannolik said...

Could you please elaborate on what you needed to do in order to get st-link working? I'm having trouble with breakpoints.

Magnus Lundin said...

What troubles, does breakpoints work sometimes or not at all. What setup do you use ?

There is a suggested patch on https://github.com/texane/stlink and some discussion. The patch should help for Cortex M7 but in its current state it will probably break other targets like M3 and M4, so I dont think its ready for inclusion in the main tree yet.

I have been using stlink/gdb-server from the main tree at texane/stlink with breakpoints working, but I have not done any heavy testing.

osannolik said...

Thanks for pointing out that it has been discussed at the issues page, I had totally missed that.

The problems I had were that the breakpoints did not work at all. I managed to figure out that I needed to change CODE_BREAK_NUM and CODE_LIT_NUM, but as was pointed out in the patch you referred to, it is also necessary to e.g. modify a mask. Anyways, now it is working fine.