Stm32f407vg stm32f4discovery

STM32F4DISCOVERY

• A discovery board for STM32F407VGT6 microcontroller with 168 MHz ARM Cortex-M4F core, 1024 KB Flash, 192 KB RAM, 4 KB battery-backed RAM in LQFP100 package.
• This board includes an integrated ST-LINK/V2 debugger via Mini-B USB connector, accelerometer (LIS302DL), microphone (MP45DT02), audio codec (CS43L22), 3.5 mm audio jack, 4 user LEDs, user button, reset button, Full-Speed USB OTG to second Micro-AB USB connector, and two 25x2 male pin headers.
• A separate STM32F4DIS-BB baseboard is available.

Configuring the kernel

Unlike the stm32vldiscovery, this board has the STLink/V2 firmware which is much more Linux friendly. All you need is a recent version of OpenOCD and the QStlink2 tool to support ths board.

First, make sure the correct board is selected in the miosix/config/Makefile.inc file. The line defining the OPT_BOARD variable should be set to OPT_BOARD := stm32f407vg_stm32f4discovery, that is, that line should be uncommented, and the other commented out, like this:

##
## Target board, choose one. This also implicitly select the target
## architecture
##
#OPT_BOARD := lpc2138_miosix_board
#OPT_BOARD := stm32f103ze_stm3210e-eval
#OPT_BOARD := stm32f103ve_mp3v2
#OPT_BOARD := stm32f100rb_stm32vldiscovery
#OPT_BOARD := stm32f103ve_strive_mini
#OPT_BOARD := stm32f103ze_redbull_v2
OPT_BOARD := stm32f407vg_stm32f4discovery
#OPT_BOARD := stm32f207ig_stm3220g-eval
#OPT_BOARD := stm32f207zg_ethboard_v2

In addition, this board has a couple of board-specific options in the Makefile.inc file. For convenience, the relevant part of that configuration file is reported here so as to be easily located within the file

##---------------------------------------------------------------------------
## stm32f407vg_stm32f4discovery
##
ifeq ($(OPT_BOARD),stm32f407vg_stm32f4discovery)

  ## Linker script type, there are two options
  ## 1) Code in FLASH, stack + heap in internal RAM (file *_rom.ld)
  ## 2) Code + stack + heap in internal RAM (file *_ram.ld)
  LINKER_SCRIPT_PATH := arch/cortexM4_stm32f4/stm32f407vg_stm32f4discovery/
  LINKER_SCRIPT := $(LINKER_SCRIPT_PATH)stm32_1m+192k_rom.ld
  #LINKER_SCRIPT := $(LINKER_SCRIPT_PATH)stm32_1m+192k_ram.ld

  ## This causes the interrupt vector table to be relocated in SRAM, must be
  ## uncommented when using the ram linker script
  #SRAM_BOOT := -DVECT_TAB_SRAM

endif

As can be seen, the file is made mostly of comments, and defines three options: LINKER_SCRIPT and SRAM_BOOT. The comments explain in detail the meaning of there options, so it isn't necessary to further explain them.

Then you should disable filesystem support. Since this board lacks a microSD card or other hardware that could support a filesystem, the bsp has no filesystem backend implementation and if you leave the filesystem enabled the kernel will fail to compile saying it can't find a backend. To do so, open the miosix/config/miosix_settings.h and comment out the

#define WITH_FILESYSTEM

After modifying configuration files it is recomended to do a make clean; make (or in the Netbeans IDE, to click on the "Clean and build project" button) to be sure that changes are applied.

Loading code

As explained before, there are more than one linker script for this board, and the selected linker script affects the way code should be loaded on the board.

• The stm32_1m+192k_rom.ld is the default linker script, and put the code in FLASH, so you need to program the microcontroller's FLASH every time you change your code, but code will run faster and won't be lost at each reboot.
  A simple way to load code in FLASH is to use the QStlink2 tool.
• The stm32_1m+192k_ram.ld linker script is very useful for debugging code on this board, as it locates everything (code, stack, heap) in the microcontroller's RAM.
  It has the disadvantage that the loaded code is lost upon reboot (being in a volatile memory), but for debugging,it is not an issue.

stdout redirection

The board support package of this board is a little different from the other, as by default it will redirect stdout (but not stdin!) through the debug communication channel. This means that if you are debugging your board with OpenOCD+gdb, you'll see the output of printf directly in your gdb shell. Since the debug communication channel is unidirectional, stdin is redirected nowhere, and attempting to read from it will result in an infinte loop. This has been done to keep the board "self contained", that is, to be able to write and test code without adding additional hardware.

If on the other hand, you have a 3.3V logic level USB to serial adapter, such as one based on the FT232 chip, you can still redirect printf to the serial port USART3 (GPIO PB10 and PB11 on the board). This also has the advantage of making both stdout and stdin work. To do so, edit the file miosix/arch/cortexM4_stm32f4/stm32f407vg_stm32f4discovery/board_settings.h and comment out the line #define STDOUT_REDIRECTED_TO_DCC

In Circuit Debugging

Before you begin you should note that the Miosix kernel will put the CPU to a low power state when no thread is running. This low power state will usually confuse debuggers and make them lose sync with the CPU. To avoid this you need to edit the miosix/config/miosix_settings.h file and uncomment

#define JTAG_DISABLE_SLEEP 

This will prevent the kernel from putting the CPU in its low power state making debugging possible. Also, to be able to precisely single-step your code you need to disable compiler optimizations as gdb is incapable of reliably debug an optimized code. The option is in the miosix/config/Makefile.inc file and is the OPT_OPTIMIZATION := -O0 that should be uncommented while the other lines related to the same option should be commented out.

After modifying configuration files it is recomended to do a make clean; make (or in the Netbeans IDE, to click on the "Clean and build project" button) to be sure that changes are applied.

Since the board has an on board SWD in circuit debugger, simply plugging the USB cable is all you need from an hardware point of view. On the software side, you need to open two shells. In one do a

sudo openocd -f miosix/arch/cortexM4_stm32f4/stm32f407vg_stm32f4discovery/stm32f4discovery.cfgg 

This will start the OpenOCD program that will connect to the board and listen for GDB connections.

In the second shell type the following commands

arm-miosix-eabi-gdb main.elf
target remote :3333
monitor soft_reset_halt
monitor target_request debugmsgs enable
monitor trace point 1
break main
continue

The first command will start the gdb debugger. The following commands are typed into the gdb console, and tell it to connect to OpenOCD, and reset the board, enable the debug communication channel to redirect printf, and stop the program at the beginning of main() To load the program to be debugged, you can either do a make program before and then start debugging, or you can directly write the FLASH memory from within gdb with this command

monitor flash write_image erase main.bin 0x08000000 

From there on, consult a gdb reference on the Internet for information on how to single step code, set breakpoints and inspect variables.

Resource

*stm32f4discovery Datasheet