Nucleo-64 - Revision history

Kai: /* Programming */

2022-09-18T16:18:00Z

Programming

← Older revision		Revision as of 2022-09-18T16:18:00
Line 146:		Line 146:

	=== Programming ===		=== Programming ===
	~~Please download~~ the [~~http~~://www.st.com~~/content/ccc~~/resource/~~technical/document~~/programming_manual/~~6c/3a/cb/e7/e4/ea/44/9b/DM00046982~~.pdf/~~files~~/~~DM00046982~~.~~pdf~~/~~jcr:content~~/~~translations~~/~~en.DM00046982~~.pdf ~~Programming~~ Manual ~~PM0214~~] from ST ~~for their STM32F3xx, STM32F4xx and STM32L4xx series Cortex-M4 microcontrollers~~.		For the Nucleo-F411RE, see the [https://www.st.com/resource/en/programming_manual/pm0214-stm32-cortexm4-mcus-and-mpus-programming-manual-stmicroelectronics.pdf STM32 Cortex-M4 MCUs and MPUs Programming Manual] and [https://www.st.com/resource/en/reference_manual/rm0383-stm32f411xce-advanced-armbased-32bit-mcus-stmicroelectronics.pdf STM32F411xC/E Reference Manual] from ST.
	<br />		<br />
	<br />		<br />

Kai: Kai moved page Programming STM32F411 to Nucleo-64 without leaving a redirect: Most of the information applies to Nucleo-64 in general.

2022-09-16T09:07:26Z

Kai moved page Programming STM32F411 to Nucleo-64 without leaving a redirect: Most of the information applies to Nucleo-64 in general.

← Older revision	Revision as of 2022-09-16T09:07:26
(No difference)

Kai at 2019-08-06T16:18:10

2019-08-06T16:18:10Z

← Older revision		Revision as of 2019-08-06T16:18:10
Line 32:		Line 32:
	=== Building and Uploading a Program ===		=== Building and Uploading a Program ===
	<br />		<br />
	==== Building with the Mbed Web IDE and uploading with ''st-flash~~'' or ''mbed~~'' ====		==== Building with the Mbed Web IDE and uploading with ''st-flash'' ====
	The [https://ide.mbed.com/compiler/ Mbed web IDE] can be used to create an executable binary program that is downloaded from the website and uploaded to the GPU.		The [https://ide.mbed.com/compiler/ Mbed web IDE] can be used to create an executable binary program that is downloaded from the website and uploaded to the GPU.
	<pre class="terminal">		<pre class="terminal">
	st-flash write <path to bin file>/myprogram.bin 0x08000000		st-flash write <path to bin file>/myprogram.bin 0x08000000
	</pre>		</pre>
	where 0x8000000 is the address at which the '''flash memory region''' starts on STM32F4 chips. Our program needs to be uploaded into this memory region in order to be executed after a system restart.		where 0x8000000 is the address at which the '''flash memory region''' starts on STM32F4 chips. Our program needs to be uploaded into this memory region in order to be executed after a system restart. Note that the ''st-flash'' tool is part of the [https://github.com/texane/stlink stlink project on GitHub] and not installable from the Ubuntu 18.04 repository.
	<br />		<br />
	<br />		<br />
	~~Note that the ''st~~-~~flash''~~ tool ~~is part of the [https://github.com/texane/stlink stlink~~ project ~~on GitHub]~~ and ~~not installable from the Ubuntu 18.04 repository. Another tool~~ for flashing the binary is ''mbed'', which is part of the [[ARM_Mbed#Command_Line_Tools \| Mbed Command Line Tools]].		==== Building and uploading with Mbed-CLI ====
			Another tool for creating an Mbed project, for building it, and for flashing the generated binary is the tool ''mbed'', which is part of the [[ARM_Mbed#Command_Line_Tools \| Mbed Command Line Tools]] and installed the Python package manager PIP. Unfortunately, the flashing function of ''mbed'' requires that the project is completely handled by the ''mbed'' tool.
	<br />		<br />
	<br />		<br />

	==== Building with GNU MCU Eclipse and uploading with OpenOCD ====		==== Building with GNU MCU Eclipse and uploading with OpenOCD ====
	In GNU MCU Eclipse (https://gnu-mcu-eclipse.github.io/downloads/), select "Create a New STM32F4xx C/C++ Project as shown:		In GNU MCU Eclipse (https://gnu-mcu-eclipse.github.io/downloads/), select "Create a New STM32F4xx C/C++ Project as shown:

Kai: /* Building with the Mbed Web IDE and uploading with st-flash */

2019-08-06T16:04:03Z

Building with the Mbed Web IDE and uploading with st-flash

← Older revision		Revision as of 2019-08-06T16:04:03
Line 32:		Line 32:
	=== Building and Uploading a Program ===		=== Building and Uploading a Program ===
	<br />		<br />
	==== Building with the Mbed Web IDE and uploading with st-flash ====		==== Building with the Mbed Web IDE and uploading with ''st-flash'' or ''mbed'' ====
	The [https://ide.mbed.com/compiler/ Mbed web IDE] can be used to create an executable binary program that is downloaded from the website and uploaded to the GPU.		The [https://ide.mbed.com/compiler/ Mbed web IDE] can be used to create an executable binary program that is downloaded from the website and uploaded to the GPU.
	<pre class="terminal">		<pre class="terminal">
	st-flash write <path to bin file>/myprogram.bin 0x08000000		st-flash write <path to bin file>/myprogram.bin 0x08000000
	</pre>		</pre>
	where 0x8000000 is the address at which the '''flash memory region''' starts on STM32F4 chips. Our program needs to be uploaded into this memory region in order to be executed after a system restart. Note that the ''st-flash'' tool is part of the [https://github.com/texane/stlink stlink project on GitHub] and not installable from the Ubuntu 18.04 repository.		where 0x8000000 is the address at which the '''flash memory region''' starts on STM32F4 chips. Our program needs to be uploaded into this memory region in order to be executed after a system restart.
			<br />
			<br />
			Note that the ''st-flash'' tool is part of the [https://github.com/texane/stlink stlink project on GitHub] and not installable from the Ubuntu 18.04 repository. Another tool for flashing the binary is ''mbed'', which is part of the [[ARM_Mbed#Command_Line_Tools \| Mbed Command Line Tools]].
	<br />		<br />
	<br />		<br />

Kai: /* Building with the Mbed Web IDE and uploading with st-flash */

2019-08-06T15:32:53Z

Building with the Mbed Web IDE and uploading with st-flash

← Older revision		Revision as of 2019-08-06T15:32:53
Line 37:		Line 37:
	st-flash write <path to bin file>/myprogram.bin 0x08000000		st-flash write <path to bin file>/myprogram.bin 0x08000000
	</pre>		</pre>
	where 0x8000000 is the address at which the '''flash memory region''' starts on STM32F4 chips. Our program needs to be uploaded into this memory region in order to be executed after a system restart.		where 0x8000000 is the address at which the '''flash memory region''' starts on STM32F4 chips. Our program needs to be uploaded into this memory region in order to be executed after a system restart. Note that the ''st-flash'' tool is part of the [https://github.com/texane/stlink stlink project on GitHub] and not installable from the Ubuntu 18.04 repository.
	<br />		<br />
	<br />		<br />

	==== Building with GNU MCU Eclipse and uploading with OpenOCD ====		==== Building with GNU MCU Eclipse and uploading with OpenOCD ====
	In GNU MCU Eclipse (https://gnu-mcu-eclipse.github.io/downloads/), select "Create a New STM32F4xx C/C++ Project as shown:		In GNU MCU Eclipse (https://gnu-mcu-eclipse.github.io/downloads/), select "Create a New STM32F4xx C/C++ Project as shown:

Kai at 2019-07-18T22:36:20

2019-07-18T22:36:20Z

← Older revision		Revision as of 2019-07-18T22:36:20
Line 30:		Line 30:
	<br />		<br />
	<br />		<br />
			=== Building and Uploading a Program ===
	=== ~~Setup~~ ===		<br />
	~~Our~~ program is ~~called~~ '''~~STM32F4Test~~'''. In Eclipse, select ~~create~~ a ~~new~~ STM32F4xx C/C++ Project as shown:		==== Building with the Mbed Web IDE and uploading with st-flash ====
			The [https://ide.mbed.com/compiler/ Mbed web IDE] can be used to create an executable binary program that is downloaded from the website and uploaded to the GPU.
			<pre class="terminal">
			st-flash write <path to bin file>/myprogram.bin 0x08000000
			</pre>
			where 0x8000000 is the address at which the '''flash memory region''' starts on STM32F4 chips. Our program needs to be uploaded into this memory region in order to be executed after a system restart.
			<br />
			<br />
			==== Building with GNU MCU Eclipse and uploading with OpenOCD ====
			In GNU MCU Eclipse (https://gnu-mcu-eclipse.github.io/downloads/), select "Create a New STM32F4xx C/C++ Project as shown:
	[[File:Programming-STM32F4-New-Project.png \| x400px]]		[[File:Programming-STM32F4-New-Project.png \| x400px]]
	<br />		<br />
	<br />		<br />

	~~=== Using OpenOCD And Telnet To Transfer The Executable ===~~
	[[OpenOCD]] is a command-line tool for flashing binaries onto microcontrollers. Open a terminal window and type		[[OpenOCD]] is a command-line tool for flashing binaries onto microcontrollers. Open a terminal window and type
	<pre class="terminal">		<pre class="terminal">

Kai: /* Using OpenOCD And Telnet To Transfer The Executable */

2019-07-18T19:55:22Z

Using OpenOCD And Telnet To Transfer The Executable

← Older revision		Revision as of 2019-07-18T19:55:22
Line 38:		Line 38:

	=== Using OpenOCD And Telnet To Transfer The Executable ===		=== Using OpenOCD And Telnet To Transfer The Executable ===
	Open a terminal window and type		[[OpenOCD]] is a command-line tool for flashing binaries onto microcontrollers. Open a terminal window and type
	<pre class="terminal">		<pre class="terminal">
	openocd -f /usr/share/openocd/scripts/board/st_nucleo_f4.cfg -c "program <path to build results folder>/STM32F4Test.elf verify reset exit"		openocd -f /usr/share/openocd/scripts/board/st_nucleo_f4.cfg -c "program <path to build results folder>/STM32F4Test.elf verify reset exit"

Kai: /* Debugging With OpenOCD */

2019-07-18T19:52:50Z

Debugging With OpenOCD

← Older revision		Revision as of 2019-07-18T19:52:50
Line 80:		Line 80:

	=== Debugging With OpenOCD ===		=== Debugging With OpenOCD ===
	First of all, you should make sure GDB for ARM is installed.		First of all, you should make sure GDB for ARM is installed. Either install from the default repository
	<pre class="terminal">		<pre class="terminal">
	sudo apt install gdb-arm-none-eabi		sudo apt install gdb-arm-none-eabi
	</pre>		</pre>
			or [https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads download the latest version directly from ARM].
	<br />		<br />
	==== Command-Line Debugging With GDB/OpenOCD ====		==== Command-Line Debugging With GDB/OpenOCD ====
Line 110:		Line 111:
	<br />		<br />
	<br />		<br />

	=== DFU mode ===		=== DFU mode ===
	Pin #7 on the outer left male header row CN7 is the '''BOOT0''' pin. Pin #5, right next to it, is VDD. So, in order to enable writing to the boot memory via USB we simply cap these two pins with a jumper. The bootloader thus switches to [https://en.wikipedia.org/wiki/USB#Device_Firmware_Upgrade DFU] mode after resetting the STM32. USB data wires D+ and D- need to be connected to pins PA12 and PA11, respectively. PA11 and PA12 are located on the male header row CN10 on the right side.		Pin #7 on the outer left male header row CN7 is the '''BOOT0''' pin. Pin #5, right next to it, is VDD. So, in order to enable writing to the boot memory via USB we simply cap these two pins with a jumper. The bootloader thus switches to [https://en.wikipedia.org/wiki/USB#Device_Firmware_Upgrade DFU] mode after resetting the STM32. USB data wires D+ and D- need to be connected to pins PA12 and PA11, respectively. PA11 and PA12 are located on the male header row CN10 on the right side.

Kai: /* Programming */

2017-04-09T21:38:16Z

Programming

New page

=== Introduction ===
This article is about programming the [[ARM]] development board [http://www.st.com/content/st_com/en/products/evaluation-tools/product-evaluation-tools/mcu-eval-tools/stm32-mcu-eval-tools/stm32-mcu-nucleo/nucleo-f411re.html Nucleo-64 STM32F411] by STMicroelectronics. The development environment is [http://www.eclipse.org/neon Eclipse 4.6.2] (a.k.a. "Neon.2") with the [http://gnuarmeclipse.github.io/ GNU ARM Eclipse] plugin running on Ubuntu Linux. If your GNU ARM toolchain is [https://developer.arm.com/open-source/gnu-toolchain/gnu-rm the latest version directly from ARM], then you will have problems debugging in Eclipse because the Eclipse debugger is not able to suspend or terminate the debugging session. You can work around this problem by either debugging manually from the command line or by using Eclipse 4.5.2 (a.k.a. "Mars.2"). It is expected that the problem will be fixed in Neon.3.
 
 
I am combining the knowledge I obtained from various sources like the official documentation by ARM Ltd., [http://regalis.com.pl/en/arm-cortex-stm32-gnulinux the tutorial by Patryk Jaworski], where he shows us how to program a Nucleo development board with an STM32F401RE processor by using the GNU ARM cross-compiler and the CMSIS library extracted from the STM32CubeF4 software bundle, [http://vedder.se/2012/12/debugging-the-stm32f4-using-openocd-gdb-and-eclipse the tutorial by Benjamin Vedder], who shows us how to set up the Eclipse debugger for STM32F4 to work with OpenOCD, and a [http://electronics.stackexchange.com/questions/149387/how-do-i-print-debug-messages-to-gdb-console-with-stm32-discovery-board-using-gd discussion on StackExchange] about how to use GDB with OpenOCD
 
 
We will be using CMSIS, HAL and assembly code in our program. Fortunately we don't need to extract CMSIS or HAL from the [http://www.st.com/en/embedded-software/stm32cubef4.html STM32CubeF4] bundle, like Patryk did in his tutorial. The STM32F4xx template project in the GNU ARM Eclipse plugin includes the CMSIS and HAL libraries.
 
 
Note that the Nucleo boards do not include a programmable bootloader and ARM Cortex-M usually don't have an integrated bootloader, unlike the ATmega processors used in [[Arduino]] boards. The uploaded program therefore gets wiped when power is cut off.
 
 

=== Hardware Overview And Specifications ===
==== The Board ====
{| style="border-width:0"
| style="text-align:left;" | [[File:Programming-STM32F4-Nucleo-64-board-top.jpg | x360px]] || [[File:Programming-STM32F4-Nucleo-64-board-supports.jpg | x360px]]
|}
In the picture on the left, the top part of the board is the ST-LINK/V2-1 debugger/programmer for STM32 microcontrollers. It has [[SWD]] (serial wire debugging) pins. It can be used to program ARM processors on other boards by connecting the SWD pins (the 6 headers on the left) to the appropriate pins of the other board.
 
[[File:Programming-STM32F4-Nucleo-64-SWD.png | x200px]]
 
 
The picture on the right shows the two-piece support structure that I designed to relieve the pins on the bottom side from physical stress. The 3D model of the support is included with the project files.
 
 
==== Pin Layout ====
[[File:Nucleo-STM32F411-pins.png | 540px]]
 
 

=== Setup ===
Our program is called '''STM32F4Test'''. In Eclipse, select create a new STM32F4xx C/C++ Project as shown:
[[File:Programming-STM32F4-New-Project.png | x400px]]
 
 

=== Using OpenOCD And Telnet To Transfer The Executable ===
Open a terminal window and type
<pre class="terminal">
openocd -f /usr/share/openocd/scripts/board/st_nucleo_f4.cfg -c "program <path to build results folder>/STM32F4Test.elf verify reset exit"
</pre>
where ''<path to build results folder>'' needs to be replaced by the path to the build results folder (= ''<project folder>/Debug'' for debug builds). OpenOCD will use the specified configuration file for STM32F4 Nucleo boards and execute the given commands to transfer the ARM '''program''' corresponding to ''STM32F4Test.elf'', '''verify''' the transferred binary, '''reset''' the microprocessor so that the program starts from the beginning, and '''exit''' execution after closing its connection to the board. The program will continue running on the board after OpenOCD exits.
 
 
The commands executed by OpenOCD can also be issued from a second terminal session while in the first terminal session OpenOCD runs in server mode via
<pre class="terminal">
cd <project folder>
openocd -f /usr/share/openocd/scripts/board/st_nucleo_f4.cfg
</pre>
and waits for the telnet connection on port '''4444'''. In the second terminal you just type
<pre class="terminal">
cd <project folder>
telnet localhost 4444
</pre>
to connect to OpenOCD. Now issue the commands
<pre class="terminal">
> reset halt
> arm semihosting enable
> program Debug/STM32F4Test.elf verify reset
</pre>
or, alternatively,
<pre class="terminal">
> reset halt
> arm semihosting enable
> flash write_image erase Debug/STM32F4Test.hex
> reset
</pre>
to load and run the generated program. Note that the working directories are the same in both terminals so that relative file paths can be used. Also note that we enabled [http://www.keil.com/support/man/docs/armcc/armcc_pge1358787046598.htm ARM semihosting], which binds the I/O of the program that runs on the ARM processor to the I/O of the terminal that we are running OpenOCD from. Otherwise we would not be seeing the debug (trace) messages in the first terminal.
 
 
To disconnect the ''telnet'' client from the OpenOCD server, type
<pre class="terminal">
> exit
</pre>
The OpenOCD server and the ARM program will keep running. You can connect again with a new ''telnet'' session. To stop the server (and the program), press ''Ctrl+C'' in the first terminal.
 
 

=== Debugging With OpenOCD ===
First of all, you should make sure GDB for ARM is installed.
<pre class="terminal">
sudo apt install gdb-arm-none-eabi
</pre>
 
==== Command-Line Debugging With GDB/OpenOCD ====
Open two terminal sessions. In the first terminal start OpenOCD as server:
<pre class="terminal">
openocd -f /usr/share/openocd/scripts/board/st_nucleo_f4.cfg
</pre>
Note that your working directory does not matter when starting OpenOCD. In the second terminal, start GDB, connect to the OpenOCD server on port 3333, load the program and run it:
<pre class="terminal">
cd <project folder>
arm-none-eabi-gdb Debug/STM32F4Test.elf
> target remote localhost:3333
> monitor arm semihosting enable
> monitor reset halt
> load Debug/STM32F4Test.elf
> continue
</pre>
Here we use the GDB command ''monitor'' to send messages (usually commands) to the remote target. The line "''monitor arm semihosting enable''" is needed for ''continue'' to work. After ''continue'', use the [http://visualgdb.com/gdbreference/commands GDB commands] to pause execution (Ctrl+C), set breakpoints, inspect stack variables, and so on.
 
 

==== Setting Up The Eclipse Debugger ====
Read the instructions in [http://gnuarmeclipse.github.io/debug/openocd/#start-a-debug-session the GNU ARM Eclipse documentation]. In our case, the ''Config options'' string that needs to be entered is ''-f /usr/share/openocd/scripts/board/st_nucleo_f4.cfg''.
 
[[File:Programming-STM32F4-Debugger-Configuration.png | x400px]]
 
 
=== DFU mode ===
Pin #7 on the outer left male header row CN7 is the '''BOOT0''' pin. Pin #5, right next to it, is VDD. So, in order to enable writing to the boot memory via USB we simply cap these two pins with a jumper. The bootloader thus switches to [https://en.wikipedia.org/wiki/USB#Device_Firmware_Upgrade DFU] mode after resetting the STM32. USB data wires D+ and D- need to be connected to pins PA12 and PA11, respectively. PA11 and PA12 are located on the male header row CN10 on the right side.
 
 
DFU bootloader configuration for STM32F411 according to ST application note AN2606
{|
! Feature/Peripheral
! State
! Comment
|-
| USB || Enabled || USB OTG FS configured in Forced Device mode
|-
| USB_DM pin || Input/Output || connects to STM32 pin PA11
|-
| USB_DP pin || Input/Output || connects to STM32 pin PA12
|-
| TIM11 || Enabled || This timer is used to determine the value of the HSE. Once the HSE frequency is determined, the system clock is configured to 60 MHz using PLL and HSE.
|}
''The system clock is derived from the embedded internal high-speed RC for USARTx, I2Cx and SPIx bootloaders. This internal clock is also used for DFU (USB FS Device) but only for the selection phase. An external clock multiple of 1 MHz (between 4 and 26 MHz) is required for DFU bootloader execution after the selection phase.''
 
 

=== Programming ===
Please download the [http://www.st.com/content/ccc/resource/technical/document/programming_manual/6c/3a/cb/e7/e4/ea/44/9b/DM00046982.pdf/files/DM00046982.pdf/jcr:content/translations/en.DM00046982.pdf Programming Manual PM0214] from ST for their STM32F3xx, STM32F4xx and STM32L4xx series Cortex-M4 microcontrollers.
 
 
==== Global Variables ====
{|
| HSE || external high speed clock, usually more accurate than the internal clock HSI
|-
| HSI || internal high speed clock
|}