Stm32f407vg stm32f4discovery - Revision history

Fede.tft at 07:35, 10 May 2026

2026-05-10T07:35:21Z

← Older revision		Revision as of 07:35, 10 May 2026
Line 44:		Line 44:
	This is the default linker script, and puts 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.		This is the default linker script, and puts 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 [https://github.com/fpoussin/QStlink2 QStlink2] tool. Also, if you have a brand new~~ board ~~and QStlink fails you may take a look at [[ST~~-~~LINK utility update\|this page]]~~		Flashing this board on Linux can be done with st-flash.

	===stm32_1m+192k_ram.ld===		===stm32_1m+192k_ram.ld===

Fede.tft: Fixed baudrate, was 115200 but is 19200

2017-02-28T00:03:49Z

Fixed baudrate, was 115200 but is 19200

← Older revision		Revision as of 00:03, 28 February 2017
Line 53:		Line 53:
	The board has no serial to USB adapter onboard, so you need to use an external one, connected to USART3, in detail PB10 (TXD) and PB11 (RXD). The choice of USART3 was done due to the fact that USART1 pins are not free on this board.		The board has no serial to USB adapter onboard, so you need to use an external one, connected to USART3, in detail PB10 (TXD) and PB11 (RXD). The choice of USART3 was done due to the fact that USART1 pins are not free on this board.

	On Linux you can use screen. Open a terminal and type ''screen /dev/ttyUSB0 ~~115200~~'' (Note that to quit from screen you need to type "Ctrl-C, \"). You'll need to change /dev/ttyUSB0 with your serial port device name.		On Linux you can use screen. Open a terminal and type ''screen /dev/ttyUSB0 19200'' (Note that to quit from screen you need to type "Ctrl-C, \"). You'll need to change /dev/ttyUSB0 with your serial port device name.

	On windows you can use HyperTerminal, you need to configure it to use the required baud rate, no flow control, and select the correct COM port device name.		On windows you can use HyperTerminal, you need to configure it to use the required baud rate, no flow control, and select the correct COM port device name.

Silseva at 08:43, 16 December 2016

2016-12-16T08:43:08Z

← Older revision		Revision as of 08:43, 16 December 2016
Line 44:		Line 44:
	This is the default linker script, and puts 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.		This is the default linker script, and puts 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 [https://github.com/fpoussin/QStlink2 QStlink2] tool. If you have a brand new board and QStlink fails you may take a look at [[ST-LINK utility update\|this page]]		A simple way to load code in FLASH is to use the [https://github.com/fpoussin/QStlink2 QStlink2] tool. Also, if you have a brand new board and QStlink fails you may take a look at [[ST-LINK utility update\|this page]]

	===stm32_1m+192k_ram.ld===		===stm32_1m+192k_ram.ld===

Silseva: qstlink update

2016-12-16T08:39:58Z

qstlink update

← Older revision		Revision as of 08:39, 16 December 2016
Line 44:		Line 44:
	This is the default linker script, and puts 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.		This is the default linker script, and puts 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 [https://github.com/fpoussin/QStlink2 QStlink2] tool.		A simple way to load code in FLASH is to use the [https://github.com/fpoussin/QStlink2 QStlink2] tool. If you have a brand new board and QStlink fails you may take a look at [[ST-LINK utility update\|this page]]

	===stm32_1m+192k_ram.ld===		===stm32_1m+192k_ram.ld===

Fede.tft at 22:22, 24 August 2015

2015-08-24T22:22:21Z

Show changes

Fede.tft at 22:07, 17 June 2015

2015-06-17T22:07:04Z

← Older revision		Revision as of 22:07, 17 June 2015
Line 4:		Line 4:
	* This board includes an integrated [http://www.st.com/web/catalog/tools/PF219866 ST-LINK/V2] debugger via [[Mini-USB\|Mini-B USB]] connector, [[accelerometer]] (LIS302DL), [[microphone]] (MP45DT02), audio [[codec]] (CS43L22), [[Phone connector (audio)\|3.5 mm audio jack]], 4 user LEDs, user button, reset button, Full-Speed [[USB On-The-Go\|USB OTG]] to second [[MicroUSB\|Micro-AB USB]] connector, and two 25x2 male [[pin header]]s.		* This board includes an integrated [http://www.st.com/web/catalog/tools/PF219866 ST-LINK/V2] debugger via [[Mini-USB\|Mini-B USB]] connector, [[accelerometer]] (LIS302DL), [[microphone]] (MP45DT02), audio [[codec]] (CS43L22), [[Phone connector (audio)\|3.5 mm audio jack]], 4 user LEDs, user button, reset button, Full-Speed [[USB On-The-Go\|USB OTG]] to second [[MicroUSB\|Micro-AB USB]] connector, and two 25x2 male [[pin header]]s.
	* A separate [http://www.farnell.com/datasheets/1671410.pdf STM32F4DIS-BB] baseboard is available.		* A separate [http://www.farnell.com/datasheets/1671410.pdf STM32F4DIS-BB] baseboard is available.


	=== Configuring the kernel ===		=== 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 [https://github.com/fpoussin/QStlink2 QStlink2] tool to support ths board.		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 [https://github.com/fpoussin/QStlink2 QStlink2] tool to support ths board.

	First, make sure the correct board is selected in the ~~'''miosix/config/~~[~~http://gitorious~~.~~org/miosix-kernel/miosix-kernel/blobs/master/~~miosix/config/Makefile.inc ~~Makefile.inc~~]~~'''~~ file.		First, make sure the correct board is selected in the [[Makefile.inc\|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:		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:

Line 50:		Line 49:

	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.		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/[http://gitorious.org/miosix-kernel/miosix-kernel/blobs/master/miosix/config/miosix_settings.h 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.		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 ===		=== 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.		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.<br />A simple way to load code in FLASH is to use the [[QStlink2]] tool.		*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.<br />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.~~<br />~~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.		*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~~ ===		=== Serial port ===

	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~~.		The board has no serial to USB adapter onboard, so you need to use an external one, connected to USART3, in detail PB10 (TXD) and PB11 (RXD). The choice of USART3 was done due to the fact that USART1 pins are not free on this board.
	~~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~~.		=== In Circuit Debugging ===
	To ~~do so,~~ edit the ~~file '''miosix/arch/cortexM4_stm32f4/stm32f407vg_stm32f4discovery/~~[~~https://gitorious~~.~~org/~~miosix~~-kernel~~/~~miosix-kernel/blobs/master~~/~~miosix/arch/cortexM4_stm32f4/stm32f407vg_stm32f4discovery/board_settings.h board_settings~~.h]~~'''~~ and ~~comment out the line~~ #define ~~STDOUT_REDIRECTED_TO_DCC~~		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_settings.h\|miosix/config/miosix_settings.h]] file and uncomment

			<source lang="CPP">
			#define JTAG_DISABLE_SLEEP
			</source>

	~~=== 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/[http://gitorious.org/miosix-kernel/miosix-kernel/blobs/master/miosix/config/miosix_settings.h 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.		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.		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.
Line 80:		Line 73:
	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.		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.		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		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~~		<source lang="BASH">
			sudo openocd -f miosix/arch/cortexM4_stm32f4/stm32f407vg_stm32f4discovery/stm32f4discovery.cfg
			</source>

	This will ~~'''~~start the OpenOCD~~'''~~ program that will connect to the board and listen for GDB connections.		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		In the second shell type the following commands

	arm-miosix-eabi-gdb main.elf		<source lang="BASH">
	target remote :3333		arm-miosix-eabi-gdb main.elf
	monitor soft_reset_halt		target remote :3333
	~~monitor target_request debugmsgs enable~~		monitor soft_reset_halt
	~~monitor trace point 1~~		break main
	break main		continue
	continue		</source>

	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()		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 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		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
			<source lang="BASH">
			monitor flash write_image erase main.bin 0x08000000
			</source>

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

Andreabont: Adding category

2015-01-22T20:06:53Z

Adding category

← Older revision		Revision as of 20:06, 22 January 2015
Line 134:		Line 134:
	=== Resource ===		=== Resource ===
	stm32f4discovery [http://www.st.com/st-web-ui/static/active/en/resource/technical/document/user_manual/DM00039084.pdf Datasheet]		stm32f4discovery [http://www.st.com/st-web-ui/static/active/en/resource/technical/document/user_manual/DM00039084.pdf Datasheet]

			[[Category:Boards]]

Matteo.piazzolla: /* Resource */

2014-12-15T22:18:34Z

Resource

← Older revision		Revision as of 22:18, 15 December 2014
Line 133:		Line 133:

	=== Resource ===		=== Resource ===
	*stm32f4discovery [http://www.st.com/st-web-ui/static/active/en/resource/technical/document/user_manual/DM00039084.pdf Datasheet]		stm32f4discovery [http://www.st.com/st-web-ui/static/active/en/resource/technical/document/user_manual/DM00039084.pdf Datasheet]

Mario.polino: /* SD Card */

2014-12-15T22:07:22Z

SD Card

← Older revision		Revision as of 22:07, 15 December 2014
Line 127:		Line 127:
	\| D3 \|\| PC11 \|\| Y		\| D3 \|\| PC11 \|\| Y
	\|}		\|}

			Each connection needs a pullup resistor between ~47Kohm and 100Kohm.

			Optional GPIOs are used in 4-bit mode.

	=== Resource ===		=== Resource ===
	*stm32f4discovery [http://www.st.com/st-web-ui/static/active/en/resource/technical/document/user_manual/DM00039084.pdf Datasheet]		*stm32f4discovery [http://www.st.com/st-web-ui/static/active/en/resource/technical/document/user_manual/DM00039084.pdf Datasheet]

Mario.polino: /* SD Card */

2014-12-15T22:04:16Z

SD Card

← Older revision		Revision as of 22:04, 15 December 2014
Line 109:		Line 109:

	==== SD Card ====		==== SD Card ====
			Connect VCC (3V) and GND using a 100nF capacitor between VCC and GND, this will be useful to overcome to current absorption peaks.

	{\| class="wikitable"		{\| class="wikitable"