sergiotarxz/nuttx
sergiotarxz/nuttx
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Documentation: migrate STM32F4

Browse Source
This commit is contained in:
raiden00pl 2023-08-23 10:22:31 +02:00 committed by Alan Carvalho de Assis
parent 0953d0cbb5
commit 00db279c00
34 changed files with 7626 additions and 8496 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
boards/arm/stm32/axoloti/README.txt → Documentation/platforms/arm/stm32f4/boards/axoloti/index.rst
View File

@ -1,5 +1,6 @@
README
======
=======
Axoloti
=======
This README discusses issues unique to NuttX configurations for the
Axoloti open source synthesizer board featuring the STM32F427IGH6

543
boards/arm/stm32/clicker2-stm32/README.txt → Documentation/platforms/arm/stm32f4/boards/clicker2-stm32/index.rst
View File

@ -1,71 +1,73 @@
README
======
=====================
Mikroe Clicker2 STM32
=====================
This is the README file for the port of NuttX to the Mikroe Clicker2 STM32
board based on the STMicro STM32F407VGT6 MCU.
This is the README file for the port of NuttX to the Mikroe Clicker2 STM32
board based on the STMicro STM32F407VGT6 MCU.
Reference: https://shop.mikroe.com/development-boards/starter/clicker-2/stm32f4
Reference: https://shop.mikroe.com/development-boards/starter/clicker-2/stm32f4
Contents
========
o Serial Console
o LEDs
o Buttons
o Using JTAG
o Configurations
- Serial Console
- LEDs
- Buttons
- Using JTAG
- Configurations
Serial Console
==============
The are no RS-232 drivers on-board. An RS-232 Click board is available:
https://shop.mikroe.com/click/interface/rs232 or you can cannot an off-
board TTL-to-RS-232 converter as follows:
The are no RS-232 drivers on-board. An RS-232 Click board is available:
https://shop.mikroe.com/click/interface/rs232 or you can cannot an off-
board TTL-to-RS-232 converter as follows::
USART2: mikroBUS1 PD6/RX and PD5/TX
USART3: mikroBUS2 PD9/RX and PD8TX
GND, 3.3V, and 5V. Are also available
GND, 3.3V, and 5V. Are also available
By default, USART3 on mikroBUS2 is used as the serial console in each
configuration unless stated otherwise in the description of the
configuration.
By default, USART3 on mikroBUS2 is used as the serial console in each
configuration unless stated otherwise in the description of the
configuration.
LEDs
====
The Mikroe Clicker2 STM32 has two user controllable LEDs:
The Mikroe Clicker2 STM32 has two user controllable LEDs::
LD1/PE12, Active high output illuminates
LD2/PE15, Active high output illuminates
If CONFIG_ARCH_LEDS is not defined, then the user can control the LEDs in any
way. If CONFIG_ARCH_LEDs is defined, then NuttX will control the 2 LEDs on
board the Clicker2 for STM32. The following definitions describe how NuttX
controls the LEDs:
If CONFIG_ARCH_LEDS is not defined, then the user can control the LEDs in any
way. If CONFIG_ARCH_LEDs is defined, then NuttX will control the 2 LEDs on
board the Clicker2 for STM32. The following definitions describe how NuttX
controls the LEDs:
SYMBOL Meaning LED state
LD1 LD2
------------------- ----------------------- -------- --------
LED_STARTED NuttX has been started OFF OFF
LED_HEAPALLOCATE Heap has been allocated OFF OFF
LED_IRQSENABLED Interrupts enabled OFF OFF
LED_STACKCREATED Idle stack created ON OFF
LED_INIRQ In an interrupt N/C ON
LED_SIGNAL In a signal handler No change
LED_ASSERTION An assertion failed No change
LED_PANIC The system has crashed OFF Blinking
LED_IDLE STM32 is is sleep mode Not used
=================== ======================= ======== ========
SYMBOL Meaning LD1 LD2
=================== ======================= ======== ========
LED_STARTED NuttX has been started OFF OFF
LED_HEAPALLOCATE Heap has been allocated OFF OFF
LED_IRQSENABLED Interrupts enabled OFF OFF
LED_STACKCREATED Idle stack created ON OFF
LED_INIRQ In an interrupt N/C ON
LED_SIGNAL In a signal handler N/C N/C
LED_ASSERTION An assertion failed N/C N/C
LED_PANIC The system has crashed OFF Blinking
LED_IDLE STM32 is is sleep mode N/U N/U
=================== ======================= ======== ========
Thus is LD1 is illuminated, the Clicker2 has completed boot-up. IF LD2
is glowly softly, then interrupts are being taken; the level of illumination
depends amount of time processing interrupts. If LD1 is off and LD2 is
blinking at about 2Hz, then the system has crashed.
Thus is LD1 is illuminated, the Clicker2 has completed boot-up. IF LD2
is glowly softly, then interrupts are being taken; the level of illumination
depends amount of time processing interrupts. If LD1 is off and LD2 is
blinking at about 2Hz, then the system has crashed.
Buttons
=======
The Mikroe Clicker2 STM32 has two buttons available to software:
The Mikroe Clicker2 STM32 has two buttons available to software::
T2/E0, Low sensed when pressed
T3/PA10, Low sensed when pressed
@ -73,24 +75,24 @@ Buttons
Using JTAG
==========
The Clicker2 comes with the mikroBootloader installed. That bootloader
has not been used and is possibly incompatible with the Clicker2-STM32
linker script at boards/arm/stm32/clicker2-stm32/scripts/flash.ld. Often code must
be built to execute at an offset in to FLASH when a bootloader is used.
Certainly that is the case for the ST-Micro DFU bootloader but I am not
aware of the requirements for use with the mikroBootloader.
The Clicker2 comes with the mikroBootloader installed. That bootloader
has not been used and is possibly incompatible with the Clicker2-STM32
linker script at boards/arm/stm32/clicker2-stm32/scripts/flash.ld. Often code must
be built to execute at an offset in to FLASH when a bootloader is used.
Certainly that is the case for the ST-Micro DFU bootloader but I am not
aware of the requirements for use with the mikroBootloader.
JTAG has been used in the development of this board support. The
Clicker2-STM32 board offers a 2x5 JTAG connector. You may use Dupont
jumpers to connect this port to JTAG as described here:
JTAG has been used in the development of this board support. The
Clicker2-STM32 board offers a 2x5 JTAG connector. You may use Dupont
jumpers to connect this port to JTAG as described here:
https://www.mikroe.com/how-to-use-st-link-v2-with-clicker-2-for-stm32-a-detailed-walkthrough/
http://www.playembedded.org/blog/en/2016/02/06/mikroe-clicker-2-for-stm32-and-stlink-v2/
NOTE that the FLASH probably has read protection enabled locked. You may
need to follow the instructions at the second link to unlock it. You can
also use the STM32 ST-Link CLI tool on Windows to remove the read protection
using the -OB command:
NOTE that the FLASH probably has read protection enabled locked. You may
need to follow the instructions at the second link to unlock it. You can
also use the STM32 ST-Link CLI tool on Windows to remove the read protection
using the -OB command::
$ ./ST-LINK_CLI.exe -c SN=53FF6F064966545035320387 SWD LPM
STM32 ST-LINK CLI v2.3.0
@ -121,15 +123,19 @@ Using JTAG
Updating option bytes...
Option bytes updated successfully.
NOTE:
1. You can get the ST-Link Utilities here:
http://www.st.com/en/embedded-software/stsw-link004.html
2. The ST-LINK Utility command line interface is located at:
[Install_Directory]\STM32 ST-LINK Utility\ST-LINK Utility\ST-LINK_CLI.exe
3. You can get a summary of all of the command options by running
ST-LINK_CLI.exe with no arguments.
4. You can get the serial number of the ST-Link when from the information
window if you connect via the ST-Link Utility:
NOTE:
1. You can get the ST-Link Utilities here:
http://www.st.com/en/embedded-software/stsw-link004.html
2. The ST-LINK Utility command line interface is located at:
[Install_Directory]\STM32 ST-LINK Utility\ST-LINK Utility\ST-LINK_CLI.exe
3. You can get a summary of all of the command options by running
ST-LINK_CLI.exe with no arguments.
4. You can get the serial number of the ST-Link when from the information
window if you connect via the ST-Link Utility::
11:04:28 : ST-LINK SN : 53FF6F064966545035320387
11:04:28 : ST-LINK Firmware version : V2J24S4
@ -142,42 +148,43 @@ Using JTAG
11:04:30 : Can not read memory!
Disable Read Out Protection and retry.
You can avoid the mess of jumpers using the mikroProg to ST-Link v2 adapter
along with a 2x5, 10-wire ribbon cable connector:
You can avoid the mess of jumpers using the mikroProg to ST-Link v2 adapter
along with a 2x5, 10-wire ribbon cable connector:
https://shop.mikroe.com/add-on-boards/adapter/mikroprog-st-link-v2-adapter
Then you can use the ST-Link Utility or other debugger software to write
the NuttX binary to FLASH. OpenOCD can be used with the ST-Link to provide
a debug environment. The debug adaptor is NOT compatible with other JTAG
debuggers such as the Segger J-Link.
Then you can use the ST-Link Utility or other debugger software to write
the NuttX binary to FLASH. OpenOCD can be used with the ST-Link to provide
a debug environment. The debug adaptor is NOT compatible with other JTAG
debuggers such as the Segger J-Link.
Configurations
==============
Information Common to All Configurations
----------------------------------------
Each Clicker2 configuration is maintained in a sub-directory and can be
selected as follow:
Information Common to All Configurations
----------------------------------------
Each Clicker2 configuration is maintained in a sub-directory and can be
selected as follow::
tools/configure.sh clicker2-stm32:<subdir>
Before building, make sure the PATH environment variable includes the
correct path to the directory than holds your toolchain binaries.
Before building, make sure the PATH environment variable includes the
correct path to the directory than holds your toolchain binaries.
And then build NuttX by simply typing the following. At the conclusion of
the make, the nuttx binary will reside in an ELF file called, simply, nuttx.
And then build NuttX by simply typing the following. At the conclusion of
the make, the nuttx binary will reside in an ELF file called, simply, nuttx.::
make oldconfig
make
The <subdir> that is provided above as an argument to the tools/configure.sh
must be is one of the following.
The <subdir> that is provided above as an argument to the tools/configure.sh
must be is one of the following.
NOTES:
NOTES:
1. These configurations use the mconf-based configuration tool. To
change any of these configurations using that tool, you should:
1. These configurations use the mconf-based configuration tool. To
change any of these configurations using that tool, you should:
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
see additional README.txt files in the NuttX tools repository.
@ -185,9 +192,9 @@ Configurations
b. Execute 'make menuconfig' in nuttx/ in order to start the
reconfiguration process.
2. Unless stated otherwise, all configurations generate console
output on USART3, channel 0) as described above under "Serial
Console". The relevant configuration settings are listed below:
2. Unless stated otherwise, all configurations generate console
output on USART3, channel 0) as described above under "Serial
Console". The relevant configuration settings are listed below::
CONFIG_STM32_USART3=y
CONFIG_STM32_USART3_SERIALDRIVER=y
@ -203,52 +210,57 @@ Configurations
CONFIG_USART3_PARITY=0
CONFIG_USART3_2STOP=0
3. All of these configurations are set up to build under Linux using the
"GNU Tools for ARM Embedded Processors" that is maintained by ARM
(unless stated otherwise in the description of the configuration).
3. All of these configurations are set up to build under Linux using the
"GNU Tools for ARM Embedded Processors" that is maintained by ARM
(unless stated otherwise in the description of the configuration).
https://developer.arm.com/open-source/gnu-toolchain/gnu-rm
That toolchain selection can easily be reconfigured using
'make menuconfig'. Here are the relevant current settings:
That toolchain selection can easily be reconfigured using
'make menuconfig'. Here are the relevant current settings:
Build Setup::
Build Setup:
CONFIG_HOST_LINUX =y : Linux environment
System Type -> Toolchain:
System Type -> Toolchain::
CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : GNU ARM EABI toolchain
Configuration sub-directories
-----------------------------
Configuration sub-directories
-----------------------------
knsh:
This is identical to the nsh configuration below except that NuttX
is built as a protected mode, monolithic module and the user applications
are built separately.
knsh
----
It is recommends to use a special make command; not just 'make' but make
with the following two arguments:
This is identical to the nsh configuration below except that NuttX
is built as a protected mode, monolithic module and the user applications
are built separately.
It is recommends to use a special make command; not just 'make' but make
with the following two arguments::
make pass1 pass2
In the normal case (just 'make'), make will attempt to build both user-
and kernel-mode blobs more or less interleaved. This actual works!
However, for me it is very confusing so I prefer the above make command:
Make the user-space binaries first (pass1), then make the kernel-space
binaries (pass2)
In the normal case (just 'make'), make will attempt to build both user-
and kernel-mode blobs more or less interleaved. This actual works!
However, for me it is very confusing so I prefer the above make command:
Make the user-space binaries first (pass1), then make the kernel-space
binaries (pass2)
NOTES:
NOTES:
1. At the end of the build, there will be several files in the top-level
NuttX build directory:
1. At the end of the build, there will be several files in the top-level
NuttX build directory:
PASS1::
PASS1:
nuttx_user.elf - The pass1 user-space ELF file
nuttx_user.hex - The pass1 Intel HEX format file (selected in defconfig)
User.map - Symbols in the user-space ELF file
PASS2:
PASS2::
nuttx - The pass2 kernel-space ELF file
nuttx.hex - The pass2 Intel HEX file (selected in defconfig)
System.map - Symbols in the kernel-space ELF file
@ -257,12 +269,12 @@ Configurations
formats. The St-Link programmer will accept files in hex and .bin
formats.
2. Combining .hex files. If you plan to use the .hex files with your
debugger or FLASH utility, then you may need to combine the two hex
files into a single .hex file. Here is how you can do that.
2. Combining .hex files. If you plan to use the .hex files with your
debugger or FLASH utility, then you may need to combine the two hex
files into a single .hex file. Here is how you can do that.
a. The 'tail' of the nuttx.hex file should look something like this
(with my comments added):
a. The 'tail' of the nuttx.hex file should look something like this
(with my comments added)::
$ tail nuttx.hex
# 00, data records
@ -277,8 +289,8 @@ Configurations
Use an editor such as vi to remove the 05 and 01 records.
b. The 'head' of the nuttx_user.hex file should look something like
this (again with my comments added):
b. The 'head' of the nuttx_user.hex file should look something like
this (again with my comments added)::
$ head nuttx_user.hex
# 04, Extended Linear Address Record
@ -292,8 +304,8 @@ Configurations
Nothing needs to be done here. The nuttx_user.hex file should
be fine.
c. Combine the edited nuttx.hex and un-edited nuttx_user.hex
file to produce a single combined hex file:
c. Combine the edited nuttx.hex and un-edited nuttx_user.hex
file to produce a single combined hex file::
$ cat nuttx.hex nuttx_user.hex >combined.hex
@ -301,18 +313,19 @@ Configurations
If you do this a lot, you will probably want to invest a little time
to develop a tool to automate these steps.
mrf24j40-mac
mrf24j40-mac
------------
This is a version of nsh that was used for testing the MRF24J40 MAC be
as a character device. The most important configuration differences are
summarized below:
This is a version of nsh that was used for testing the MRF24J40 MAC be
as a character device. The most important configuration differences are
summarized below:
1. Support for the BEE click and SPI are in enabled in the mikroBUS1 slot:
1. Support for the BEE click and SPI are in enabled in the mikroBUS1 slot:
CONFIG_CLICKER2_STM32_MB1_BEE=y
CONFIG_CLICKER2_STM32_MB1_SPI=y
2. SPI support and STM32 SPI3, in particular, are enabled:
2. SPI support and STM32 SPI3, in particular, are enabled:
CONFIG_SPI=y
CONFIG_SPI_EXCHANGE=y
@ -320,7 +333,7 @@ Configurations
CONFIG_STM32_SPI=y
CONFIG_STM32_SPI3=y
4. Support for the IEEE802.15.4 "upper half" character driver is enabled:
4. Support for the IEEE802.15.4 "upper half" character driver is enabled:
CONFIG_WIRELESS=y
CONFIG_WIRELESS_IEEE802154=y
@ -330,13 +343,13 @@ Configurations
CONFIG_IEEE802154_IND_IRQRESERVE=10
CONFIG_IEEE802154_DEFAULT_EADDR=0x00fade00deadbeef
5. Support for the lower half MRF24J40 character driver is enabled
5. Support for the lower half MRF24J40 character driver is enabled
CONFIG_DRIVERS_WIRELESS=y
CONFIG_DRIVERS_IEEE802154=y
CONFIG_IEEE802154_MRF24J40=y
6. Support for the i8sak test program at apps/ieee802154 is enabled:
6. Support for the i8sak test program at apps/ieee802154 is enabled:
CONFIG_IEEE802154_LIBMAC=y
CONFIG_IEEE802154_LIBUTILS=y
@ -344,12 +357,12 @@ Configurations
CONFIG_IEEE802154_I8SAK_PRIORITY=100
CONFIG_IEEE802154_I8SAK_STACKSIZE=2048
7. Initialization hooks are provided to enable the MRF24J40 and to
7. Initialization hooks are provided to enable the MRF24J40 and to
register the radio character driver.
CONFIG_NSH_ARCHINIT=y
8. Configuration instructions: WPAN configuration must be performed
8. Configuration instructions: WPAN configuration must be performed
using the i8sak program. Detailed instructions are provided in a
README.txt file at apps/wireless/ieee802154/i8sak. You should make
sure that you are familiar with the content of that README.txt file.
@ -357,30 +370,31 @@ Configurations
Here is a quick "cheat sheet" for associated to setting up a
coordinator and associating with the WPAN:
1. Configure the Coordinator. On coordinator device do:
1. Configure the Coordinator. On coordinator device do:
nsh> i8 /dev/ieee0 startpan cd:ab
nsh> i8 acceptassoc
2. Associate an endpoint device with the WPAN. On the endpoint
2. Associate an endpoint device with the WPAN. On the endpoint
device:
nsh> i8 /dev/ieee0 assoc
mrf24j40-6lowpan
mrf24j40-6lowpan
----------------
This is another version of nsh that is very similar to the mrf24j40-mac
configuration but is focused on testing the IEEE 802.15.4 MAC
integration with the 6LoWPAN network stack. It derives directly from the
mrf24j40-mac and all NOTES provided there apply. Additional differences
are summarized below:
This is another version of nsh that is very similar to the mrf24j40-mac
configuration but is focused on testing the IEEE 802.15.4 MAC
integration with the 6LoWPAN network stack. It derives directly from the
mrf24j40-mac and all NOTES provided there apply. Additional differences
are summarized below:
NOTES:
NOTES:
1. You must have two clicker2-stm32 boards each with an MRF24J40 click
1. You must have two clicker2-stm32 boards each with an MRF24J40 click
board in order to run these tests.
2. This configuration differs from the mrf24j40-mac configuration in
2. This configuration differs from the mrf24j40-mac configuration in
that this configuration, like the usbnsh configuration, uses a USB
serial device for console I/O. Such a configuration is useful on the
Clicker2 STM32 which has no builtin RS-232 drivers and eliminates the
@ -390,25 +404,25 @@ Configurations
differences between the usbnsh or mrf24j40-mac configurations and this
configuration are listed in these NOTES.
3. On most serial terminal programs that I have used, the USB
3. On most serial terminal programs that I have used, the USB
connection will be lost when the target board is reset. When that
happens, you may have to reset your serial terminal program to adapt
to the new USB connection. Using TeraTerm, I actually have to exit
the serial program and restart it in order to detect and select the
re-established USB serial connection.
4. This configuration does NOT have USART3 output enabled. This
4. This configuration does NOT have USART3 output enabled. This
configuration supports logging of debug output to a circular
buffer in RAM. This feature is discussed fully in this Wiki page:
https://cwiki.apache.org/confluence/display/NUTTX/SYSLOG . Relevant
configuration settings are summarized below:
configuration settings are summarized below::
Device Drivers:
CONFIG_RAMLOG=y : Enable the RAM-based logging feature.
CONFIG_RAMLOG_SYSLOG=y : This enables the RAM-based logger as the
system logger.
CONFIG_RAMLOG_NONBLOCKING=y : Needs to be non-blocking for dmesg
CONFIG_RAMLOG_BUFSIZE=8192 : Buffer size is 8KiB
Device Drivers:
CONFIG_RAMLOG=y : Enable the RAM-based logging feature.
CONFIG_RAMLOG_SYSLOG=y : This enables the RAM-based logger as the
system logger.
CONFIG_RAMLOG_NONBLOCKING=y : Needs to be non-blocking for dmesg
CONFIG_RAMLOG_BUFSIZE=8192 : Buffer size is 8KiB
NOTE: This RAMLOG feature is really only of value if debug output
is enabled. But, by default, no debug output is disabled in this
@ -425,37 +439,37 @@ Configurations
the system has crashed because (a) it will be unresponsive and (b)
the LD2 will be blinking at about 2Hz.
5. IPv6 networking is enabled with TCP/IP, UDP, 6LoWPAN, and NSH
Telnet support.
5. IPv6 networking is enabled with TCP/IP, UDP, 6LoWPAN, and NSH
Telnet support.
6. Configuration instructions: Basic PAN configuration is similar to the
mrf24j40-mac configuration with the exception that you use the network
interface name 'wpan0'. This tells the i8sak app to use a socket
instead of a character device to perform the IOCTL operations with the
MAC. Additionally, after the PAN has been configured with the i8sak
utility, you must explicitly bring the network up on each node:
6. Configuration instructions: Basic PAN configuration is similar to the
mrf24j40-mac configuration with the exception that you use the network
interface name 'wpan0'. This tells the i8sak app to use a socket
instead of a character device to perform the IOCTL operations with the
MAC. Additionally, after the PAN has been configured with the i8sak
utility, you must explicitly bring the network up on each node::
nsh> ifup wpan0
7. examples/udp is enabled. This will allow two MRF24J40 nodes to
exchange UDP packets. Basic instructions:
7. examples/udp is enabled. This will allow two MRF24J40 nodes to
exchange UDP packets. Basic instructions:
On the server node:
On the server node::
nsh> ifconfig
nsh> udpserver &
The ifconfig command will show the IP address of the server. Then on
the client node use this IP address to start the client:
The ifconfig command will show the IP address of the server. Then on
the client node use this IP address to start the client::
nsh> udpclient <server-ip> &
Where <server-ip> is the IP address of the server that you got above.
NOTE: There is no way to stop the UDP test once it has been started
other than by resetting the board.
Where <server-ip> is the IP address of the server that you got above.
NOTE: There is no way to stop the UDP test once it has been started
other than by resetting the board.
Cheat Sheet. Here is a concise summary of all all the steps needed to
run the UDP test (C=Coordinator; E=Endpoint):
Cheat Sheet. Here is a concise summary of all all the steps needed to
run the UDP test (C=Coordinator; E=Endpoint)::
C: nsh> i8 wpan0 startpan cd:ab
C: nsh> i8 acceptassoc
@ -466,28 +480,28 @@ Configurations
C: nsh> udpserver &
E: nsh> udpclient <server-ip> &
The nsh> dmesg command can be use at any time on any node to see
any debug output that you have selected.
The nsh> dmesg command can be use at any time on any node to see
any debug output that you have selected.
8. examples/nettest is enabled. This will allow two MRF24J40 nodes to
exchange TCP packets. Basic instructions:
8. examples/nettest is enabled. This will allow two MRF24J40 nodes to
exchange TCP packets. Basic instructions:
On the server node:
On the server node::
nsh> ifconfig
nsh> tcpserver &
The ifconfig command will show the IP address of the server. Then on
the client node use this IP address to start the client:
The ifconfig command will show the IP address of the server. Then on
the client node use this IP address to start the client::
nsh> tcpclient <server-ip> &
Where <server-ip> is the IP address of the server that you got above.
NOTE: Unlike the UDP test, there the TCP test will terminate
automatically when the packet exchange is complete.
Where <server-ip> is the IP address of the server that you got above.
NOTE: Unlike the UDP test, there the TCP test will terminate
automatically when the packet exchange is complete.
Cheat Sheet. Here is a concise summary of all all the steps needed to
run the TCP test (C=Coordinator; E=Endpoint):
Cheat Sheet. Here is a concise summary of all all the steps needed to
run the TCP test (C=Coordinator; E=Endpoint)::
C: nsh> i8 wpan0 startpan cd:ab
C: nsh> i8 acceptassoc
@ -498,36 +512,36 @@ Configurations
C: nsh> tcpserver &
E: nsh> tcpclient <server-ip> &
The nsh> dmesg command can be use at any time on any node to see
any debug output that you have selected.
The nsh> dmesg command can be use at any time on any node to see
any debug output that you have selected.
9. The NSH Telnet daemon (server) is enabled. However, it cannot be
started automatically. Rather, it must be started AFTER the network
has been brought up using the NSH 'telnetd' command. You would want
to start the Telent daemon only if you want the node to serve Telent
connections to an NSH shell on the node.
9. The NSH Telnet daemon (server) is enabled. However, it cannot be
started automatically. Rather, it must be started AFTER the network
has been brought up using the NSH 'telnetd' command. You would want
to start the Telent daemon only if you want the node to serve Telent
connections to an NSH shell on the node.::
nsh> ifconfig
nsh> telnetd
Note the 'ifconfig' is executed to get the IP address of the node.
This is necessary because the IP address is assigned by the the
Coordinator and may not be known a priori.
Note the 'ifconfig' is executed to get the IP address of the node.
This is necessary because the IP address is assigned by the the
Coordinator and may not be known a priori.
10. This configuration also includes the Telnet client program. This
will allow you to execute a NSH one a node from the command line on
a different node. Like:
10. This configuration also includes the Telnet client program. This
will allow you to execute a NSH one a node from the command line on
a different node. Like::
nsh> telnet <server-ip>
Where <server-ip> is the IP address of the server that you got for
the ifconfig comma on the remote node. Once the telnet session
has been started, you can end the session with:
Where <server-ip> is the IP address of the server that you got for
the ifconfig comma on the remote node. Once the telnet session
has been started, you can end the session with::
nsh> exit
Cheat Sheet. Here is a concise summary of all all the steps needed to
run the TCP test (C=Coordinator; E=Endpoint):
Cheat Sheet. Here is a concise summary of all all the steps needed to
run the TCP test (C=Coordinator; E=Endpoint)::
C: nsh> i8 wpan0 startpan
C: nsh> i8 acceptassoc
@ -562,19 +576,20 @@ Configurations
support, Telnet worked just fine.
Test Matrix:
The following configurations have been tested:
The following configurations have been tested::
TEST DATE
COMPRESSION ADDRESSING UDP TCP
----------- ---------- ---- ----
hc06 short 6/21 6/25
extended 6/22 6/26
hc1 short 6/23 6/26
extended 6/23 6/26
ipv6 short --- ---
extended --- ---
telnet short N/A 6/27 (hc06)
extended N/A ---
=========== ========== ==== ====
COMPRESSION ADDRESSING UDP TCP
=========== ========== ==== ====
hc06 short 6/21 6/25
extended 6/22 6/26
hc1 short 6/23 6/26
extended 6/23 6/26
ipv6 short --- ---
extended --- ---
telnet short N/A 6/27 (hc06)
extended N/A ---
=========== ========== ==== ====
Other configuration options have not been specifically addressed
(such non-compressable ports, non-MAC based IPv6 addresses, etc.)
@ -585,17 +600,18 @@ Configurations
potentially be verifying only that the design is implemented
incorrectly in compatible way on both the client and server sides.
mrf24j40-starhub and mrf24j40-starpoint
mrf24j40-starhub and mrf24j40-starpoint
----------------------------------------
These two configurations implement hub and and star endpoint in a
star topology. Both configurations derive from the mrf24j40-6lowpan
configuration and most of the notes there apply here as well.
These two configurations implement hub and and star endpoint in a
star topology. Both configurations derive from the mrf24j40-6lowpan
configuration and most of the notes there apply here as well.
1. You must have three clicker2-stm32 boards each with an MRF24J40
1. You must have three clicker2-stm32 boards each with an MRF24J40
click board in order to run these tests: One that serves as the
star hub and at least two star endpoints.
2. The star point configuration differs from the primarily in the
2. The star point configuration differs from the primarily in the
mrf24j40-6lowpan in following is also set:
CONFIG_NET_STAR=y
@ -616,20 +632,20 @@ Configurations
receives any packets that are not destined for the hub, it should
forward those packets appropriately.
3. Telnet: The star point configuration supports the Telnet daemon,
3. Telnet: The star point configuration supports the Telnet daemon,
but not the Telnet client; the star hub configuration supports
the Telnet client, but not the Telnet daemon. Therefore, the
star hub can Telnet to any point in the star, the star endpoints
cannot initiate telnet sessions.
4. TCP and UDP Tests: The same TCP and UDP tests as described for
4. TCP and UDP Tests: The same TCP and UDP tests as described for
the mrf24j40-6lowpan coniguration are supported on the star
endpoints, but NOT on the star hub. Therefore, all network testing
is between endpoints with the hub acting, well, only like a hub.
The modified usage of the TCP test is show below with E1 E2
representing the two star endpoints and C: representing the
coordinator/hub.
coordinator/hub.::
C: nsh> i8 wpan0 startpan cd:ab
C: nsh> i8 acceptassoc
@ -647,7 +663,7 @@ Configurations
Where <server-ip> is the IP address of the E1 endpoint.
Similarly for the UDP test:
Similarly for the UDP test:::
E1: nsh> udpserver &
E2: nsh> udpclient <server-ip> &
@ -656,7 +672,7 @@ Configurations
any debug output that you have selected.
Telenet sessions may be initiated only from the hub to a star
endpoint:
endpoint::
C: nsh> telnet <server-ip> <-- Runs the Telnet client
@ -696,80 +712,85 @@ Configurations
incoming streams. The design was extended to support multiple
reassembly buffers but have not yet been verified on this platform.
nsh:
nsh
----
Configures the NuttShell (nsh) located at examples/nsh. This
configuration is focused on low level, command-line driver testing. It
has no network.
Configures the NuttShell (nsh) located at examples/nsh. This
configuration is focused on low level, command-line driver testing. It
has no network.
NOTES:
NOTES:
1. Support for NSH built-in applications is provided:
1. Support for NSH built-in applications is provided:
Binary Formats:
CONFIG_BUILTIN=y : Enable support for built-in programs
Binary Formats::
Application Configuration:
CONFIG_NSH_BUILTIN_APPS=y : Enable starting apps from NSH command line
CONFIG_BUILTIN=y : Enable support for built-in programs
No built applications are enabled in the base configuration, however.
Application Configuration::
2. C++ support for applications is enabled:
CONFIG_NSH_BUILTIN_APPS=y : Enable starting apps from NSH command line
No built applications are enabled in the base configuration, however.
2. C++ support for applications is enabled::
CONFIG_HAVE_CXX=y
CONFIG_HAVE_CXXINITIALIZE=y
usbnsh:
usbnsh
------
This is another NSH example. If differs from other 'nsh' configurations
in that this configurations uses a USB serial device for console I/O.
Such a configuration is useful on the Clicker2 STM32 which has no
builtin RS-232 drivers.
This is another NSH example. If differs from other 'nsh' configurations
n that this configurations uses a USB serial device for console I/O.
Such a configuration is useful on the Clicker2 STM32 which has no
builtin RS-232 drivers.
NOTES:
NOTES:
1. One most serial terminal programs that I have used, the USB
1. One most serial terminal programs that I have used, the USB
connection will be lost when the target board is reset. When that
happens, you may have to reset your serial terminal program to adapt
to the new USB connection. Using TeraTerm, I actually have to exit
the serial program and restart it in order to detect and select the
re-established USB serial connection.
2. This configuration does have USART3 output enabled and set up as
the system logging device:
2. This configuration does have USART3 output enabled and set up as
the system logging device::
CONFIG_SYSLOG_CHAR=y : Use a character device for system logging
CONFIG_SYSLOG_DEVPATH="/dev/ttyS0" : USART3 will be /dev/ttyS0
CONFIG_SYSLOG_CHAR=y : Use a character device for system logging
CONFIG_SYSLOG_DEVPATH="/dev/ttyS0" : USART3 will be /dev/ttyS0
However, there is nothing to generate SYSLOG output in the default
configuration so nothing should appear on USART3 unless you enable
some debug output or enable the USB monitor.
3. Enabling USB monitor SYSLOG output. If tracing is enabled, the USB
3. Enabling USB monitor SYSLOG output. If tracing is enabled, the USB
device will save encoded trace output in in-memory buffer; if the
USB monitor is enabled, that trace buffer will be periodically
emptied and dumped to the system logging device (USART3 in this
configuration):
configuration)::
CONFIG_USBDEV_TRACE=y : Enable USB trace feature
CONFIG_USBDEV_TRACE_NRECORDS=128 : Buffer 128 records in memory
CONFIG_NSH_USBDEV_TRACE=n : No builtin tracing from NSH
CONFIG_NSH_ARCHINIT=y : Automatically start the USB monitor
CONFIG_USBMONITOR=y : Enable the USB monitor daemon
CONFIG_USBMONITOR_STACKSIZE=2048 : USB monitor daemon stack size
CONFIG_USBMONITOR_PRIORITY=50 : USB monitor daemon priority
CONFIG_USBMONITOR_INTERVAL=2 : Dump trace data every 2 seconds
CONFIG_USBDEV_TRACE=y : Enable USB trace feature
CONFIG_USBDEV_TRACE_NRECORDS=128 : Buffer 128 records in memory
CONFIG_NSH_USBDEV_TRACE=n : No builtin tracing from NSH
CONFIG_NSH_ARCHINIT=y : Automatically start the USB monitor
CONFIG_USBMONITOR=y : Enable the USB monitor daemon
CONFIG_USBMONITOR_STACKSIZE=2048 : USB monitor daemon stack size
CONFIG_USBMONITOR_PRIORITY=50 : USB monitor daemon priority
CONFIG_USBMONITOR_INTERVAL=2 : Dump trace data every 2 seconds
CONFIG_USBMONITOR_TRACEINIT=y : Enable TRACE output
CONFIG_USBMONITOR_TRACECLASS=y
CONFIG_USBMONITOR_TRACETRANSFERS=y
CONFIG_USBMONITOR_TRACECONTROLLER=y
CONFIG_USBMONITOR_TRACEINTERRUPTS=y
CONFIG_USBMONITOR_TRACEINIT=y : Enable TRACE output
CONFIG_USBMONITOR_TRACECLASS=y
CONFIG_USBMONITOR_TRACETRANSFERS=y
CONFIG_USBMONITOR_TRACECONTROLLER=y
CONFIG_USBMONITOR_TRACEINTERRUPTS=y
Using the Prolifics PL2303 Emulation
------------------------------------
You could also use the non-standard PL2303 serial device instead of
the standard CDC/ACM serial device by changing:
Using the Prolifics PL2303 Emulation
------------------------------------
You could also use the non-standard PL2303 serial device instead of
the standard CDC/ACM serial device by changing::
CONFIG_CDCACM=n : Disable the CDC/ACM serial device class
CONFIG_CDCACM_CONSOLE=n : The CDC/ACM serial device is NOT the console

372
Documentation/platforms/arm/stm32f4/boards/mikroe-stm32f4/index.rst Normal file
View File

@ -0,0 +1,372 @@
==============
mikroe-stm32f4
==============
This README discusses issues unique to NuttX configurations for the
MikroElektronika Mikromedia for STM32F4 development board. This is
another board support by NuttX that uses the same STM32F407VGT6 MCU
as does the STM32F4-Discovery board. This board, however, has very
different on-board peripherals than does the STM32F4-Discovery:
- TFT display with touch panel,
- VS1053 stereo audio codec with headphone jack,
- SD card slot,
- Serial FLASH memory,
- USB OTG FS with micro-AB connector, and
- Battery connect and batter charger circuit.
See the http://www.mikroe.com/mikromedia/stm32-m4/ for more information
about this board.
LEDs
====
The Mikroe-STM32F4 board has no user accessible LEDs onboard, only a power
and "charging" LED. All visual user output must be performed through the TFT
display.
External LEDs could be added via the expansion headers on the side of the
board, but as this would be a custom configuration, LEDs are not supported
in this port.
PWM
===
The Mikroe-STM32F4 has no real on-board PWM devices, but it does have PWM
pins routed to the expansion I/O headers on the side of the board.
UARTs
=====
The Mikroe-STM32F4 board has no onboard RS-232 line driver, however the
expansion I/O header provides access to USART2 on pins PD5/PD6. The port
includes support for USART2 configured as /dev/ttyS0.
USART2
------
========== =====
UART/USART PINS
========== =====
RX PD6
TX PD5
========== =====
Default USART/UART Configuration
--------------------------------
USART2 is enabled in all configurations (see \*/defconfig). RX and TX are
configured on pins PD6 and PD5, respectively (see include/board.h).
Timer Inputs/Outputs
====================
::
TIM1
CH1 PA8, PE9
CH2 PA9[1], PE11
CH3 PA10[1], PE13
CH4 PA11[1], PE14
TIM2
CH1 PA0[1], PA15, PA5[1]
CH2 PA1, PB3[1]
CH3 PA2, PB10[1]
CH4 PA3, PB11
TIM3
CH1 PA6[1], PB4, PC6
CH2 PA7[1], PB5, PC7[1]
CH3 PB0, PC8
CH4 PB1, PC9
TIM4
CH1 PB6[1], PD12[1]
CH2 PB7, PD13[1]
CH3 PB8, PD14[1]
CH4 PB9[1], PD15[1]
TIM5
CH1 PA0[1], PH10[2]
CH2 PA1, PH11[2]
CH3 PA2, PH12[2]
CH4 PA3, PI0
TIM8
CH1 PC6, PI5
CH2 PC7[1], PI6
CH3 PC8, PI7
CH4 PC9, PI2
TIM9
CH1 PA2, PE5
CH2 PA3, PE6
TIM10
CH1 PB8, PF6
TIM11
CH1 PB9[1], PF7
TIM12
CH1 PH6[2], PB14
CH2 PC15, PH9[2]
TIM13
CH1 PA6[1], PF8
TIM14
CH1 PA7[1], PF9
[1] Indicates pins that have other on-board functions and should be used only
with care (See table 5 in the Mikroe-STM32F4 User Guide). The rest are
free I/O pins.
[2] Port H pins are not supported by the MCU
MIO283QT-2/MIO283QT-9A
======================
The original Mikroe-SMT32F4 board as an on-board MIO283QT-2 TFT LCD that can
be configured and used. This is a 320x240 resolution display with color
capability to 262K colors, though the mio283qt-2 driver in NuttX only
supports 16-bit color depth, or 65K colors. Changes to both the
mio283qt-2 driver and the driver interface layer would need to be made
to support 24 BPP mode.
UPDATE: New boards now support a MIO283QT-9A TFT LCD that is not compatible
with the MIO283QT-2. It uses a different LCD controller. The default in
all of these configurations is the MIO283QT-2. But MIO283QT-9A is also
supported and you can switch from the MIO283QT-2 to the MIO283QT-9A by simply
modifying the NuttX configuration
Configurations
==============
Each Mikroe-STM32F4 configuration is maintained in a sub-directory and
can be selected as follow::
tools/configure.sh mikroe-stm32f4:<subdir>
If this is a Windows native build, then configure.bat should be used
instead of configure.sh::
configure.bat Mikroe-STM32F4\<subdir>
Where <subdir> is one of the following:
fulldemo
--------
This is an example that includes an NSH shell over USB that also
enables all features of the Mikroe-STM32F4 board including the LCD,
on-board 1M Flash with SMART filesystem, Aux RS-232 serial port on the
expansion header, etc. A couple of the NX graphics commands are made
available via the NSH prompt for performing LCD demonstrations, and the
nximage example is used as a splash-screen at startup.
kostest
-------
NOTE: This configuration compiles, but has not been fully tested
on the hardware yet.
This configuration directory, performs a simple OS test using
apps/examples/ostest with NuttX build as a kernel-mode monolithic
module and the user applications are built separately. Is
is recommended to use a special make command; not just 'make' but
make with the following two arguments::
make pass1 pass2
In the normal case (just 'make'), make will attempt to build both user-
and kernel-mode blobs more or less interleaved. This actual works!
However, for me it is very confusing so I prefer the above make command:
Make the user-space binaries first (pass1), then make the kernel-space
binaries (pass2)
NOTES:
1. This configuration uses the mconf-based configuration tool. To
change this configuration using that tool, you should:
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
see additional README.txt files in the NuttX tools repository.
b. Execute 'make menuconfig' in nuttx/ in order to start the
reconfiguration process.
2. This is the default platform/toolchain in the configuration::
CONFIG_HOST_WINDOWS=y : Windows
CONFIG_WINDOWS_CYGWIN=y : Cygwin environment on Windows
CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : GNU EABI toolchain for Windows
This is easily changed by modifying the configuration.
3. At the end of the build, there will be several files in the top-level
NuttX build directory::
PASS1:
nuttx_user.elf - The pass1 user-space ELF file
nuttx_user.hex - The pass1 Intel HEX format file (selected in defconfig)
User.map - Symbols in the user-space ELF file
PASS2:
nuttx - The pass2 kernel-space ELF file
nuttx.hex - The pass2 Intel HEX file (selected in defconfig)
System.map - Symbols in the kernel-space ELF file
4. Combining .hex files. If you plan to use the STM32 ST-Link Utility to
load the .hex files into FLASH, then you need to combine the two hex
files into a single .hex file. Here is how you can do that.
a. The 'tail' of the nuttx.hex file should look something like this
(with my comments added)::
$ tail nuttx.hex
# 00, data records
...
:10 9DC0 00 01000000000800006400020100001F0004
:10 9DD0 00 3B005A0078009700B500D400F300110151
:08 9DE0 00 30014E016D0100008D
# 05, Start Linear Address Record
:04 0000 05 0800 0419 D2
# 01, End Of File record
:00 0000 01 FF
Use an editor such as vi to remove the 05 and 01 records.
b. The 'head' of the nuttx_user.hex file should look something like
this (again with my comments added)::
$ head nuttx_user.hex
# 04, Extended Linear Address Record
:02 0000 04 0801 F1
# 00, data records
:10 8000 00 BD89 01084C800108C8110208D01102087E
:10 8010 00 0010 00201C1000201C1000203C16002026
:10 8020 00 4D80 01085D80010869800108ED83010829
...
Nothing needs to be done here. The nuttx_user.hex file should
be fine.
c. Combine the edited nuttx.hex and un-edited nuttx_user.hex
file to produce a single combined hex file::
$ cat nuttx.hex nuttx_user.hex >combined.hex
Then use the combined.hex file with the STM32 ST-Link tool. If
you do this a lot, you will probably want to invest a little time
to develop a tool to automate these steps.
nsh
---
This is an NSH example that uses USART2 as the console. Note that
the Mikroe-STM32F4 board doesn't actually have onboard line drivers
or a connector for USART2, but it does route the USART2 signals to
the expansion header. To use this demo, you would need to connect
an external 3.3V RS-232 line driver to the USART's I/O lines on the
expansion header.
NOTE: This demo doesn't quite work yet. I can get output to the
USART, but so far, I have not gotten nsh to actually come up.
nx
--
An example using the NuttX graphics system (NX). This example
focuses on general window controls, movement, mouse and keyboard
input.::
CONFIG_LCD_LANDSCAPE=y : 320x240 landscape orientation
CONFIG_LCD_MIO283QT2=y : MIO283QT-2 is the default
You can the newer MIO283QT-9A by enabling it in the configuration.::
CONFIG_LCD_MIO283QT2=n : Disable the MIO283QT-2
CONFIG_LCD_MIO283QT9A=y : Enable the MIO283QT-9A
nxlines
-------
An example using the NuttX graphics system (NX). This example focuses on
placing lines on the background in various orientations using the
on-board TFT LCD.::
CONFIG_LCD_LANDSCAPE=y : 320x240 landscape orientation
CONFIG_LCD_MIO283QT2=y : MIO283QT-2 is the default
You can the newer MIO283QT-9A by enabling it in the configuration.::
CONFIG_LCD_MIO283QT2=n : Disable the MIO283QT-2
CONFIG_LCD_MIO283QT9A=y : Enable the MIO283QT-9A
nxtext
------
Another example using the NuttX graphics system (NX). This
example focuses on placing text on the background while pop-up
windows occur. Text should continue to update normally with
or without the popup windows present.
usbnsh
-------
This is another NSH example. If differs from other 'nsh' configurations
in that this configurations uses a USB serial device for console I/O.
Such a configuration is useful on the stm32f4discovery which has no
builtin RS-232 drivers.
NOTES:
1. This configuration uses the mconf-based configuration tool. To
change this configuration using that tool, you should:
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
see additional README.txt files in the NuttX tools repository.
b. Execute 'make menuconfig' in nuttx/ in order to start the
reconfiguration process.
2. By default, this configuration uses the ARM EABI toolchain
for Windows and builds under Cygwin (or probably MSYS). That
can easily be reconfigured, of course.::
CONFIG_HOST_WINDOWS=y : Builds under Windows
CONFIG_WINDOWS_CYGWIN=y : Using Cygwin
CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : GNU EABI toolchain for Windows
3. This configuration does have UART2 output enabled and set up as
the system logging device::
CONFIG_SYSLOG_CHAR=y : Use a character device for system logging
CONFIG_SYSLOG_DEVPATH="/dev/ttyS0" : UART2 will be /dev/ttyS0
However, there is nothing to generate SYSLOG output in the default
configuration so nothing should appear on UART2 unless you enable
some debug output or enable the USB monitor.
4. Enabling USB monitor SYSLOG output. If tracing is enabled, the USB
device will save encoded trace output in in-memory buffer; if the
USB monitor is enabled, that trace buffer will be periodically
emptied and dumped to the system logging device (UART2 in this
configuration)::
CONFIG_USBDEV_TRACE=y : Enable USB trace feature
CONFIG_USBDEV_TRACE_NRECORDS=128 : Buffer 128 records in memory
CONFIG_NSH_USBDEV_TRACE=n : No builtin tracing from NSH
CONFIG_NSH_ARCHINIT=y : Automatically start the USB monitor
CONFIG_USBMONITOR=y : Enable the USB monitor daemon
CONFIG_USBMONITOR_STACKSIZE=2048 : USB monitor daemon stack size
CONFIG_USBMONITOR_PRIORITY=50 : USB monitor daemon priority
CONFIG_USBMONITOR_INTERVAL=2 : Dump trace data every 2 seconds
CONFIG_USBMONITOR_TRACEINIT=y : Enable TRACE output
CONFIG_USBMONITOR_TRACECLASS=y
CONFIG_USBMONITOR_TRACETRANSFERS=y
CONFIG_USBMONITOR_TRACECONTROLLER=y
CONFIG_USBMONITOR_TRACEINTERRUPTS=y
5. By default, this project assumes that you are *NOT* using the DFU bootloader.
Using the Prolifics PL2303 Emulation
------------------------------------
You could also use the non-standard PL2303 serial device instead of
the standard CDC/ACM serial device by changing::
CONFIG_CDCACM=y : Disable the CDC/ACM serial device class
CONFIG_CDCACM_CONSOLE=y : The CDC/ACM serial device is NOT the console
CONFIG_PL2303=y : The Prolifics PL2303 emulation is enabled
CONFIG_PL2303_CONSOLE=y : The PL2303 serial device is the console

394
Documentation/platforms/arm/stm32f4/boards/nucleo-f401re/index.rst Normal file
View File

@ -0,0 +1,394 @@
================
ST Nucleo F401RE
================
This page discusses issues unique to NuttX configurations for the ST
NucleoF401RE and NucleoF411RE boards from ST Micro. See
http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1577/LN1810/PF258797
http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1577/LN1877/PF260049
These two boards are very similar, both supporting STM32 "Dynamic Efficiency
Line" parts but differing in the specific STM32 chip mounted on board. The
chips themselves are also very similar with the STM32F411RE having some
additional capability:
NucleoF401RE:
- Microprocessor: 32-bit ARM Cortex M4 at 84MHz STM32F104RE
- Memory: 512 KB Flash and 96 KB SRAM
- ADC: 1×12-bit, 2.4 MSPS A/D converter: up to 10 channels
- DMA: 16-stream DMA controllers with FIFOs and burst support
- Timers: Up to 11 timers: up to six 16-bit, two 32-bit timers, two
watchdog timers, and a SysTick timer
- GPIO: Up to 81 I/O ports with interrupt capability
- I2C: Up to 3 × I2C interfaces
- USARTs: Up to 3 USARTs
- SPIs: Up to 4 SPIs (2 I2S)
- SDIO interface
- USB: USB 2.0 full-speed device/host/OTG controller with on-chip PHY
- CRC calculation unit
- RTC
The NucleoF411RE also has additional DMA and SPI peripheral capabilities.
Board features, however, are identical:
- Peripherals: 1 led, 1 push button
- Debug: Serial wire debug and JTAG interfaces
- Expansion I/F Ardino and Morpho Headers
Uses a STM32F103 to provide a ST-Link for programming, debug similar to the
OpenOcd FTDI function - USB to JTAG front-end.
See http://mbed.org/platforms/ST-Nucleo-F401RE and
http://developer.mbed.org/platforms/ST-Nucleo-F411RE for more
information about these boards.
mbed
====
The Nucleo-F401RE includes boot loader from mbed:
https://mbed.org/platforms/ST-Nucleo-F401RE/
https://mbed.org/handbook/Homepage
Using the mbed loader:
1. Connect the Nucleo-F4x1RE to the host PC using the USB connector.
2. A new file system will appear called NUCLEO; open it with Windows
Explorer (assuming that you are using Windows).
3. Drag and drop nuttx.bin into the MBED window. This will load the
nuttx.bin binary into the Nucleo-F4x1RE. The NUCLEO window will
close then re-open and the Nucleo-F4x1RE will be running the new code.
Hardware
========
GPIO
----
::
SERIAL_TX=PA_2 USER_BUTTON=PC_13
SERIAL_RX=PA_3 LED1 =PA_5
A0=PA_0 USART2RX D0=PA_3 D8 =PA_9
A1=PA_1 USART2TX D1=PA_2 D9 =PC_7
A2=PA_4 D2=PA_10 WIFI_CS=D10=PB_6 SPI_CS
A3=PB_0 WIFI_INT=D3=PB_3 D11=PA_7 SPI_MOSI
A4=PC_1 SDCS=D4=PB_5 D12=PA_6 SPI_MISO
A5=PC_0 WIFI_EN=D5=PB_4 LED1=D13=PA_5 SPI_SCK
LED2=D6=PB_10 I2C1_SDA=D14=PB_9 Probe
D7=PA_8 I2C1_SCL=D15=PB_8 Probe
From: https://mbed.org/platforms/ST-Nucleo-F401RE/
Buttons
-------
B1 USER: the user button is connected to the I/O PC13 (pin 2) of the STM32
microcontroller.
LEDs
----
The Nucleo F401RE and Nucleo F411RE provide a single user LED, LD2. LD2
is the green LED connected to Arduino signal D13 corresponding to MCU I/O
PA5 (pin 21) or PB13 (pin 34) depending on the STM32target.
- When the I/O is HIGH value, the LED is on.
- When the I/O is LOW, the LED is off.
These LEDs are not used by the board port unless CONFIG_ARCH_LEDS is
defined. In that case, the usage by the board port is defined in
include/board.h and src/sam_leds.c. The LEDs are used to encode OS-related
events as follows when the red LED (PE24) is available:
=================== ======================= ===========
SYMBOL Meaning LD2
=================== ======================= ===========
LED_STARTED NuttX has been started OFF
LED_HEAPALLOCATE Heap has been allocated OFF
LED_IRQSENABLED Interrupts enabled OFF
LED_STACKCREATED Idle stack created ON
LED_INIRQ In an interrupt No change
LED_SIGNAL In a signal handler No change
LED_ASSERTION An assertion failed No change
LED_PANIC The system has crashed Blinking
LED_IDLE MCU is is sleep mode Not used
=================== ======================= ===========
Thus if LD2, NuttX has successfully booted and is, apparently, running
normally. If LD2 is flashing at approximately 2Hz, then a fatal error
has been detected and the system has halted.
Serial Consoles
===============
USART1
------
Pins and Connectors::
RXD: PA11 CN10 pin 14
PB7 CN7 pin 21
TXD: PA10 CN9 pin 3, CN10 pin 33
PB6 CN5 pin 3, CN10 pin 17
NOTE: You may need to edit the include/board.h to select different USART1
pin selections.
TTL to RS-232 converter connection::
Nucleo CN10 STM32F4x1RE
----------- ------------
Pin 21 PA9 USART1_RX *Warning you make need to reverse RX/TX on
Pin 33 PA10 USART1_TX some RS-232 converters
Pin 20 GND
Pin 8 U5V
To configure USART1 as the console::
CONFIG_STM32_USART1=y
CONFIG_USART1_SERIALDRIVER=y
CONFIG_USART1_SERIAL_CONSOLE=y
CONFIG_USART1_RXBUFSIZE=256
CONFIG_USART1_TXBUFSIZE=256
CONFIG_USART1_BAUD=115200
CONFIG_USART1_BITS=8
CONFIG_USART1_PARITY=0
CONFIG_USART1_2STOP=0
USART2
------
Pins and Connectors::
RXD: PA3 CN9 pin 1 (See SB13, 14, 62, 63). CN10 pin 37
PD6
TXD: PA2 CN9 pin 2(See SB13, 14, 62, 63). CN10 pin 35
PD5
UART2 is the default in all of these configurations.
TTL to RS-232 converter connection::
Nucleo CN9 STM32F4x1RE
----------- ------------
Pin 1 PA3 USART2_RX *Warning you make need to reverse RX/TX on
Pin 2 PA2 USART2_TX some RS-232 converters
Solder Bridges. This configuration requires:
- SB62 and SB63 Closed: PA2 and PA3 on STM32 MCU are connected to D1 and D0
(pin 7 and pin 8) on Arduino connector CN9 and ST Morpho connector CN10
as USART signals. Thus SB13 and SB14 should be OFF.
- SB13 and SB14 Open: PA2 and PA3 on STM32F103C8T6 (ST-LINK MCU) are
disconnected to PA3 and PA2 on STM32 MCU.
To configure USART2 as the console::
CONFIG_STM32_USART2=y
CONFIG_USART2_SERIALDRIVER=y
CONFIG_USART2_SERIAL_CONSOLE=y
CONFIG_USART2_RXBUFSIZE=256
CONFIG_USART2_TXBUFSIZE=256
CONFIG_USART2_BAUD=115200
CONFIG_USART2_BITS=8
CONFIG_USART2_PARITY=0
CONFIG_USART2_2STOP=0
USART6
------
Pins and Connectors::
RXD: PC7 CN5 pin2, CN10 pin 19
PA12 CN10, pin 12
TXD: PC6 CN10, pin 4
PA11 CN10, pin 14
To configure USART6 as the console::
CONFIG_STM32_USART6=y
CONFIG_USART6_SERIALDRIVER=y
CONFIG_USART6_SERIAL_CONSOLE=y
CONFIG_USART6_RXBUFSIZE=256
CONFIG_USART6_TXBUFSIZE=256
CONFIG_USART6_BAUD=115200
CONFIG_USART6_BITS=8
CONFIG_USART6_PARITY=0
CONFIG_USART6_2STOP=0
Virtual COM Port
----------------
Yet another option is to use UART2 and the USB virtual COM port. This
option may be more convenient for long term development, but is painful
to use during board bring-up.
Solder Bridges. This configuration requires:
- SB62 and SB63 Open: PA2 and PA3 on STM32 MCU are disconnected to D1
and D0 (pin 7 and pin 8) on Arduino connector CN9 and ST Morpho
connector CN10.
- SB13 and SB14 Closed: PA2 and PA3 on STM32F103C8T6 (ST-LINK MCU) are
connected to PA3 and PA2 on STM32 MCU to have USART communication
between them. Thus SB61, SB62 and SB63 should be OFF.
Configuring USART2 is the same as given above.
Question: What BAUD should be configure to interface with the Virtual
COM port? 115200 8N1?
Default
-------
As shipped, SB62 and SB63 are open and SB13 and SB14 closed, so the
virtual COM port is enabled.
Shields
=======
RS-232 from Cutedigi.com
------------------------
Supports a single RS-232 connected via::
Nucleo CN9 STM32F4x1RE Cutedigi
----------- ------------ --------
Pin 1 PA3 USART2_RX RXD
Pin 2 PA2 USART2_TX TXD
Support for this shield is enabled by selecting USART2 and configuring
SB13, 14, 62, and 63 as described above under "Serial Consoles"
Itead Joystick Shield
---------------------
See http://imall.iteadstudio.com/im120417014.html for more information
about this joystick.
Itead Joystick Connection::
--------- ----------------- ---------------------------------
ARDUINO ITEAD NUCLEO-F4x1
PIN NAME SIGNAL SIGNAL
--------- ----------------- ---------------------------------
D3 Button E Output PB3
D4 Button D Output PB5
D5 Button C Output PB4
D6 Button B Output PB10
D7 Button A Output PA8
D8 Button F Output PA9
D9 Button G Output PC7
A0 Joystick Y Output PA0 ADC1_0
A1 Joystick X Output PA1 ADC1_1
--------- ----------------- ---------------------------------
All buttons are pulled on the shield. A sensed low value indicates
when the button is pressed.
NOTE: Button F cannot be used with the default USART1 configuration
because PA9 is configured for USART1_RX by default. Use select
different USART1 pins in the board.h file or select a different
USART or select CONFIG_NUCLEO_F401RE_AJOY_MINBUTTONS which will
eliminate all but buttons A, B, and C.
Itead Joystick Signal interpretation::
--------- ----------------------- ---------------------------
BUTTON TYPE NUTTX ALIAS
--------- ----------------------- ---------------------------
Button A Large button A JUMP/BUTTON 3
Button B Large button B FIRE/BUTTON 2
Button C Joystick select button SELECT/BUTTON 1
Button D Tiny Button D BUTTON 6
Button E Tiny Button E BUTTON 7
Button F Large Button F BUTTON 4
Button G Large Button G BUTTON 5
--------- ----------------------- ---------------------------
Itead Joystick configuration settings::
System Type -> STM32 Peripheral Support
CONFIG_STM32_ADC1=y : Enable ADC1 driver support
Drivers
CONFIG_ANALOG=y : Should be automatically selected
CONFIG_ADC=y : Should be automatically selected
CONFIG_INPUT=y : Select input device support
CONFIG_INPUT_AJOYSTICK=y : Select analog joystick support
There is nothing in the configuration that currently uses the joystick.
For testing, you can add the following configuration options to enable the
analog joystick example at apps/examples/ajoystick::
CONFIG_NSH_ARCHINIT=y
CONFIG_EXAMPLES_AJOYSTICK=y
CONFIG_EXAMPLES_AJOYSTICK_DEVNAME="/dev/ajoy0"
STATUS:
2014-12-04:
- Without ADC DMA support, it is not possible to sample both X and Y
with a single ADC. Right now, only one axis is being converted.
- There is conflicts with some of the Arduino data pins and the
default USART1 configuration. I am currently running with USART1
but with CONFIG_NUCLEO_F401RE_AJOY_MINBUTTONS to eliminate the
conflict.
- Current showstopper: I appear to be getting infinite interrupts as
soon as joystick button interrupts are enabled.
Configurations
==============
f401-nsh:
---------
Configures the NuttShell (nsh) located at apps/examples/nsh for the
Nucleo-F401RE board. The Configuration enables the serial interfaces
on UART2. Support for builtin applications is enabled, but in the base
configuration no builtin applications are selected (see NOTES below).
NOTES:
1. This configuration uses the mconf-based configuration tool. To
change this configuration using that tool, you should:
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
see additional README.txt files in the NuttX tools repository.
b. Execute 'make menuconfig' in nuttx/ in order to start the
reconfiguration process.
2. By default, this configuration uses the ARM EABI toolchain
for Linux. That can easily be reconfigured, of course.:
CONFIG_HOST_LINUX=y : Builds under Linux
CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : GNU EABI toolchain for Linux
3. Although the default console is USART2 (which would correspond to
the Virtual COM port) I have done all testing with the console
device configured for USART1 (see instruction above under "Serial
Consoles). I have been using a TTL-to-RS-232 converter connected
as shown below::
Nucleo CN10 STM32F4x1RE
----------- ------------
Pin 21 PA9 USART1_RX *Warning you make need to reverse RX/TX on
Pin 33 PA10 USART1_TX some RS-232 converters
Pin 20 GND
Pin 8 U5V
f411-nsh
--------
This configuration is the same as the f401-nsh configuration, except
that it is configured to support the Nucleo-F411RE.

223
Documentation/platforms/arm/stm32f4/boards/nucleo-f410rb/index.rst Normal file
View File

@ -0,0 +1,223 @@
================
ST Nucleo F410RB
================
This page discusses issues unique to NuttX configurations for the ST
Nucleo F410RB board from ST Micro. See
http://www.st.com/en/evaluation-tools/nucleo-f410rb.html
NucleoF410RB:
- Microprocessor: 32-bit ARM Cortex M4 at 100MHz STM32F410RB
- Memory: 128 KB Flash and 32 KB SRAM
- ADC: 1x12-bit, 2.4 MSPS A/D converter: up to 16 channels
- DAC: 1x12-bit, 2.4 MSPS A/D converter: up to 1 channels
- DMA: 16-stream DMA controllers with FIFOs and burst support
- Timers: Up to 11 timers: up to 5 16-bit, 1 32-bit timers, two
watchdog timers, and a SysTick timer
- GPIO: Up to 81 I/O ports with interrupt capability
- I2C: Up to 3 I2C interfaces
- USARTs: Up to 3 USARTs
- SPIs: Up to 4 SPIs (2 I2S)
- CRC calculation unit
- RTC
- Peripherals: 1 led, 1 push button
- Debug: Serial wire debug and JTAG interfaces
- Expansion I/F Ardino and Morpho Headers
Uses a STM32F103 to provide a ST-Link for programming, debug similar to the
OpenOcd FTDI function - USB to JTAG front-end.
See https://os.mbed.com/platforms/ST-Nucleo-F410RB for more
information about this board.
Hardware
========
Buttons
-------
B1 USER: the user button is connected to the I/O PC13 (pin 2) of the STM32
microcontroller.
LEDs
----
The Nucleo F410RB provide a single user LED, LD2. LD2
is the green LED connected to Arduino signal D13 corresponding to MCU I/O
PA5 (pin 21) or PB13 (pin 34) depending on the STM32target.
- When the I/O is HIGH value, the LED is on.
- When the I/O is LOW, the LED is off.
These LEDs are not used by the board port unless CONFIG_ARCH_LEDS is
defined. In that case, the usage by the board port is defined in
include/board.h and src/sam_leds.c. The LEDs are used to encode OS-related
events as follows when the red LED (PE24) is available::
SYMBOL Meaning LD2
------------------- ----------------------- -----------
LED_STARTED NuttX has been started OFF
LED_HEAPALLOCATE Heap has been allocated OFF
LED_IRQSENABLED Interrupts enabled OFF
LED_STACKCREATED Idle stack created ON
LED_INIRQ In an interrupt No change
LED_SIGNAL In a signal handler No change
LED_ASSERTION An assertion failed No change
LED_PANIC The system has crashed Blinking
LED_IDLE MCU is is sleep mode Not used
Thus if LD2, NuttX has successfully booted and is, apparently, running
normally. If LD2 is flashing at approximately 2Hz, then a fatal error
has been detected and the system has halted.
Serial Consoles
===============
USART1
------
Pins and Connectors::
RXD: PA11 CN10 pin 14
PB7 CN7 pin 21
TXD: PA10 CN9 pin 3, CN10 pin 33
PB6 CN5 pin 3, CN10 pin 17
NOTE: You may need to edit the include/board.h to select different USART1
pin selections.
TTL to RS-232 converter connection::
Nucleo CN10 STM32F410RB
----------- ------------
Pin 21 PA9 USART1_RX *Warning you make need to reverse RX/TX on
Pin 33 PA10 USART1_TX some RS-232 converters
Pin 20 GND
Pin 8 U5V
To configure USART1 as the console::
CONFIG_STM32_USART1=y
CONFIG_USART1_SERIALDRIVER=y
CONFIG_USART1_SERIAL_CONSOLE=y
CONFIG_USART1_RXBUFSIZE=256
CONFIG_USART1_TXBUFSIZE=256
CONFIG_USART1_BAUD=115200
CONFIG_USART1_BITS=8
CONFIG_USART1_PARITY=0
CONFIG_USART1_2STOP=0
USART2
------
Pins and Connectors::
RXD: PA3 CN9 pin 1 (See SB13, 14, 62, 63). CN10 pin 37
PD6
TXD: PA2 CN9 pin 2(See SB13, 14, 62, 63). CN10 pin 35
PD5
UART2 is the default in all of these configurations.
TTL to RS-232 converter connection::
Nucleo CN9 STM32F410RB
----------- ------------
Pin 1 PA3 USART2_RX *Warning you make need to reverse RX/TX on
Pin 2 PA2 USART2_TX some RS-232 converters
Solder Bridges. This configuration requires:
- SB62 and SB63 Closed: PA2 and PA3 on STM32 MCU are connected to D1 and D0
(pin 7 and pin 8) on Arduino connector CN9 and ST Morpho connector CN10
as USART signals. Thus SB13 and SB14 should be OFF.
- SB13 and SB14 Open: PA2 and PA3 on STM32F103C8T6 (ST-LINK MCU) are
disconnected to PA3 and PA2 on STM32 MCU.
To configure USART2 as the console::
CONFIG_STM32_USART2=y
CONFIG_USART2_SERIALDRIVER=y
CONFIG_USART2_SERIAL_CONSOLE=y
CONFIG_USART2_RXBUFSIZE=256
CONFIG_USART2_TXBUFSIZE=256
CONFIG_USART2_BAUD=115200
CONFIG_USART2_BITS=8
CONFIG_USART2_PARITY=0
CONFIG_USART2_2STOP=0
USART6
------
Pins and Connectors::
RXD: PC7 CN5 pin2, CN10 pin 19
PA12 CN10, pin 12
TXD: PC6 CN10, pin 4
PA11 CN10, pin 14
To configure USART6 as the console::
CONFIG_STM32_USART6=y
CONFIG_USART6_SERIALDRIVER=y
CONFIG_USART6_SERIAL_CONSOLE=y
CONFIG_USART6_RXBUFSIZE=256
CONFIG_USART6_TXBUFSIZE=256
CONFIG_USART6_BAUD=115200
CONFIG_USART6_BITS=8
CONFIG_USART6_PARITY=0
CONFIG_USART6_2STOP=0
Virtual COM Port
----------------
Yet another option is to use UART2 and the USB virtual COM port. This
option may be more convenient for long term development, but is painful
to use during board bring-up.
Solder Bridges. This configuration requires:
- SB62 and SB63 Open: PA2 and PA3 on STM32 MCU are disconnected to D1
and D0 (pin 7 and pin 8) on Arduino connector CN9 and ST Morpho
connector CN10.
- SB13 and SB14 Closed: PA2 and PA3 on STM32F103C8T6 (ST-LINK MCU) are
connected to PA3 and PA2 on STM32 MCU to have USART communication
between them. Thus SB61, SB62 and SB63 should be OFF.
Configuring USART2 is the same as given above.
Question: What BAUD should be configure to interface with the Virtual
COM port? 115200 8N1?
Default
-------
As shipped, SB62 and SB63 are open and SB13 and SB14 closed, so the
virtual COM port is enabled.
Configurations
==============
nsh
---
Configures the NuttShell (nsh) located at apps/examples/nsh for the
Nucleo-F410RB board. The Configuration enables the serial interfaces
on UART2. Support for builtin applications is enabled, but in the base
configuration no builtin applications are selected (see NOTES below).
NOTES:
1. This configuration uses the mconf-based configuration tool. To
change this configuration using that tool, you should:
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
see additional README.txt files in the NuttX tools repository.
b. Execute 'make menuconfig' in nuttx/ in order to start the
reconfiguration process.

394
Documentation/platforms/arm/stm32f4/boards/nucleo-f411re/index.rst Normal file
View File

@ -0,0 +1,394 @@
================
ST Nucleo F401RE
================
This README discusses issues unique to NuttX configurations for the ST
NucleoF401RE and NucleoF411RE boards from ST Micro. See
http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1577/LN1810/PF258797
http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1577/LN1877/PF260049
These two boards are very similar, both supporting STM32 "Dynamic Efficiency
Line" parts but differing in the specific STM32 chip mounted on board. The
chips themselves are also very similar with the STM32F411RE having some
additional capability:
NucleoF411RE:
- Microprocessor: 32-bit ARM Cortex M4 at 100MHz STM32F411RE
- Memory: 512 KB Flash and 128 KB SRAM
- ADC: 1×12-bit, 2.4 MSPS A/D converter: up to 10 channels
- DMA: 16-stream DMA controllers with FIFOs and burst support
- Timers: Up to 11 timers: up to six 16-bit, two 32-bit timers, two
watchdog timers, and a SysTick timer
- GPIO: Up to 81 I/O ports with interrupt capability
- I2C: Up to 3 × I2C interfaces
- USARTs: Up to 3 USARTs
- SPIs: Up to 4 SPIs (2 I2S)
- SDIO interface
- USB: USB 2.0 full-speed device/host/OTG controller with on-chip PHY
- CRC calculation unit
- RTC
The NucleoF411RE also has additional DMA and SPI peripheral capabilities.
Board features, however, are identical:
- Peripherals: 1 led, 1 push button
- Debug: Serial wire debug and JTAG interfaces
- Expansion I/F Ardino and Morpho Headers
Uses a STM32F103 to provide a ST-Link for programming, debug similar to the
OpenOcd FTDI function - USB to JTAG front-end.
See http://mbed.org/platforms/ST-Nucleo-F401RE and
http://developer.mbed.org/platforms/ST-Nucleo-F411RE for more
information about these boards.
mbed
====
The Nucleo-F411RE includes boot loader from mbed:
https://mbed.org/platforms/ST-Nucleo-F401RE/
https://mbed.org/handbook/Homepage
Using the mbed loader:
1. Connect the Nucleo-F4x1RE to the host PC using the USB connector.
2. A new file system will appear called NUCLEO; open it with Windows
Explorer (assuming that you are using Windows).
3. Drag and drop nuttx.bin into the MBED window. This will load the
nuttx.bin binary into the Nucleo-F4x1RE. The NUCLEO window will
close then re-open and the Nucleo-F4x1RE will be running the new code.
Hardware
========
GPIO
----
::
SERIAL_TX=PA_2 USER_BUTTON=PC_13
SERIAL_RX=PA_3 LED1 =PA_5
A0=PA_0 USART2RX D0=PA_3 D8 =PA_9
A1=PA_1 USART2TX D1=PA_2 D9 =PC_7
A2=PA_4 D2=PA_10 WIFI_CS=D10=PB_6 SPI_CS
A3=PB_0 WIFI_INT=D3=PB_3 D11=PA_7 SPI_MOSI
A4=PC_1 SDCS=D4=PB_5 D12=PA_6 SPI_MISO
A5=PC_0 WIFI_EN=D5=PB_4 LED1=D13=PA_5 SPI_SCK
LED2=D6=PB_10 I2C1_SDA=D14=PB_9 Probe
D7=PA_8 I2C1_SCL=D15=PB_8 Probe
From: https://mbed.org/platforms/ST-Nucleo-F401RE/
Buttons
-------
B1 USER: the user button is connected to the I/O PC13 (pin 2) of the STM32
microcontroller.
LEDs
----
The Nucleo F401RE and Nucleo F411RE provide a single user LED, LD2. LD2
is the green LED connected to Arduino signal D13 corresponding to MCU I/O
PA5 (pin 21) or PB13 (pin 34) depending on the STM32target.
- When the I/O is HIGH value, the LED is on.
- When the I/O is LOW, the LED is off.
These LEDs are not used by the board port unless CONFIG_ARCH_LEDS is
defined. In that case, the usage by the board port is defined in
include/board.h and src/sam_leds.c. The LEDs are used to encode OS-related
events as follows when the red LED (PE24) is available:
=================== ======================= ===========
SYMBOL Meaning LD2
=================== ======================= ===========
LED_STARTED NuttX has been started OFF
LED_HEAPALLOCATE Heap has been allocated OFF
LED_IRQSENABLED Interrupts enabled OFF
LED_STACKCREATED Idle stack created ON
LED_INIRQ In an interrupt No change
LED_SIGNAL In a signal handler No change
LED_ASSERTION An assertion failed No change
LED_PANIC The system has crashed Blinking
LED_IDLE MCU is is sleep mode Not used
=================== ======================= ===========
Thus if LD2, NuttX has successfully booted and is, apparently, running
normally. If LD2 is flashing at approximately 2Hz, then a fatal error
has been detected and the system has halted.
Serial Consoles
===============
USART1
------
Pins and Connectors::
RXD: PA11 CN10 pin 14
PB7 CN7 pin 21
TXD: PA10 CN9 pin 3, CN10 pin 33
PB6 CN5 pin 3, CN10 pin 17
NOTE: You may need to edit the include/board.h to select different USART1
pin selections.
TTL to RS-232 converter connection::
Nucleo CN10 STM32F4x1RE
----------- ------------
Pin 21 PA9 USART1_RX *Warning you make need to reverse RX/TX on
Pin 33 PA10 USART1_TX some RS-232 converters
Pin 20 GND
Pin 8 U5V
To configure USART1 as the console::
CONFIG_STM32_USART1=y
CONFIG_USART1_SERIALDRIVER=y
CONFIG_USART1_SERIAL_CONSOLE=y
CONFIG_USART1_RXBUFSIZE=256
CONFIG_USART1_TXBUFSIZE=256
CONFIG_USART1_BAUD=115200
CONFIG_USART1_BITS=8
CONFIG_USART1_PARITY=0
CONFIG_USART1_2STOP=0
USART2
------
Pins and Connectors::
RXD: PA3 CN9 pin 1 (See SB13, 14, 62, 63). CN10 pin 37
PD6
TXD: PA2 CN9 pin 2(See SB13, 14, 62, 63). CN10 pin 35
PD5
UART2 is the default in all of these configurations.
TTL to RS-232 converter connection::
Nucleo CN9 STM32F4x1RE
----------- ------------
Pin 1 PA3 USART2_RX *Warning you make need to reverse RX/TX on
Pin 2 PA2 USART2_TX some RS-232 converters
Solder Bridges. This configuration requires:
- SB62 and SB63 Closed: PA2 and PA3 on STM32 MCU are connected to D1 and D0
(pin 7 and pin 8) on Arduino connector CN9 and ST Morpho connector CN10
as USART signals. Thus SB13 and SB14 should be OFF.
- SB13 and SB14 Open: PA2 and PA3 on STM32F103C8T6 (ST-LINK MCU) are
disconnected to PA3 and PA2 on STM32 MCU.
To configure USART2 as the console::
CONFIG_STM32_USART2=y
CONFIG_USART2_SERIALDRIVER=y
CONFIG_USART2_SERIAL_CONSOLE=y
CONFIG_USART2_RXBUFSIZE=256
CONFIG_USART2_TXBUFSIZE=256
CONFIG_USART2_BAUD=115200
CONFIG_USART2_BITS=8
CONFIG_USART2_PARITY=0
CONFIG_USART2_2STOP=0
USART6
------
Pins and Connectors::
RXD: PC7 CN5 pin2, CN10 pin 19
PA12 CN10, pin 12
TXD: PC6 CN10, pin 4
PA11 CN10, pin 14
To configure USART6 as the console::
CONFIG_STM32_USART6=y
CONFIG_USART6_SERIALDRIVER=y
CONFIG_USART6_SERIAL_CONSOLE=y
CONFIG_USART6_RXBUFSIZE=256
CONFIG_USART6_TXBUFSIZE=256
CONFIG_USART6_BAUD=115200
CONFIG_USART6_BITS=8
CONFIG_USART6_PARITY=0
CONFIG_USART6_2STOP=0
Virtual COM Port
----------------
Yet another option is to use UART2 and the USB virtual COM port. This
option may be more convenient for long term development, but is painful
to use during board bring-up.
Solder Bridges. This configuration requires:
- SB62 and SB63 Open: PA2 and PA3 on STM32 MCU are disconnected to D1
and D0 (pin 7 and pin 8) on Arduino connector CN9 and ST Morpho
connector CN10.
- SB13 and SB14 Closed: PA2 and PA3 on STM32F103C8T6 (ST-LINK MCU) are
connected to PA3 and PA2 on STM32 MCU to have USART communication
between them. Thus SB61, SB62 and SB63 should be OFF.
Configuring USART2 is the same as given above.
Question: What BAUD should be configure to interface with the Virtual
COM port? 115200 8N1?
Default
-------
As shipped, SB62 and SB63 are open and SB13 and SB14 closed, so the
virtual COM port is enabled.
Shields
=======
RS-232 from Cutedigi.com
------------------------
Supports a single RS-232 connected via::
Nucleo CN9 STM32F4x1RE Cutedigi
----------- ------------ --------
Pin 1 PA3 USART2_RX RXD
Pin 2 PA2 USART2_TX TXD
Support for this shield is enabled by selecting USART2 and configuring
SB13, 14, 62, and 63 as described above under "Serial Consoles"
Itead Joystick Shield
---------------------
See http://imall.iteadstudio.com/im120417014.html for more information
about this joystick.
Itead Joystick Connection::
--------- ----------------- ---------------------------------
ARDUINO ITEAD NUCLEO-F4x1
PIN NAME SIGNAL SIGNAL
--------- ----------------- ---------------------------------
D3 Button E Output PB3
D4 Button D Output PB5
D5 Button C Output PB4
D6 Button B Output PB10
D7 Button A Output PA8
D8 Button F Output PA9
D9 Button G Output PC7
A0 Joystick Y Output PA0 ADC1_0
A1 Joystick X Output PA1 ADC1_1
--------- ----------------- ---------------------------------
All buttons are pulled on the shield. A sensed low value indicates
when the button is pressed.
NOTE: Button F cannot be used with the default USART1 configuration
because PA9 is configured for USART1_RX by default. Use select
different USART1 pins in the board.h file or select a different
USART or select CONFIG_NUCLEO_F401RE_AJOY_MINBUTTONS which will
eliminate all but buttons A, B, and C.
Itead Joystick Signal interpretation::
--------- ----------------------- ---------------------------
BUTTON TYPE NUTTX ALIAS
--------- ----------------------- ---------------------------
Button A Large button A JUMP/BUTTON 3
Button B Large button B FIRE/BUTTON 2
Button C Joystick select button SELECT/BUTTON 1
Button D Tiny Button D BUTTON 6
Button E Tiny Button E BUTTON 7
Button F Large Button F BUTTON 4
Button G Large Button G BUTTON 5
--------- ----------------------- ---------------------------
Itead Joystick configuration settings::
System Type -> STM32 Peripheral Support
CONFIG_STM32_ADC1=y : Enable ADC1 driver support
Drivers
CONFIG_ANALOG=y : Should be automatically selected
CONFIG_ADC=y : Should be automatically selected
CONFIG_INPUT=y : Select input device support
CONFIG_INPUT_AJOYSTICK=y : Select analog joystick support
There is nothing in the configuration that currently uses the joystick.
For testing, you can add the following configuration options to enable the
analog joystick example at apps/examples/ajoystick::
CONFIG_NSH_ARCHINIT=y
CONFIG_EXAMPLES_AJOYSTICK=y
CONFIG_EXAMPLES_AJOYSTICK_DEVNAME="/dev/ajoy0"
STATUS:
2014-12-04:
- Without ADC DMA support, it is not possible to sample both X and Y
with a single ADC. Right now, only one axis is being converted.
- There is conflicts with some of the Arduino data pins and the
default USART1 configuration. I am currently running with USART1
but with CONFIG_NUCLEO_F401RE_AJOY_MINBUTTONS to eliminate the
conflict.
- Current showstopper: I appear to be getting infinite interrupts as
soon as joystick button interrupts are enabled.
Configurations
==============
f401-nsh:
---------
Configures the NuttShell (nsh) located at apps/examples/nsh for the
Nucleo-F401RE board. The Configuration enables the serial interfaces
on UART2. Support for builtin applications is enabled, but in the base
configuration no builtin applications are selected (see NOTES below).
NOTES:
1. This configuration uses the mconf-based configuration tool. To
change this configuration using that tool, you should:
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
see additional README.txt files in the NuttX tools repository.
b. Execute 'make menuconfig' in nuttx/ in order to start the
reconfiguration process.
2. By default, this configuration uses the ARM EABI toolchain
for Linux. That can easily be reconfigured, of course.:
CONFIG_HOST_LINUX=y : Builds under Linux
CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : GNU EABI toolchain for Linux
3. Although the default console is USART2 (which would correspond to
the Virtual COM port) I have done all testing with the console
device configured for USART1 (see instruction above under "Serial
Consoles). I have been using a TTL-to-RS-232 converter connected
as shown below::
Nucleo CN10 STM32F4x1RE
----------- ------------
Pin 21 PA9 USART1_RX *Warning you make need to reverse RX/TX on
Pin 33 PA10 USART1_TX some RS-232 converters
Pin 20 GND
Pin 8 U5V
f411-nsh
--------
This configuration is the same as the f401-nsh configuration, except
that it is configured to support the Nucleo-F411RE.

222
Documentation/platforms/arm/stm32f4/boards/nucleo-f412zg/index.rst Normal file
View File

@ -0,0 +1,222 @@
================
ST Nucleo F410RB
================
This page discusses issues unique to NuttX configurations for the ST
Nucleo F410RB board from ST Micro. See
http://www.st.com/en/evaluation-tools/nucleo-f412zg.html
NucleoF412ZG:
- Microprocessor: 32-bit ARM Cortex M4 at 100MHz STM32F412ZG
- Memory: 1 MB Flash and 256 KB SRAM
- ADC: 1x12-bit, 2.4 MSPS A/D converter: up to 16 channels
- DMA: 2x8-stream DMA controllers with FIFOs and burst support
- Timers: Up to 17 timers: up to 12 16-bit, 2 32-bit timers, two
watchdog timers, and a SysTick timer
- GPIO: Up to 114 I/O ports with interrupt capability
- I2C: Up to 4 I2C interfaces
- USARTs: Up to 4 USARTs
- SPIs: Up to 5 SPIs (5 I2S)
- SDIO interface (SD/MMC/eMMC)
- Advanced connectivity: USB 2.0 full-speed device/host/OTG controller with PHY
- 2x CAN (2.0B Active)
- True random number generator
- CRC calculation unit
- 96-bit unique ID
- RTC
See:
https://www.st.com/content/ccc/resource/technical/document/user_manual/group0/26/49/90/2e/33/0d/4a/da/DM00244518/files/DM00244518.pdf/jcr:content/translations/en.DM00244518.pdf
- Peripherals: 3 led, 2 push button
- Debug: Serial wire debug and JTAG interfaces
- Expansion I/F Ardino and Morpho Headers
Hardware
========
Buttons
-------
B1 USER: the user button is connected to the I/O PC13 (pin 2) of the STM32
microcontroller.
LEDs
----
The Nucleo F410RB provide a single user LED, LD2. LD2
is the green LED connected to Arduino signal D13 corresponding to MCU I/O
PA5 (pin 21) or PB13 (pin 34) depending on the STM32target.
- When the I/O is HIGH value, the LED is on.
- When the I/O is LOW, the LED is off.
These LEDs are not used by the board port unless CONFIG_ARCH_LEDS is
defined. In that case, the usage by the board port is defined in
include/board.h and src/sam_leds.c. The LEDs are used to encode OS-related
events as follows when the red LED (PE24) is available::
SYMBOL Meaning LD2
------------------- ----------------------- -----------
LED_STARTED NuttX has been started OFF
LED_HEAPALLOCATE Heap has been allocated OFF
LED_IRQSENABLED Interrupts enabled OFF
LED_STACKCREATED Idle stack created ON
LED_INIRQ In an interrupt No change
LED_SIGNAL In a signal handler No change
LED_ASSERTION An assertion failed No change
LED_PANIC The system has crashed Blinking
LED_IDLE MCU is is sleep mode Not used
Thus if LD2, NuttX has successfully booted and is, apparently, running
normally. If LD2 is flashing at approximately 2Hz, then a fatal error
has been detected and the system has halted.
Serial Consoles
===============
USART1
------
Pins and Connectors::
RXD: PA11 CN10 pin 14
PB7 CN7 pin 21
TXD: PA10 CN9 pin 3, CN10 pin 33
PB6 CN5 pin 3, CN10 pin 17
NOTE: You may need to edit the include/board.h to select different USART1
pin selections.
TTL to RS-232 converter connection::
Nucleo CN10 STM32F410RB
----------- ------------
Pin 21 PA9 USART1_RX *Warning you make need to reverse RX/TX on
Pin 33 PA10 USART1_TX some RS-232 converters
Pin 20 GND
Pin 8 U5V
To configure USART1 as the console::
CONFIG_STM32_USART1=y
CONFIG_USART1_SERIALDRIVER=y
CONFIG_USART1_SERIAL_CONSOLE=y
CONFIG_USART1_RXBUFSIZE=256
CONFIG_USART1_TXBUFSIZE=256
CONFIG_USART1_BAUD=115200
CONFIG_USART1_BITS=8
CONFIG_USART1_PARITY=0
CONFIG_USART1_2STOP=0
USART2
------
Pins and Connectors::
RXD: PA3 CN9 pin 1 (See SB13, 14, 62, 63). CN10 pin 37
PD6
TXD: PA2 CN9 pin 2(See SB13, 14, 62, 63). CN10 pin 35
PD5
UART2 is the default in all of these configurations.
TTL to RS-232 converter connection::
Nucleo CN9 STM32F410RB
----------- ------------
Pin 1 PA3 USART2_RX *Warning you make need to reverse RX/TX on
Pin 2 PA2 USART2_TX some RS-232 converters
Solder Bridges. This configuration requires:
- SB62 and SB63 Closed: PA2 and PA3 on STM32 MCU are connected to D1 and D0
(pin 7 and pin 8) on Arduino connector CN9 and ST Morpho connector CN10
as USART signals. Thus SB13 and SB14 should be OFF.
- SB13 and SB14 Open: PA2 and PA3 on STM32F103C8T6 (ST-LINK MCU) are
disconnected to PA3 and PA2 on STM32 MCU.
To configure USART2 as the console::
CONFIG_STM32_USART2=y
CONFIG_USART2_SERIALDRIVER=y
CONFIG_USART2_SERIAL_CONSOLE=y
CONFIG_USART2_RXBUFSIZE=256
CONFIG_USART2_TXBUFSIZE=256
CONFIG_USART2_BAUD=115200
CONFIG_USART2_BITS=8
CONFIG_USART2_PARITY=0
CONFIG_USART2_2STOP=0
USART6
------
Pins and Connectors::
RXD: PC7 CN5 pin2, CN10 pin 19
PA12 CN10, pin 12
TXD: PC6 CN10, pin 4
PA11 CN10, pin 14
To configure USART6 as the console::
CONFIG_STM32_USART6=y
CONFIG_USART6_SERIALDRIVER=y
CONFIG_USART6_SERIAL_CONSOLE=y
CONFIG_USART6_RXBUFSIZE=256
CONFIG_USART6_TXBUFSIZE=256
CONFIG_USART6_BAUD=115200
CONFIG_USART6_BITS=8
CONFIG_USART6_PARITY=0
CONFIG_USART6_2STOP=0
Virtual COM Port
----------------
Yet another option is to use UART2 and the USB virtual COM port. This
option may be more convenient for long term development, but is painful
to use during board bring-up.
Solder Bridges. This configuration requires:
- SB62 and SB63 Open: PA2 and PA3 on STM32 MCU are disconnected to D1
and D0 (pin 7 and pin 8) on Arduino connector CN9 and ST Morpho
connector CN10.
- SB13 and SB14 Closed: PA2 and PA3 on STM32F103C8T6 (ST-LINK MCU) are
connected to PA3 and PA2 on STM32 MCU to have USART communication
between them. Thus SB61, SB62 and SB63 should be OFF.
Configuring USART2 is the same as given above.
Question: What BAUD should be configure to interface with the Virtual
COM port? 115200 8N1?
Default:
As shipped, SB62 and SB63 are open and SB13 and SB14 closed, so the
virtual COM port is enabled.
Configurations
==============
nsh
---
Configures the NuttShell (nsh) located at apps/examples/nsh for the
Nucleo-F410RB board. The Configuration enables the serial interfaces
on UART2. Support for builtin applications is enabled, but in the base
configuration no builtin applications are selected (see NOTES below).
NOTES:
1. This configuration uses the mconf-based configuration tool. To
change this configuration using that tool, you should:
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
see additional README.txt files in the NuttX tools repository.
b. Execute 'make menuconfig' in nuttx/ in order to start the
reconfiguration process.

3
Documentation/platforms/arm/stm32f4/boards/nucleo-f429zi/index.rst Normal file
View File

@ -0,0 +1,3 @@
================
ST Nucleo F429ZI
================

494
Documentation/platforms/arm/stm32f4/boards/nucleo-f446re/index.rst Normal file
View File

@ -0,0 +1,494 @@
================
ST Nucleo F446RE
================
This page discusses issues unique to NuttX configurations for the ST
NucleoF446RE boards from ST Micro. See
https://www.st.com/en/evaluation-tools/nucleo-f446re.html
NucleoF446RE:
- Microprocessor: 32-bit ARM Cortex M4 at 180MHz STM32F446RE
- Memory: 512 KB Flash and 128 KB SRAM
- ADC: 1×12-bit, 2.4 MSPS A/D converter: up to 10 channels
- DMA: 16-stream DMA controllers with FIFOs and burst support
- Timers: Up to 11 timers: up to six 16-bit, two 32-bit timers, two
watchdog timers, and a SysTick timer
- GPIO: Up to 81 I/O ports with interrupt capability
- I2C: Up to 3 × I2C interfaces
- USARTs: Up to 3 USARTs
- USARTs: Up to 3 USARTs
- SPIs: Up to 4 SPIs (2 I2S)
- SDIO interface
- USB: USB 2.0 full-speed device/host/OTG controller with on-chip PHY
- CRC calculation unit
- RTC
The NucleoF446RE also has additional DMA and SPI peripheral capabilities.
Board features, however, are identical:
- Peripherals: 1 led, 1 push button
- Debug: Serial wire debug and JTAG interfaces
- Expansion I/F Ardino and Morpho Headers
Uses a STM32F103 to provide a ST-Link for programming, debug similar to the
OpenOcd FTDI function - USB to JTAG front-end.
See https://os.mbed.com/platforms/ST-Nucleo-F446RE/ for more
information about this board.
mbed
====
The Nucleo-F401RE includes boot loader from mbed:
https://mbed.org/platforms/ST-Nucleo-F401RE/
https://mbed.org/handbook/Homepage
Using the mbed loader:
1. Connect the Nucleo-F4x1RE to the host PC using the USB connector.
2. A new file system will appear called NUCLEO; open it with Windows
Explorer (assuming that you are using Windows).
3. Drag and drop nuttx.bin into the MBED window. This will load the
nuttx.bin binary into the Nucleo-F4x1RE. The NUCLEO window will
close then re-open and the Nucleo-F4x1RE will be running the new code.
Hardware
========
..
GPIO
----
SERIAL_TX=PA_2 USER_BUTTON=PC_13
SERIAL_RX=PA_3 LED1 =PA_5
A0=PA_0 USART2RX D0=PA_3 D8 =PA_9
A1=PA_1 USART2TX D1=PA_2 D9 =PC_7
A2=PA_4 D2=PA_10 WIFI_CS=D10=PB_6 SPI_CS
A3=PB_0 WIFI_INT=D3=PB_3 D11=PA_7 SPI_MOSI
A4=PC_1 SDCS=D4=PB_5 D12=PA_6 SPI_MISO
A5=PC_0 WIFI_EN=D5=PB_4 LED1=D13=PA_5 SPI_SCK
LED2=D6=PB_10 I2C1_SDA=D14=PB_9 Probe
D7=PA_8 I2C1_SCL=D15=PB_8 Probe
From: https://mbed.org/platforms/ST-Nucleo-F401RE/
Buttons
-------
B1 USER: the user button is connected to the I/O PC13 (pin 2) of the STM32
microcontroller.
LEDs
----
The Nucleo F446RE provides a single user LED, LD2. LD2
is the green LED connected to Arduino signal D13 corresponding to MCU I/O
PA5 (pin 21) or PB13 (pin 34) depending on the STM32target.
- When the I/O is HIGH value, the LED is on.
- When the I/O is LOW, the LED is off.
These LEDs are not used by the board port unless CONFIG_ARCH_LEDS is
defined. In that case, the usage by the board port is defined in
include/board.h and src/sam_leds.c. The LEDs are used to encode OS-related
events as follows when the red LED (PE24) is available::
SYMBOL Meaning LD2
------------------- ----------------------- -----------
LED_STARTED NuttX has been started OFF
LED_HEAPALLOCATE Heap has been allocated OFF
LED_IRQSENABLED Interrupts enabled OFF
LED_STACKCREATED Idle stack created ON
LED_INIRQ In an interrupt No change
LED_SIGNAL In a signal handler No change
LED_ASSERTION An assertion failed No change
LED_PANIC The system has crashed Blinking
LED_IDLE MCU is is sleep mode Not used
Thus if LD2, NuttX has successfully booted and is, apparently, running
normally. If LD2 is flashing at approximately 2Hz, then a fatal error
has been detected and the system has halted.
Serial Consoles
===============
USART1
------
Pins and Connectors::
RXD: PA11 CN10 pin 14
PB7 CN7 pin 21
TXD: PA10 CN9 pin 3, CN10 pin 33
PB6 CN5 pin 3, CN10 pin 17
NOTE: You may need to edit the include/board.h to select different USART1
pin selections.
TTL to RS-232 converter connection::
Nucleo CN10 STM32F4x1RE
----------- ------------
Pin 21 PA9 USART1_RX *Warning you make need to reverse RX/TX on
Pin 33 PA10 USART1_TX some RS-232 converters
Pin 20 GND
Pin 8 U5V
To configure USART1 as the console::
CONFIG_STM32_USART1=y
CONFIG_USART1_SERIALDRIVER=y
CONFIG_USART1_SERIAL_CONSOLE=y
CONFIG_USART1_RXBUFSIZE=256
CONFIG_USART1_TXBUFSIZE=256
CONFIG_USART1_BAUD=115200
CONFIG_USART1_BITS=8
CONFIG_USART1_PARITY=0
CONFIG_USART1_2STOP=0
USART2
------
Pins and Connectors::
RXD: PA3 CN9 pin 1 (See SB13, 14, 62, 63). CN10 pin 37
PD6
TXD: PA2 CN9 pin 2(See SB13, 14, 62, 63). CN10 pin 35
PD5
UART2 is the default in all of these configurations.
TTL to RS-232 converter connection::
Nucleo CN9 STM32F4x1RE
----------- ------------
Pin 1 PA3 USART2_RX *Warning you make need to reverse RX/TX on
Pin 2 PA2 USART2_TX some RS-232 converters
Solder Bridges. This configuration requires:
- SB62 and SB63 Closed: PA2 and PA3 on STM32 MCU are connected to D1 and D0
(pin 7 and pin 8) on Arduino connector CN9 and ST Morpho connector CN10
as USART signals. Thus SB13 and SB14 should be OFF.
- SB13 and SB14 Open: PA2 and PA3 on STM32F103C8T6 (ST-LINK MCU) are
disconnected to PA3 and PA2 on STM32 MCU.
To configure USART2 as the console::
CONFIG_STM32_USART2=y
CONFIG_USART2_SERIALDRIVER=y
CONFIG_USART2_SERIAL_CONSOLE=y
CONFIG_USART2_RXBUFSIZE=256
CONFIG_USART2_TXBUFSIZE=256
CONFIG_USART2_BAUD=115200
CONFIG_USART2_BITS=8
CONFIG_USART2_PARITY=0
CONFIG_USART2_2STOP=0
USART6
------
Pins and Connectors::
RXD: PC7 CN5 pin2, CN10 pin 19
PA12 CN10, pin 12
TXD: PC6 CN10, pin 4
PA11 CN10, pin 14
To configure USART6 as the console::
CONFIG_STM32_USART6=y
CONFIG_USART6_SERIALDRIVER=y
CONFIG_USART6_SERIAL_CONSOLE=y
CONFIG_USART6_RXBUFSIZE=256
CONFIG_USART6_TXBUFSIZE=256
CONFIG_USART6_BAUD=115200
CONFIG_USART6_BITS=8
CONFIG_USART6_PARITY=0
CONFIG_USART6_2STOP=0
Virtual COM Port
----------------
Yet another option is to use UART2 and the USB virtual COM port. This
option may be more convenient for long term development, but is painful
to use during board bring-up.
Solder Bridges. This configuration requires:
- SB62 and SB63 Open: PA2 and PA3 on STM32 MCU are disconnected to D1
and D0 (pin 7 and pin 8) on Arduino connector CN9 and ST Morpho
connector CN10.
- SB13 and SB14 Closed: PA2 and PA3 on STM32F103C8T6 (ST-LINK MCU) are
connected to PA3 and PA2 on STM32 MCU to have USART communication
between them. Thus SB61, SB62 and SB63 should be OFF.
Configuring USART2 is the same as given above.
Question: What BAUD should be configure to interface with the Virtual
COM port? 115200 8N1?
Default
-------
As shipped, SB62 and SB63 are open and SB13 and SB14 closed, so the
virtual COM port is enabled.
Shields
=======
RS-232 from Cutedigi.com
------------------------
Supports a single RS-232 connected via::
Nucleo CN9 STM32F4x1RE Cutedigi
----------- ------------ --------
Pin 1 PA3 USART2_RX RXD
Pin 2 PA2 USART2_TX TXD
Support for this shield is enabled by selecting USART2 and configuring
SB13, 14, 62, and 63 as described above under "Serial Consoles"
Itead Joystick Shield
---------------------
See http://imall.iteadstudio.com/im120417014.html for more information
about this joystick.
Itead Joystick Connection::
--------- ----------------- ---------------------------------
ARDUINO ITEAD NUCLEO-F4x1
PIN NAME SIGNAL SIGNAL
--------- ----------------- ---------------------------------
D3 Button E Output PB3
D4 Button D Output PB5
D5 Button C Output PB4
D6 Button B Output PB10
D7 Button A Output PA8
D8 Button F Output PA9
D9 Button G Output PC7
A0 Joystick Y Output PA0 ADC1_0
A1 Joystick X Output PA1 ADC1_1
--------- ----------------- ---------------------------------
All buttons are pulled on the shield. A sensed low value indicates
when the button is pressed.
NOTE: Button F cannot be used with the default USART1 configuration
because PA9 is configured for USART1_RX by default. Use select
different USART1 pins in the board.h file or select a different
USART or select CONFIG_NUCLEO_F401RE_AJOY_MINBUTTONS which will
eliminate all but buttons A, B, and C.
Itead Joystick Signal interpretation::
--------- ----------------------- ---------------------------
BUTTON TYPE NUTTX ALIAS
--------- ----------------------- ---------------------------
Button A Large button A JUMP/BUTTON 3
Button B Large button B FIRE/BUTTON 2
Button C Joystick select button SELECT/BUTTON 1
Button D Tiny Button D BUTTON 6
Button E Tiny Button E BUTTON 7
Button F Large Button F BUTTON 4
Button G Large Button G BUTTON 5
--------- ----------------------- ---------------------------
Itead Joystick configuration settings::
System Type -> STM32 Peripheral Support
CONFIG_STM32_ADC1=y : Enable ADC1 driver support
Drivers
CONFIG_ANALOG=y : Should be automatically selected
CONFIG_ADC=y : Should be automatically selected
CONFIG_INPUT=y : Select input device support
CONFIG_INPUT_AJOYSTICK=y : Select analog joystick support
There is nothing in the configuration that currently uses the joystick.
For testing, you can add the following configuration options to enable the
analog joystick example at apps/examples/ajoystick::
CONFIG_NSH_ARCHINIT=y
CONFIG_EXAMPLES_AJOYSTICK=y
CONFIG_EXAMPLES_AJOYSTICK_DEVNAME="/dev/ajoy0"
STATUS:
2014-12-04:
- Without ADC DMA support, it is not possible to sample both X and Y
with a single ADC. Right now, only one axis is being converted.
- There is conflicts with some of the Arduino data pins and the
default USART1 configuration. I am currently running with USART1
but with CONFIG_NUCLEO_F401RE_AJOY_MINBUTTONS to eliminate the
conflict.
- Current showstopper: I appear to be getting infinite interrupts as
soon as joystick button interrupts are enabled.
Configurations
==============
nsh:
----
Configures the NuttShell (nsh) located at apps/examples/nsh for the
Nucleo-F446RE board. The Configuration enables the serial interfaces
on UART2. Support for builtin applications is enabled, but in the base
configuration no builtin applications are selected (see NOTES below).
NOTES:
1. This configuration uses the mconf-based configuration tool. To
change this configuration using that tool, you should:
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
see additional README.txt files in the NuttX tools repository.
b. Execute 'make menuconfig' in nuttx/ in order to start the
reconfiguration process.
2. By default, this configuration uses the ARM EABI toolchain
for Linux. That can easily be reconfigured, of course.::
CONFIG_HOST_LINUX=y : Builds under Linux
CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : GNU EABI toolchain for Linux
3. Although the default console is USART2 (which would correspond to
the Virtual COM port) I have done all testing with the console
device configured for USART1 (see instruction above under "Serial
Consoles). I have been using a TTL-to-RS-232 converter connected
as shown below::
Nucleo CN10 STM32F446RE
----------- ------------
Pin 21 PA9 USART1_RX *Warning you make need to reverse RX/TX on
Pin 33 PA10 USART1_TX some RS-232 converters
Pin 20 GND
Pin 8 U5V
can
---
This is basically an nsh configuration (see above) with added support
for CAN driver. Both CAN 1 (RX: PB_8, TX: PB_9) and CAN 2 (RX: PB_5, TX: PB_6)
are turn on.
Functionality of CAN driver can be tested by calling application
"can" in NuttShell. This application sends 100 messages over CAN 1.
dac
---
This is an nsh configuration (see above) with added support
for digital analog converter driver.
Functionality of DAC driver can be tested by calling application
"dac" in NuttShell. GPIO_DAC1_OUT1 pin is set on PA_4.
gpio
----
This is an nsh configuration (see above) with added support for GPIO
driver and GPIO test application "gpio". Three pins are configured for
testing purposes::
PA_7 - GPIO_INPUT
PB_6 - GPIO_OUTPUT
PC_7 - GPIO_INPUT_INTERRUPT
ihm08m1_f32 and ihm08m1_b16
---------------------------
These examples are dedicated for the X-NUCLEO-IHM08M1 expansion board with
L6398 gate drivers and discrete transistors.
WARNING: L6398 gate drivers require channel 2 negative polarisation and
negative sign for the deadtime. Make sure that your gate drivers logic
is compatible with this configuration.
X-NUCLEO-IHM08M1 must be configured to work with FOC and 3-shunt
resistors. See ST documentation for details.
Pin configuration for the X-NUCLEO-IHM08M1 (TIM1 configuration)::
Board Function Chip Function Chip Pin Number
------------- ---------------- -----------------
Phase U high TIM1_CH1 PA8
Phase U low TIM1_CH1N PA7
Phase V high TIM1_CH2 PA9
Phase V low TIM1_CH2N PB0
Phase W high TIM1_CH3 PA10
Phase W low TIM1_CH3N PB1
Current U ADC1_IN0 PA0
Current V ADC1_IN11 PC1
Current W ADC1_IN10 PC0
Temperature ADC1_IN12 PC2
VBUS ADC1_IN1 PA1
BEMF1 (NU) PC3
BEMF2 (NU) PC4
BEMF3 (NU) PC5
LED GPIO_PB2 PB2
+3V3 (CN7_16)
GND (CN7_20)
GPIO_BEMF (NU) PC9
ENCO_A/HALL_H1 TIM2_CH1 PA15
ENCO_B/HALL_H2 TIM2_CH2 PB3
ENCO_Z/HALL_H3 TIM2_CH3 PB10
DAC (NU) PA5
GPIO3 (NU) PB13
CPOUT (NU) PA12
BKIN1 (NU) PA6
BKIN2 (NU) PA11
BKIN3 (NU) PB14
POT/DAC DAC1_CH1/ADC1_IN4 PA4
CURR_REF (NU) PB4
DEBUG0 GPIO PB12
DEBUG1 GPIO PB9
DEBUG2 GPIO PC6
DEBUG3 GPIO PB5
DEBUG4 GPIO PC8
Current shunt resistance = 0.01
Current sense gain = -5.18 (inverted current)
Vbus sense gain = 9.31k/(9.31k+169k) = 0.0522
Vbus min = 10V
Vbus max = 48V
Iout max = 15A RMS
IPHASE_RATIO = 1/(R_shunt*gain) = -19.3
VBUS_RATIO = 1/VBUS_gain = 19.152
For now only 3-shunt resistors configuration is supported.
lcd
---
This is basically an nsh configuration (see above) with added support
of ILI9225 176x220 TFT display and test framebuffer application.
Display connection is set to SPI 3 and pinout is following::
CS D8
RST D6
RS D7
SDA D4
CLK D3
Framebuffer application can be started from terminal by typing "fb".
pwm
---
This is an nsh configuration (see above) with added capability of pulse width
modulation. PWM output is on Timer 3 channel 1, which is pin PA_6 (D12) on
Nucleo board. Example program can be stared by "pwm" command.

210
Documentation/platforms/arm/stm32f4/boards/olimex-stm32-e407/index.rst Normal file
View File

@ -0,0 +1,210 @@
=================
Olimex STM32-E407
=================
The Olimex STM32-E407 configuration is based on the configuration
olimex-stm32-h407 and stm32f4discovery.
Configurations
==============
Instantiating Configurations
----------------------------
Each Olimex-STM32-E407 configuration is maintained in a sub-directory and
can be selected as follow::
tools/configure.sh [OPTIONS] olimex-stm32-e407:<subdir>
Typical options include -l for a Linux host platform or -c for Cygwin
host platform. See 'tools/configure.sh -h' for other options. And
<subdir> is one of the sub-directories listed below.
Compile Firmware
----------------
Once you've set the proper configuration, you just need to execute the next
command::
make
If everything goes find, it should return the next two files::
nuttx.hex
nuttx.bin
You can return more kinds of files by setting on menuconfig.
Flashing the Board
------------------
You can flash this board in different ways, but the easiest way is using
ARM-USB-TINY-H JTAG flasher device.
Connect this device to the JTAG connector and type the next command::
openocd -f interface/ftdi/olimex-arm-usb-tiny-h.cfg -f target/stm32f4x.cfg -c init -c "reset halt" -c "flash write_image erase nuttx.bin 0x08000000"
Configuration Directories
-------------------------
nsh
---
Configures the NuttShell (nsh) located at apps/examples/nsh. This
configuration enables a console on UART2. Support for
builtin applications is enabled, but in the base configuration no
builtin applications are selected.
usbnsh
------
Configures the NuttShell (nsh) located at apps/examples/nsh. This
configuration enables a console on USB_OTG1. Support for
builtin applications is enabled, but in the base configuration no
builtin applications are selected.
netnsh
------
Configures the NuttShell (nsh) located at examples/nsh. This
configuration is focused on network testing.
bmp180
------
This is a configuration example for the BMP180 barometer sensor. This
sensor works with I2C, you need to do the next connections::
BMP180 VIN -> Board 3.3V
BMP180 GND -> Board GND
BMP180 SCL -> Board PB6 (Arduino header D1)
BMP180 SDA -> Board PB7 (Arduino header D0)
This example is configured to work with the USBNSH instead of UART NSH, so
the console will be shown over the USB_OTG1 connector.
On the console, type "ls /dev " and if the registration process goes fine,
you should see a device called "press0". Now execute the app
BMP180 to see the ambient pressure value.
dac
---
This is a configuration example to use the DAC1 of the board. The DAC1
is attached to the PA4 pin (Arduino header D10).
This example is configured to work with the USBNSH instead of UART NSH, so
the console will be shown over the USB_OTG1 connector.
On the console, type "ls /dev " and if the registration process goes fine,
you should see a device called "dac0". Now execute the app
dac put a value at the output.
ina219
------
This is a configuration example for the INA219 DC current sensor. This
sensor works with I2C, you need to do the next connections::
INA219 VIN -> Board 3.3V
INA219 GND -> Board GND
INA219 SCL -> Board PB6 (Arduino header D1)
INA219 SDA -> Board PB7 (Arduino header D0)
This example is configured to work with the USBNSH instead of UART NSH, so
the console will be shown over the USB_OTG1 connector.
On the console, type "ls /dev " and if the registration process goes fine,
you should see a device called "ina219". Now execute the app
ina219 to see the ambient pressure value.
timer
-----
This configuration set the proper configuration to use the timer1 of the
board. This example is configured to work with the USBNSH instead of
UART NSH, so the console will be shown over the USB_OTG1 connector.
On the console, type "ls /dev " and if the registration process goes fine,
you should see a device called "timer1".
mrf24j40-mac
------------
This configuration set the proper configuration to set the 802.15.4
communication layer with the MRF24J40 radio. This radio works with
SPI, you need to do the next connections::
MRF24J40 VCC -> Board 3.3V
MRF24J40 GND -> Board GND
MRF24J40 SCLK -> Board PA5 (Arduino header D13)
MRF24J40 MISO -> Board PA6 (Arduino header D12)
MRF24J40 MOSI -> Board PB5 (Arduino header D11)
MRF24J40 CS -> Board PA4 (Arduino header D10)
MRF24J40 INT -> Board PG12 (Arduino header D8)
This example is configured to work with the USBNSH instead of UART NSH,
so the console will be shown over the USB_OTG1 connector.
Once you're on the console, you need to check if the initialization
process was fine. To do so, you need to type "ls /dev" and you should
see a device call "ieee0". At this point we need to set-up the network,
follow the next steps::
This is an example of how to configure a coordinator:
i8sak /dev/ieee0 startpan cd:ab
i8sak set chan 11
i8sak set saddr 42:01
i8sak acceptassoc
This is an example of how to configure the endpoint:
i8sak /dev/ieee0
i8sak set chan 11
i8sak set panid cd:ab
i8sak set saddr 42:02
i8sak set ep_saddr 42:01
i8sak assoc
mrf24j40-6lowpan
----------------
This configuration set the proper configuration to use 6lowpan protocol with the MRF24J40
radio. This radio works with SPI, you need to do the next connections::
MRF24J40 VCC -> Board 3.3V
MRF24J40 GND -> Board GND
MRF24J40 SCLK -> Board PA5 (Arduino header D13)
MRF24J40 MISO -> Board PA6 (Arduino header D12)
MRF24J40 MOSI -> Board PB5 (Arduino header D11)
MRF24J40 CS -> Board PA4 (Arduino header D10)
MRF24J40 INT -> Board PG12 (Arduino header D8)
This example is configured to work with the USBNSH instead of UART NSH, so
the console will be shown over the USB_OTG1 connector.
Once you're on the console, you need to check if the initialization process
was fine. To do so, you need to type "ls /dev" and you should see a device
call "ieee0". At this point we need to set-up the network, follow the next steps::
This is an example of how to configure a coordinator:
i8sak wpan0 startpan cd:ab
i8sak set chan 11
i8sak set saddr 42:01
i8sak acceptassoc
When the association was complete, you need to bring-up the network:
ifup wpan0
This is an example of how to configure the endpoint:
i8sak wpan0
i8sak set chan 11
i8sak set panid cd:ab
i8sak set saddr 42:02
i8sak set ep_saddr 42:01
i8sak assoc
When the association was complete, you need to bring-up the network:
ifup wpan0
If you execute the command "ifconfig", you will be able to see the info of the WPAN0 interface
and see the assigned IP. This interface can be use with an UDP or TCP server/client application.

18
boards/arm/stm32/olimex-stm32-h405/README.txt → Documentation/platforms/arm/stm32f4/boards/olimex-stm32-h405/index.rst
View File

@ -1,5 +1,6 @@
README
======
=================
Olimex STM32-P207
=================
The NuttX configuration for the Olimex STM32-H405 is based on the configuration
Olimex STM32-P207.
@ -15,14 +16,13 @@ Make sure that '# CONFIG_NSH_CONDEV is not set' is in the .config file - it defa
to '/dev/console' which makes problems with the shell over USB.
The following peripherals are enabled in this configuration.
- LED: Shows the system status
- LED: Shows the system status
- Button: Built in app 'buttons' works.
- Button: Built in app 'buttons' works.
- ADC: ADC1 samples ADC_IN1. Built in app 'adc' works.
- ADC: ADC1 samples ADC_IN1. Built in app 'adc' works.
- USB-FS-OTG: The console is running on the virtual serial port. Note that you
have to press enter three times until NSH appears.
- USB-FS-OTG: The console is running on the virtual serial port. Note that you
have to press enter three times until NSH appears.
- CAN: Built in app 'can' is enabled but not tested, since no CAN transceiver
is on board.
- CAN:Built in app 'can' is enabled but not tested, since no CAN transceiver is on board.

15
boards/arm/stm32/olimex-stm32-h407/README.txt → Documentation/platforms/arm/stm32f4/boards/olimex-stm32-h407/index.rst
View File

@ -1,5 +1,6 @@
README
======
=================
Olimex STM32-H407
=================
The Olimex STM32-H407 configuration is based on
stm32Fdiscovery and Olimex STM32-H405.
@ -10,13 +11,6 @@ This release provides baseline for H407 12MHZ clock in include/board.h
nsh - Only basic shell response tested on USART2
nsh_uext - Basic shell response tested on USART6 (UEXT)
Development Environment
=======================
Either Linux or Cygwin on Windows can be used for the development environment.
The source has been built only using the GNU toolchain (see below). Other
toolchains will likely cause problems.
LEDs
====
@ -37,6 +31,3 @@ or you can use USART6 exposed via UEXT connector.
Olimex offers MOD-RS232 voltage level converter for the UEXT so it can be
attached to computer serial port.
STM32-H407-specific Configuration Options
===============================================

574
Documentation/platforms/arm/stm32f4/boards/olimex-stm32-p407/index.rst Normal file
View File

@ -0,0 +1,574 @@
=================
Olimex STM32-P207
=================
The NuttX configuration for the Olimex STM32-P407 is derives more or less
directly from the Olimex STM32-P207 board support. The P207 and P407 seem
to share the same board design. Other code comes from the STM3240G board
support (which has the same crystal and clocking) and from the STM32 F4
Discovery (which has the same STM32 part)
Board Support
=============
The following peripherals are available in this configuration.
- LEDs: Show the system status
- Buttons: TAMPER-button, WKUP-button, J1-Joystick (consists of RIGHT-,
UP-, LEFT-, DOWN-, and CENTER-button).
- ADC: ADC1 samples the red trim potentiometer AN_TR
Built in app 'adc' works.
- USB-FS-OTG: There is a USB-A-connector (host) connected to the full
speed STM32 OTG inputs.
- USB-HS-OTG: The other connector (device) is connected to the high speed
STM32 OTG inputs.
- CAN: Built in app 'can' works, but apart from that not really tested.
- Ethernet: Ping to other station on the network works.
- microSD: Not fully functional. See below.
- LCD: Nokia 6610. This is similar the Nokia 6100 LCD used on other
Olimex boards. There is a driver for that LCD at
Obsoleted/nuttx/drivers/lcd/nokia6100.c, however, it was removed
because it was not properly integrated. It uses a 9-bit SPI
interface which is difficult to get working properly.
- External SRAM: Support is included for the onboard SRAM. It uses SRAM
settings from another board that might need to be tweaked.
Difficult to test because the SRAM conflicts with both
RS232 ports.
- Other: Buzzer, Camera, Temperature sensor, audio have not been tested.
If so, then it requires a 9-bit
microSD Card Interface
======================
microSD Connector
-----------------
::
----------------- ----------------- ------------------------
SD/MMC CONNECTOR BOARD GPIO CONFIGURATION(s
PIN SIGNAL SIGNAL (no remapping)
--- ------------- ----------------- -------------------------
1 DAT2/RES SD_D2/USART3_TX/ PC10 GPIO_SDIO_D2
SPI3_SCK
2 CD/DAT3/CS SD_D3/USART3_RX/ PC11 GPIO_SDIO_D3
SPI3_MISO
3 CMD/DI SD_CMD PD2 GPIO_SDIO_CMD
4 VDD N/A N/A
5 CLK/SCLK SD_CLK/SPI3_MOSI PC12 GPIO_SDIO_CK
6 VSS N/A N/A
7 DAT0/D0 SD_D0/DCMI_D2 PC8 GPIO_SDIO_D0
8 DAT1/RES SD_D1/DCMI_D3 PC9 GPIO_SDIO_D1
--- ------------- ----------------- -------------------------
NOTES:
1. DAT4, DAT4, DAT6, and DAT7 not connected.
2. There are no alternative pin selections.
3. There is no card detect (CD) GPIO input so we will not
sense if there is a card in the SD slot or not. This will
make usage very awkward.
Configuration
-------------
Enabling SDIO-based MMC/SD support:
System Type->STM32 Peripheral Support::
CONFIG_STM32_SDIO=y : Enable SDIO support
CONFIG_STM32_DMA2=y : DMA2 is needed by the driver
Device Drivers -> MMC/SD Driver Support::
CONFIG_MMCSD=y : Enable MMC/SD support
CONFIG_MMSCD_NSLOTS=1 : One slot per driver instance
# CONFIG_MMCSD_HAVE_CARDDETECT is not set : No card-detect GPIO
# CONFIG_MMCSD_MMCSUPPORT is not set : Interferes with some SD cards
# CONFIG_MMCSD_SPI is not set : No SPI-based MMC/SD support
CONFIG_MMCSD_SDIO=y : SDIO-based MMC/SD support
CONFIG_MMCSD_MULTIBLOCK_LIMIT=1 : Disable to keep things simple
CONFIG_SDIO_DMA=y : Use SDIO DMA
# CONFIG_SDIO_BLOCKSETUP is not set : (not implemented)
Library Routines::
CONFIG_SCHED_WORKQUEUE=y : Driver needs work queue support
Application Configuration -> NSH Library::
CONFIG_NSH_ARCHINIT=y : NSH board-initialization
Using the SD card
-----------------
1. Since there is no CD GPIO pin, the firmware sill not know if there is
a card in the SD slot or not. It will assume that there is and attempt
to mount the SD card on power-up. If there is no SD card in the card
slot, there will be a long delay during initialization as the firmware
attempts to query the non-existent card, timeout, and retry.
2. After booting, an SDIO device will appear as /dev/mmcsd0
3. If you try mounting an SD card with nothing in the slot, the
mount will fail::
nsh> mount -t vfat /dev/mmcsd0 /mnt/sdcard
nsh: mount: mount failed: 19
STATUS:
-------
2017-01-28: There is no card communication. All commands to the SD card timeout.
OTGFS Host
==========
..
STM32 USB OTG FS Host Board Support
-----------------------------------
A USB-A-connector (host) is connected to the full speed STM32 inputs. These
are the pins supported by the STM32:
PIN SIGNAL DIRECTION
---- ----------- ----------
PA8 OTG_FS_SOF SOF clock output
PA9 OTG_FS_VBUS VBUS input for device, Driven by external regulator by
host (not an alternate function)
PA10 OTG_FS_ID OTG ID pin (only needed in Dual mode)
PA11 OTG_FS_DM D- I/O
PA12 OTG_FS_DP D+ I/O
These are the signals available on-board:
OTG_FS_VBUS Used host VBUS sensing (device input only)
OTG_FS_DM Data minus
OTG_FS_DP Dta plus
NOTE: PA10 is currently used for DCMI_D1. The USB OTGFS host will
configure this as the ID input.
VBUS power is provided via an LM3526 and driven by USB_FS_VBUSON:
USB_FS_VBUSON PC2 power on output to LM3526 #ENA
USB_FS_FAULT PB10 overcurrent input from LM3526 FLAG_A.
STM32 USB OTG FS Host Driver Configuration
------------------------------------------
Pre-requisites
CONFIG_USBDEV - Enable USB device support
CONFIG_USBHOST - Enable USB host support
CONFIG_STM32_OTGFS - Enable the STM32 USB OTG FS block
CONFIG_STM32_SYSCFG - Needed
CONFIG_SCHED_WORKQUEUE - Worker thread support is required
STM32 Options:
CONFIG_STM32_OTGFS_RXFIFO_SIZE - Size of the RX FIFO in 32-bit words.
Default 128 (512 bytes)
CONFIG_STM32_OTGFS_NPTXFIFO_SIZE - Size of the non-periodic Tx FIFO
in 32-bit words. Default 96 (384 bytes)
CONFIG_STM32_OTGFS_PTXFIFO_SIZE - Size of the periodic Tx FIFO in 32-bit
words. Default 96 (384 bytes)
CONFIG_STM32_OTGFS_DESCSIZE - Maximum size of a descriptor. Default: 128
CONFIG_STM32_OTGFS_SOFINTR - Enable SOF interrupts. Why would you ever
want to do that?
CONFIG_STM32_USBHOST_REGDEBUG - Enable very low-level register access
debug. Depends on CONFIG_DEBUG_FEATURES.
CONFIG_STM32_USBHOST_PKTDUMP - Dump all incoming and outgoing USB
packets. Depends on CONFIG_DEBUG_FEATURES.
Olimex STM32 P407 Configuration:
CONFIG_STM32F_OLIMEXP407_PRIO - Priority of the USB host watier
thread (default 100).
CONFIG_STM32_OLIMEXP407_STACKSIZE - Stacksize of the USB host
waiter thread (default 1024)
Class Driver Configuration
--------------------------
Individual class drivers have additional configuration requirements. The
USB mass storage class, for example, requires FAT file system support.
CONFIG_USBHOST_MSC=y
CONFIG_FS_FAT=y
CONFIG_FAT_LCNAMES=y
CONFIG_FAT_LFN=y
CONFIG_FAT_MAXFNAME=32
This will enable USB HID keyboard support:
CONFIG_USBHOST_HIDKBD=y
CONFIG_HIDKBD_BUFSIZE=64
CONFIG_HIDKBD_DEFPRIO=50
CONFIG_HIDKBD_POLLUSEC=100000
CONFIG_HIDKBD_STACKSIZE=1024
And this will enable the USB keyboard example:
CONFIG_EXAMPLES_HIDKBD=y
CONFIG_EXAMPLES_HIDKBD_DEFPRIO=50
CONFIG_EXAMPLES_HIDKBD_DEVNAME="/dev/kbda"
CONFIG_EXAMPLES_HIDKBD_STACKSIZE=1024
STATUS: The MSC configurations seems fully functional. The HIDKBD seems rather
flaky. Sometimes the LEDs become very bright (indicating that it is being
swamped with interrupts). Data input is not clean with apps/examples/hidkbd:
There are missing characters and sometimes duplicated characters. This implies
some logic issues, probably in drivers/usbhost/usbhost_hidkbd.c, with polling
and data filtering.
Configurations
==============
Information Common to All Configurations
----------------------------------------
Each Olimex STM32-P407 configuration is maintained in a sub-directory and can be
selected as follow::
tools/configure.sh olimex-stm32-p407:<subdir>
Where <subdir> is one of the configuration sub-directories listed in the
following section.
Before building, make sure the PATH environment variable includes the
correct path to the directory than holds your toolchain binaries.
And then build NuttX by simply typing the following. At the conclusion of
the make, the nuttx binary will reside in an ELF file called, simply, nuttx.::
make oldconfig
make
NOTES:
1. This configuration uses the mconf-based configuration tool. To
change this configurations using that tool, you should:
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
see additional README.txt files in the NuttX tools repository.
b. Execute 'make menuconfig' in nuttx/ in order to start the
reconfiguration process.
2. Serial Output
This configuraiont produces all of its test output on the serial
console. This configuration has USART3 enabled as a serial console.
This is the connector labeled RS232_2. This can easily be changed
by reconfiguring with 'make menuconfig'.
3. Toolchain
By default, the host platform is set to be Linux using the NuttX
buildroot toolchain. The host and/or toolchain selection can easily
be changed with 'make menuconfig'.
4. Note that CONFIG_STM32_DISABLE_IDLE_SLEEP_DURING_DEBUG is enabled so
that the JTAG connection is not disconnected by the idle loop.
Configuration sub-directories
-----------------------------
The <subdir> that is provided above as an argument to the tools/configure.sh
must be is one of the following.
dhtxx
-----
Configuration added by Abdelatif Guettouche for testing the the DHTxx
sensor. This configuration expects this setup::
DHTXX_PIN_OUTPUT PG9
DHTXX_PIN_INPUT PG9
The STM32 free-running timer is also required.
hidkbd
------
This is another NSH configuration that supports a USB HID Keyboard
device and the HID keyboard example at apps/examples/hidkbd.
STATUS:
2018-10-07: Not all keyboards will connect successfully. I have not
looked into the details but it may be that those keyboards are not
compatible with the driver (which only accepts "boot" keyboards).
Also, when typing input into the HID keyboard, characters are often
missing and sometimes duplicated. This is like some issue with the
read logic of drivers/usbhost_hidkbc.c.
kelf
----
This is a protected mode version of the apps/examples/elf test of
loadable ELF programs. This version is unique because the ELF programs
are loaded into user space.
NOTES:
1. See build recommendations and instructions for combining the .hex
files under the section entitled "Protected Mode Build" above.
2. Unlike other versions of apps/examples/elf configurations, the test
ELF programs are not provided internally on a ROMFS or CROMFS file
system. This is due to the fact that those file systems are built in
user space and there is no mechanism in the build system to easily
get them into the kernel space.
Instead, the programs must be copied to a USB FLASH drive from your
host PC. The programs can be found at apps/examples/elf/tests/romfs.
All of those files should be copied to the USB FLASH drive. The
apps/example/elf will wait on power up until the USB FLASH drive
has been inserted and initialized.
kmodule
-------
This is a protected mode version of the apps/examples/module test of
loadable ELF kernel modules. This version is unique because the ELF
programs are loaded into the protected kernel space.
NOTES:
1. See build recommendations and instructions for combining the .hex
files under the section entitled "Protected Mode Build" above.
2. Unlike other versions of apps/examples/module configurations, the test
ELF modules are not provided internally on a ROMFS or CROMFS file
system. This is due to the fact that those file systems are built in
user space and there is no mechanism in the build system to easily
get them into the kernel space.
Instead, the module(s) must be copied to a USB FLASH drive from your
host PC. The module(s) can be found at apps/examples/module/driver/fsroot.
All of those file(s) should be copied to the USB FLASH drive. Like the
kelf configuration, the logic in apps/example/module will wait on power
up until the USB FLASH drive has been inserted and initialized.
STATUS:
2018-08-07: After some struggle, the configuration appears to be
working correctly.
knsh
----
This is identical to the nsh configuration below except that NuttX
is built as a PROTECTED mode, monolithic module and the user applications
are built separately.
NOTES:
1. See build recommendations and instructions for combining the .hex
files under the section entitled "Protected Mode Build" above.
module
------
A simple stripped down NSH configuration that was used for testing NuttX
OS modules using the test at apps/examples/module. Key difference from
the nsh configuration include these additions to the configuration file::
CONFIG_BOARDCTL_OS_SYMTAB=y
CONFIG_EXAMPLES_MODULE=y
CONFIG_EXAMPLES_MODULE_BUILTINFS=y
CONFIG_EXAMPLES_MODULE_DEVMINOR=0
CONFIG_EXAMPLES_MODULE_DEVPATH="/dev/ram0"
CONFIG_FS_ROMFS=y
CONFIG_LIBC_ARCH_ELF=y
CONFIG_MODULE=y
CONFIG_LIBC_MODLIB=y
CONFIG_MODLIB_MAXDEPEND=2
CONFIG_MODLIB_ALIGN_LOG2=2
CONFIG_MODLIB_BUFFERSIZE=128
CONFIG_MODLIB_BUFFERINCR=32
The could be followed may be added for testing shared libraries in the
FLAT build using apps/examples/sotest (assuming that you also have SD
card support enabled and that the SD card is mount at /mnt/sdcard)::
CONFIG_LIBC_DLFCN=y
CONFIG_EXAMPLES_SOTEST=y
CONFIG_EXAMPLES_SOTEST_BINDIR="/mnt/sdcard"
NOTE: You must always have::
CONFIG_STM32_CCMEXCLUDE=y
because code cannot be executed from CCM memory.
STATUS:
2018-06-01: Configuration added. Works perfectly.
nsh
---
This is the NuttShell (NSH) using the NSH startup logic at
apps/examples/nsh
NOTES:
1. USB host support for USB FLASH sticks is enabled. See the notes
above under "OTGFS Host".
STATUS: I have seen this work with some FLASH sticks but not with
others. I have not studied the failure case carefully. They seem
to fail because the request is NAKed. That is not a failure, however,
that is normal behavior when the FLASH is not ready.
There have been other cases like this with the STM32 host drivers:
in the event of NAKs, other drivers retry and wait for the data. The
STM32 does not but returns the NAK failure immediately. My guess is
that there needs to be be some retry logic to the driver 100%
reliable.
2. Kernel Modules / Shared Libraries
I used this configuration for testing NuttX kernel modules in the
FLAT build with the following configuration additions to the
configuration file::
CONFIG_BOARDCTL_OS_SYMTAB=y
CONFIG_EXAMPLES_MODULE=y
CONFIG_EXAMPLES_MODULE_BUILTINFS=y
CONFIG_EXAMPLES_MODULE_DEVMINOR=0
CONFIG_EXAMPLES_MODULE_DEVPATH="/dev/ram0"
CONFIG_FS_ROMFS=y
CONFIG_LIBC_ARCH_ELF=y
CONFIG_MODULE=y
CONFIG_LIBC_MODLIB=y
CONFIG_MODLIB_ALIGN_LOG2=2
CONFIG_MODLIB_BUFFERINCR=32
CONFIG_MODLIB_BUFFERSIZE=128
Add the following for testing shared libraries in the FLAT
build::
CONFIG_LIBC_DLFCN=y
CONFIG_EXAMPLES_SOTEST=y
CONFIG_EXAMPLES_SOTEST_BUILTINFS=y
CONFIG_EXAMPLES_SOTEST_DEVMINOR=1
CONFIG_EXAMPLES_SOTEST_DEVPATH="/dev/ram1"
zmodem
------
This configuration was used to test the zmodem utilities at
apps/system/zmodem. Two serial ports are used in this configuration:
1. USART6 (RS232_1) is the serial console (because it does not support
hardware flow control). It is configured 115200 8N1.
2. USART3 (RS232_2) is the zmodem port and does require that hardware
flow control be enabled for use. It is configured 9600 8N1.
On the target these will correspond to /dev/ttyS0 and /dev/ttyS1,
respectively.
It is possible to configure a system without hardware flow control and
using the same USART for both the serial console and for zmodem.
However, you would have to take extreme care with buffering and data
throughput considerations to assure that there is no Rx data overrun.
General usage instructions:
1. Common Setup::
[on target]
nsh> mount -t vfat /dev/sda /mnt
[on Linux host]
$ sudo stty -F /dev/ttyS0 9600
$ sudo stty -F /dev/ttyS0 crtscts *
$ sudo stty -F /dev/ttyS0 raw
$ sudo stty -F /dev/ttyS0
* Because hardware flow control will be enabled on the target side
in this configuration.
2. Host-to-Target File Transfer::
[on target]
nsh> rz
[on host]
$ sudo sz <filename> [-l nnnn] </dev/ttyS0 >/dev/ttyS0
Where <filename> is the file that you want to transfer. If -l nnnn is
not specified, then there will likely be packet buffer overflow errors.
nnnn should be set to a strictly less than CONFIG_SYSTEM_ZMODEM_PKTBUFSIZE.
All testing was performed with -l 512.
If you are using the NuttX implementation of rz and sz on the Linux host,
then the last command simplifies to just::
[on host]
$ cp README.txt /tmp/.
$ sudo ./sz -d /dev/ttyS1 README.txt
Assuming that /dev/ttyS0 is the serial and /dev/ttyS1 is the zmodem port
on the Linux host as well. NOTE: By default, files will be transferred
to and from the /tmp directory only.
Refer to the README file at apps/examples/zmodem for detailed information
about building rz/sz for the host and about zmodem usage in general.
3. Target-to-Host File Transfer::
[on host]
$ rz </dev/ttyS0 >/dev/ttyS0
The transferred file will end up in the current directory.
If you are using the NuttX implementation of rz and sz on the Linux host,
then the last command simplifies to just::
[on host]
$ ./rz
The transferred file will lie in the /tmp directory.
Then on the target side::
[on target]
nsh sz <filename>
Where <filename> is the file that you want to transfer.
STATUS
======
2016-12-21: This board configuration was ported from the Olimex STM32 P207
port. Note that none of the above features have been verified. USB, CAN,
ADC, and Ethernet are disabled in the base NSH configuration until they
can be verified. These features should be functional but may required
some tweaks due to the different clock configurations. The Olimex STM32
P207 nsh/defconfig would be a good starting place for restoring these
feature configurations.
CCM memory is not included in the heap (CONFIG_STM32_CCMEXCLUDE=y) because
it does not support DMA, leaving only 128KiB for program usage.
2017-01-23: Added the knsh configuration and support for the PROTECTED
build mode.
2018-05-27: Added the zmodem configuration. Verified correct operation
with host-to-target transfers (using Linux sz command). There appears
to be a problem using the NuttX sz command running on the host???
2018-05-28: Verified correct operation with target-to-host transfers (using
Linux rz command). There appears to be a problem using the NuttX rz
command running on the host???
2018-06-01: Added the module configuration. Works perfectly.

82
Documentation/platforms/arm/stm32f4/boards/omnibusf4/index.rst Normal file
View File

@ -0,0 +1,82 @@
=========
OMNIBUSF4
=========
"OmnibusF4" is not a product name per se, but rather a design spec
that many product vendors within the drone flight management unit
(FMU) community adhere to. The spec defines the major components, and
how those components are wired into the STM32F405RGT6 microcontroller.
Airbot is one such vendor, and they publish a schematic here:
http://bit.ly/obf4pro
Other software that supports the OmnibusF4 family include Betaflight,
iNAV, and many others. PX4 recently added support as well. No code
from any of those sources is included in this port.
Since OmnibusF4 is a drone FMU, most of its IO is already allocated to
FMU-specific tasks. As such, we don't need to make the board support
package as flexible as, say, an STM32F4 Discovery board.
..
The following are some of the committed IO pins. Most of the pins not
mentioned here are inaccessible, the details vary by board vendor:
io peripheral signal notes
==================================
XIN 8MHz crystal oscillator
PB0 TIM3 CH3 S1_OUT motor 1 PWM output
PB1 TIM3 CH4 S2_OUT motor 2 PWM output
PA3 TIM2 CH4 S3_OUT motor 3 PWM output
PA2 TIM2 CH3 S4_OUT motor 4 PWM output
PA1 TIM2 CH2 S5_OUT motor 5 PWM output
PA8 TIM1 CH4 S6_OUT motor 6 PWM output
PA4 SPI1 SPI1_NSS mpu6000
PA5 SPI1 SPI1_SCL
PA6 SPI1 SPI1_MISO
PA7 SPI1 SPI1_MOSI
PC4 GPIO GYRO_INT mpu6000 EXTI
PB10 UART3/I2C UART3_TX ttl UART tx or i2c_scl (used as console)
PB11 UART3/I2C UART3_RX ttl UART rx or i2c_sda (used as console)
PB9 RC_CH2 (rx pwm input)
PB8 RC_CH1 (rx pwm input)
PC9 RC_CH6 (rx pwm input)
PC8 RC_CH5 (rx pwm input)
PC7 RC_CH4 or USART6_RX (ttl)
PC6 RC_CH3 or USART6_TX (ttl)
PB7 GPIO SD_DET SD card detection pin (low when card inserted)
PB5 GPIO STAT LED output (active low)
PB4 GPIO BUZZER buzzer output (active low)
PD2 GPIO LED_STRIP one-wire interface for LED strips
PC12 SPI3 SPI3_MOSI bmp280 barometer (if populated) and/or max7456 OSD
PC11 SPI3 SPI3_MISO
PC10 SPI3 SPI3_SCL
PA15 GPIO SPI3_NSS OSD NSS
PB3 GPIO BARO_CS bmp280 NSS (if populated)
PA12 OTG USB_DP
PA11 OTG USB_DN
PA10 UART1 USART1_RX SBUS_IN (through inverter) or PPM
PA9 UART1 USART1_TX
PB15 SPI2 SPI2_MOSI sd/mmc card interface
PB14 SPI2 SPI2_MISO
PB13 SPI2 SPI2_SCLK
PB12 SPI2 SPI2_NSS
Build Instructions
==================
The boards/arm/stm32/omnibusf4/nsh/defconfig file creates a basic setup, and
includes drivers for all supported onboard chips. The console and
command prompt are sent to USART3.

842
Documentation/platforms/arm/stm32f4/boards/stm3240g-eval/index.rst Normal file
View File

@ -0,0 +1,842 @@
=================
ST STM32140G-EVAL
=================
This page discusses issues unique to NuttX configurations for the
STMicro STM32140G-EVAL development board.
Ethernet
========
The Ethernet driver is configured to use the MII interface:
Board Jumper Settings::
Jumper Description
JP8 To enable MII, JP8 should not be fitted.
JP6 2-3: Enable MII interface mode
JP5 2-3: Provide 25 MHz clock for MII or 50 MHz clock for RMII by MCO at PA8
SB1 Not used with MII
LEDs
====
The STM3240G-EVAL board has four LEDs labeled LD1, LD2, LD3 and LD4 on the
board.. These LEDs are not used by the board port unless CONFIG_ARCH_LEDS is
defined. In that case, the usage by the board port is defined in
include/board.h and src/up_leds.c. The LEDs are used to encode OS-related\
events as follows::
SYMBOL Meaning LED1[1] LED2 LED3 LED4
------------------- ----------------------- ------- ------- ------- ------
LED_STARTED NuttX has been started ON OFF OFF OFF
LED_HEAPALLOCATE Heap has been allocated OFF ON OFF OFF
LED_IRQSENABLED Interrupts enabled ON ON OFF OFF
LED_STACKCREATED Idle stack created OFF OFF ON OFF
LED_INIRQ In an interrupt[2] ON N/C N/C OFF
LED_SIGNAL In a signal handler[3] N/C ON N/C OFF
LED_ASSERTION An assertion failed ON ON N/C OFF
LED_PANIC The system has crashed N/C N/C N/C ON
LED_IDLE STM32 is is sleep mode (Optional, not used)
[1] If LED1, LED2, LED3 are statically on, then NuttX probably failed to boot
and these LEDs will give you some indication of where the failure was
[2] The normal state is LED3 ON and LED1 faintly glowing. This faint glow
is because of timer interrupts that result in the LED being illuminated
on a small proportion of the time.
[3] LED2 may also flicker normally if signals are processed.
PWM
===
The STM3240G-Eval has no real on-board PWM devices, but the board can be
configured to output a pulse train using timer output pins. The following
pins have been use to generate PWM output (see board.h for some other
candidates):
TIM4 CH2. Pin PD13 is used by the FSMC (FSMC_A18) and is also connected
to the Motor Control Connector (CN5) just for this purpose. If FSMC is
not enabled, then FSMC_A18 will not be used (and will be tri-stated from
the LCD).
CONFIGURATION::
CONFIG_STM32_TIM4=y
CONFIG_PWM=n
CONFIG_PWM_PULSECOUNT=n
CONFIG_STM32_TIM4_PWM=y
CONFIG_STM32_TIM4_CHANNEL=2
ACCESS::
Daughter board Extension Connector, CN3, pin 32
Ground is available on CN3, pin1
NOTE: TIM4 hardware will not support pulse counting.
TIM8 CH4: Pin PC9 is used by the microSD card (MicroSDCard_D1) and I2S
(I2S_CKIN) but can be completely disconnected from both by opening JP16.
CONFIGURATION::
CONFIG_STM32_TIM8=y
CONFIG_PWM=n
CONFIG_PWM_PULSECOUNT=y
CONFIG_STM32_TIM8_PWM=y
CONFIG_STM32_TIM8_CHANNEL=4
ACCESS::
Daughterboard Extension Connector, CN3, pin 17
Ground is available on CN3, pin1
CAN
===
Connector 10 (CN10) is DB-9 male connector that can be used with CAN1 or CAN2.::
JP10 connects CAN1_RX or CAN2_RX to the CAN transceiver
JP3 connects CAN1_TX or CAN2_TX to the CAN transceiver
CAN signals are then available on CN10 pins:::
CN10 Pin 7 = CANH
CN10 Pin 2 = CANL
Mapping to STM32 GPIO pins::
PD0 = FSMC_D2 & CAN1_RX
PD1 = FSMC_D3 & CAN1_TX
PB13 = ULPI_D6 & CAN2_TX
PB5 = ULPI_D7 & CAN2_RX
FSMC SRAM
=========
On-board SRAM
-------------
A 16 Mbit SRAM is connected to the STM32F407IGH6 FSMC bus which shares the same
I/Os with the CAN1 bus. Jumper settings::
JP1: Connect PE4 to SRAM as A20
JP2: onnect PE3 to SRAM as A19
JP3 and JP10 must not be fitted for SRAM and LCD application. JP3 and JP10
select CAN1 or CAN2 if fitted; neither if not fitted.
The on-board SRAM can be configured by setting::
CONFIG_STM32_FSMC=y
CONFIG_STM32_EXTERNAL_RAM=y
CONFIG_HEAP2_BASE=0x64000000
CONFIG_HEAP2_SIZE=2097152
CONFIG_MM_REGIONS=2 (or =3, see below)
Configuration Options
---------------------
Internal SRAM is available in all members of the STM32 family. The F4 family
also contains internal CCM SRAM. This SRAM is different because it cannot
be used for DMA. So if DMA needed, then the following should be defined
to exclude CCM SRAM from the heap::
CONFIG_STM32_CCMEXCLUDE : Exclude CCM SRAM from the HEAP
In addition to internal SRAM, SRAM may also be available through the FSMC.
In order to use FSMC SRAM, the following additional things need to be
present in the NuttX configuration file::
CONFIG_STM32_FSMC=y : Enables the FSMC
CONFIG_STM32_EXTERNAL_RAM=y : Indicates that SRAM is available via the
FSMC (as opposed to an LCD or FLASH).
CONFIG_HEAP2_BASE : The base address of the SRAM in the FSMC
address space
CONFIG_HEAP2_SIZE : The size of the SRAM in the FSMC
address space
CONFIG_MM_REGIONS : Must be set to a large enough value to
include the FSMC SRAM
SRAM Configurations
-------------------
There are 4 possible SRAM configurations::
Configuration 1. System SRAM (only)
CONFIG_MM_REGIONS == 1
CONFIG_STM32_EXTERNAL_RAM NOT defined
CONFIG_STM32_CCMEXCLUDE defined
Configuration 2. System SRAM and CCM SRAM
CONFIG_MM_REGIONS == 2
CONFIG_STM32_EXTERNAL_RAM NOT defined
CONFIG_STM32_CCMEXCLUDE NOT defined
Configuration 3. System SRAM and FSMC SRAM
CONFIG_MM_REGIONS == 2
CONFIG_STM32_EXTERNAL_RAM defined
CONFIG_STM32_CCMEXCLUDE defined
Configuration 4. System SRAM, CCM SRAM, and FSMC SRAM
CONFIG_MM_REGIONS == 3
CONFIG_STM32_ETXERNAL_RAM defined
CONFIG_STM32_CCMEXCLUDE NOT defined
I/O Expanders
=============
The STM3240G-EVAL has two STMPE811QTR I/O expanders on board both connected to
the STM32 via I2C1. They share a common interrupt line: PI2.
STMPE811 U24, I2C address 0x41 (7-bit)
====== ==== ================ ============================================
STPE11 PIN BOARD SIGNAL BOARD CONNECTION
====== ==== ================ ============================================
Y- TouchScreen_Y- LCD Connector XL
X- TouchScreen_X- LCD Connector XR
Y+ TouchScreen_Y+ LCD Connector XD
X+ TouchScreen_X+ LCD Connector XU
IN3 EXP_IO9
IN2 EXP_IO10
IN1 EXP_IO11
IN0 EXP_IO12
====== ==== ================ ============================================
STMPE811 U29, I2C address 0x44 (7-bit)
====== ==== ================ ============================================
STPE11 PIN BOARD SIGNAL BOARD CONNECTION
====== ==== ================ ============================================
Y- EXP_IO1
X- EXP_IO2
Y+ EXP_IO3
X+ EXP_IO4
IN3 EXP_IO5
IN2 EXP_IO6
IN1 EXP_IO7
IN0 EXP_IO8
====== ==== ================ ============================================
Configurations
==============
Each STM3240G-EVAL configuration is maintained in a sub-directory and
can be selected as follow::
tools/configure.sh stm3240g-eval:<subdir>
Where <subdir> is one of the following:
dhcpd
-----
This builds the DHCP server using the apps/examples/dhcpd application
(for execution from FLASH.) See apps/examples/README.txt for information
about the dhcpd example.
NOTES:
1. This configuration uses the mconf-based configuration tool. To
change this configurations using that tool, you should:
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
see additional README.txt files in the NuttX tools repository.
b. Execute 'make menuconfig' in nuttx/ in order to start the
reconfiguration process.
2. The server address is 10.0.0.1 and it serves IP addresses in the range
10.0.0.2 through 10.0.0.17 (all of which, of course, are configurable).
3. Default build environment (also easily reconfigured)::
CONFIG_HOST_WINDOWS=y
CONFIG_WINDOWS_CYGWIN=y
CONFIG_ARM_TOOLCHAIN_GNU_EABI=y
discover
--------
This configuration exercises netutils/discover utility using
apps/examples/discover. This example initializes and starts the UDP
discover daemon. This daemon is useful for discovering devices in
local networks, especially with DHCP configured devices. It listens
for UDP broadcasts which also can include a device class so that
groups of devices can be discovered. It is also possible to address all
classes with a kind of broadcast discover.
Configuration settings that you may need to change for your
environment::
CONFIG_ARM_TOOLCHAIN_GNU_EABI=y - GNU EABI toolchain for Linux
CONFIG_EXAMPLES_DISCOVER_DHCPC=y - DHCP Client
CONFIG_EXAMPLES_DISCOVER_IPADDR - (not defined)
CONFIG_EXAMPLES_DISCOVER_DRIPADDR - Router IP address
NOTE: This configuration uses to the kconfig-mconf configuration tool to
control the configuration. See the section entitled "NuttX Configuration
Tool" in the top-level README.txt file.
fb
--
A simple NSH configuration used for some basic (non-graphic) debug of
the framebuffer character driver at drivers/video/fb.c. NOTE that
the STM3240G-EVAL LCD driver does not support a framebuffer! It
interfaces with the LCD through a parallel FSMC interface. This
configuration uses the LCD framebuffer front end at
drivers/lcd/lcd_framebuffer to convert the LCD interface into a
compatible framebuffer interface.
This examples supports the framebuffer test at apps/examples/fb. That
test simply draws a pattern into the framebuffer and updates the LCD.
This example also supports the pdcurses library at apps/graphics/pdcurses
and the demo programs at apps/examples/pdcurses. This is a good test of
the use of the framebuffer driver in an application. Many of the
pdcurses demos requires user interaction via a mouse, keyboard, or
joystick. No input devices are currently present in the configuration
so no such interaction is possible.
The STM3240G-EVAL does provide a on-board discrete joystick (djoystick)
that could be used for this interaction. However, those discrete inputs
do not go directly to the STM32 but rather go indirectly through an I/O
expander. I just have not had the motivation to deal with that yet.
STATUS:
2017-09-17: This configuration appears to be fully functional.
2017-11-25: Non-interactive pdcurses examples added.
knxwm
-----
This is identical to the nxwm configuration below except that NuttX
is built as a kernel-mode, monolithic module and the user applications
are built separately. Is is recommended to use a special make command;
not just 'make' but make with the following two arguments::
make pass1 pass2
In the normal case (just 'make'), make will attempt to build both user-
and kernel-mode blobs more or less interleaved. This actual works!
However, for me it is very confusing so I prefer the above make command:
Make the user-space binaries first (pass1), then make the kernel-space
binaries (pass2)
NOTES:
1. This configuration uses the mconf-based configuration tool. To
change this configuration using that tool, you should:
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
see additional README.txt files in the NuttX tools repository.
b. Execute 'make menuconfig' in nuttx/ in order to start the
reconfiguration process.
2. This is the default platform/toolchain in the configuration:
CONFIG_HOST_WINDOWS=y : Windows
CONFIG_WINDOWS_CYGWIN=y : Cygwin environment on Windows
CONFIG_ARM_TOOLCHAIN_BUILDROOT=y : NuttX EABI buildroot toolchain
CONFIG_ARCH_SIZET_LONG=y : size_t is long (maybe?)
This is easily changed by modifying the configuration.
3. In addition to the protected mode build, this NxWM configuration
differences from the nxwm configuration in that:
a. Networking is disabled. There are issues with some of the network-
related NSH commands and with Telnet in the protected build (see the
top-level TODO file). Without these NSH commands, there is no use
for networking in this configuration.
b. The NxTerm windows are disabled. There are also issues with the
NxTerm build now.
NOTE: Those issues have been resolved. However, this configuration
has not yet be re-verified with NxTerm enabled.
c. The initialization sequence is quite different: NX and the
touchscreen are initialized in kernel mode by logic in this src/
directory before the NxWM application is started.
4. At the end of the build, there will be several files in the top-level
NuttX build directory:
PASS1:
nuttx_user.elf - The pass1 user-space ELF file
nuttx_user.hex - The pass1 Intel HEX format file (selected in defconfig)
User.map - Symbols in the user-space ELF file
PASS2:
nuttx - The pass2 kernel-space ELF file
nuttx.hex - The pass2 Intel HEX file (selected in defconfig)
System.map - Symbols in the kernel-space ELF file
5. Combining .hex files. If you plan to use the STM32 ST-Link Utility to
load the .hex files into FLASH, then you need to combine the two hex
files into a single .hex file. Here is how you can do that.
a. The 'tail' of the nuttx.hex file should look something like this
(with my comments added):
$ tail nuttx.hex
# 00, data records
...
:10 9DC0 00 01000000000800006400020100001F0004
:10 9DD0 00 3B005A0078009700B500D400F300110151
:08 9DE0 00 30014E016D0100008D
# 05, Start Linear Address Record
:04 0000 05 0800 0419 D2
# 01, End Of File record
:00 0000 01 FF
Use an editor such as vi to remove the 05 and 01 records.
b. The 'head' of the nuttx_user.hex file should look something like
this (again with my comments added):
$ head nuttx_user.hex
# 04, Extended Linear Address Record
:02 0000 04 0801 F1
# 00, data records
:10 8000 00 BD89 01084C800108C8110208D01102087E
:10 8010 00 0010 00201C1000201C1000203C16002026
:10 8020 00 4D80 01085D80010869800108ED83010829
...
Nothing needs to be done here. The nuttx_user.hex file should
be fine.
c. Combine the edited nuttx.hex and un-edited nuttx_user.hex
file to produce a single combined hex file:
$ cat nuttx.hex nuttx_user.hex >combined.hex
Then use the combined.hex file with the STM32 ST-Link tool. If
you do this a lot, you will probably want to invest a little time
to develop a tool to automate these steps.
STATUS:
2014-10-11: This worked at one time, but today I am getting a
failure inside of the GCC library. This occurred with the
computations at the end of touchscreen calibration. The
NuttX code seems to be working correctly, but there is some
problem with how the GCC integer math is hooked in??? I did
not dig into this very deeply.
nettest
-------
This configuration directory may be used to verify networking performance
using the STM32's Ethernet controller. It uses apps/examples/nettest to exercise the
TCP/IP network.::
CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : GNU EABI toolchain for Windows
CONFIG_EXAMPLES_NETTEST_SERVER=n : Target is configured as the client
CONFIG_EXAMPLES_NETTEST_PERFORMANCE=y : Only network performance is verified.
CONFIG_EXAMPLES_NETTEST_IPADDR=(10<<24|0<<16|0<<8|2) : Target side is IP: 10.0.0.2
CONFIG_EXAMPLES_NETTEST_DRIPADDR=(10<<24|0<<16|0<<8|1) : Host side is IP: 10.0.0.1
CONFIG_EXAMPLES_NETTEST_CLIENTIP=(10<<24|0<<16|0<<8|1) : Server address used by which ever is client.
NOTES:
1. This configuration uses the mconf-based configuration tool. To
change this configurations using that tool, you should:
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
see additional README.txt files in the NuttX tools repository.
b. Execute 'make menuconfig' in nuttx/ in order to start the
reconfiguration process.
nsh
---
Configures the NuttShell (nsh) located at apps/examples/nsh. The
Configuration enables both the serial and telnet NSH interfaces.::
CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : GNU EABI toolchain for Windows
CONFIG_NSH_DHCPC=n : DHCP is disabled
CONFIG_NSH_IPADDR=(10<<24|0<<16|0<<8|2) : Target IP address 10.0.0.2
CONFIG_NSH_DRIPADDR=(10<<24|0<<16|0<<8|1) : Host IP address 10.0.0.1
NOTES:
1. This configuration uses the mconf-based configuration tool. To
change this configurations using that tool, you should:
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
see additional README.txt files in the NuttX tools repository.
b. Execute 'make menuconfig' in nuttx/ in order to start the
reconfiguration process.
2. This example assumes that a network is connected. During its
initialization, it will try to negotiate the link speed. If you have
no network connected when you reset the board, there will be a long
delay (maybe 30 seconds?) before anything happens. That is the timeout
before the networking finally gives up and decides that no network is
available.
3. This example supports the ADC test (apps/examples/adc) but this must
be manually enabled by selecting::
CONFIG_ADC=y : Enable the generic ADC infrastructure
CONFIG_STM32_ADC3=y : Enable ADC3
CONFIG_STM32_TIM1=y : Enable Timer 1
CONFIG_STM32_TIM1_ADC=y : Indicate that timer 1 will be used to trigger an ADC
CONFIG_STM32_TIM1_ADC3=y : Assign timer 1 to drive ADC3 sampling
CONFIG_STM32_ADC3_SAMPLE_FREQUENCY=100 : Select a sampling frequency
See also apps/examples/README.txt
General debug for analog devices (ADC/DAC):
CONFIG_DEBUG_ANALOG
4. This example supports the PWM test (apps/examples/pwm) but this must
be manually enabled by selecting eeither::
CONFIG_PWM=y : Enable the generic PWM infrastructure
CONFIG_PWM_PULSECOUNT=n : Disable to support for TIM1/8 pulse counts
CONFIG_STM32_TIM4=y : Enable TIM4
CONFIG_STM32_TIM4_PWM=y : Use TIM4 to generate PWM output
CONFIG_STM32_TIM4_CHANNEL=2 : Select output on TIM4, channel 2
If CONFIG_STM32_FSMC is disabled, output will appear on CN3, pin 32.
Ground is available on CN3, pin1.
Or..
CONFIG_PWM=y : Enable the generic PWM infrastructure
CONFIG_PWM_PULSECOUNT=y : Enable to support for TIM1/8 pulse counts
CONFIG_STM32_TIM8=y : Enable TIM8
CONFIG_STM32_TIM8_PWM=y : Use TIM8 to generate PWM output
CONFIG_STM32_TIM8_CHANNEL=4 : Select output on TIM8, channel 4
If CONFIG_STM32_FSMC is disabled, output will appear on CN3, pin 17
Ground is available on CN23 pin1.
See also include/board.h and apps/examples/README.txt
Special PWM-only debug options:
CONFIG_DEBUG_PWM_INFO
5. This example supports the CAN loopback test (apps/examples/can) but this
must be manually enabled by selecting::
CONFIG_CAN=y : Enable the generic CAN infrastructure
CONFIG_CAN_EXTID=y or n : Enable to support extended ID frames
CONFIG_STM32_CAN1=y : Enable CAN1
CONFIG_CAN_LOOPBACK=y : Enable CAN loopback mode
See also apps/examples/README.txt
Special CAN-only debug options:
CONFIG_DEBUG_CAN_INFO
CONFIG_STM32_CAN_REGDEBUG
6. This example can support an FTP client. In order to build in FTP client
support simply uncomment the following lines in the defconfig file (before
configuring) or in the .config file (after configuring):
CONFIG_NETUTILS_FTPC=y
CONFIG_EXAMPLES_FTPC=y
7. This example can support an FTP server. In order to build in FTP server
support simply add the following lines in the defconfig file (before
configuring) or in the .config file (after configuring):
CONFIG_NETUTILS_FTPD=y
CONFIG_EXAMPLES_FTPD=y
8. This example supports the watchdog timer test (apps/examples/watchdog)
but this must be manually enabled by selecting:
CONFIG_WATCHDOG=y : Enables watchdog timer driver support
CONFIG_STM32_WWDG=y : Enables the WWDG timer facility, OR
CONFIG_STM32_IWDG=y : Enables the IWDG timer facility (but not both)
The WWDG watchdog is driven off the (fast) 42MHz PCLK1 and, as result,
has a maximum timeout value of 49 milliseconds. For WWDG watchdog, you
should also add the following to the configuration file:
CONFIG_EXAMPLES_WATCHDOG_PINGDELAY=20
CONFIG_EXAMPLES_WATCHDOG_TIMEOUT=49
The IWDG timer has a range of about 35 seconds and should not be an issue.
9. Adding LCD and graphics support:
defconfig (nuttx/.config):
CONFIG_EXAMPLES_nx=y : Pick one or more
CONFIG_EXAMPLES_nxhello=y :
CONFIG_EXAMPLES_nximage :
CONFIG_EXAMPLES_nxlines :
CONFIG_STM32_FSMC=y : FSMC support is required for the LCD
CONFIG_NX=y : Enable graphics support
CONFIG_MM_REGIONS=3 : When FSMC is enabled, so is the on-board SRAM memory region
10. USB OTG FS Device or Host Support
CONFIG_USBDEV : Enable USB device support, OR
CONFIG_USBHOST : Enable USB host support
CONFIG_STM32_OTGFS : Enable the STM32 USB OTG FS block
CONFIG_STM32_SYSCFG : Needed
CONFIG_SCHED_WORKQUEUE : Worker thread support is required
11. USB OTG FS Host Support. The following changes will enable support for
a USB host on the STM32F4Discovery, including support for a mass storage
class driver::
CONFIG_USBDEV=n : Make sure the USB device support is disabled
CONFIG_USBHOST=y : Enable USB host support
CONFIG_STM32_OTGFS=y : Enable the STM32 USB OTG FS block
CONFIG_STM32_SYSCFG=y : Needed for all USB OTF FS support
CONFIG_SCHED_WORKQUEUE=y : Worker thread support is required for the mass
storage class driver.
CONFIG_NSH_ARCHINIT=y : Architecture specific USB initialization
is needed for NSH
CONFIG_FS_FAT=y : Needed by the USB host mass storage class.
With those changes, you can use NSH with a FLASH pen driver as shown
belong. Here NSH is started with nothing in the USB host slot::
NuttShell (NSH) NuttX-x.yy
nsh> ls /dev
/dev:
console
null
ttyS0
After inserting the FLASH drive, the /dev/sda appears and can be
mounted like this::
nsh> ls /dev
/dev:
console
null
sda
ttyS0
nsh> mount -t vfat /dev/sda /mnt/stuff
nsh> ls /mnt/stuff
/mnt/stuff:
-rw-rw-rw- 16236 filea.c
And files on the FLASH can be manipulated to standard interfaces:
nsh> echo "This is a test" >/mnt/stuff/atest.txt
nsh> ls /mnt/stuff
/mnt/stuff:
-rw-rw-rw- 16236 filea.c
-rw-rw-rw- 16 atest.txt
nsh> cat /mnt/stuff/atest.txt
This is a test
nsh> cp /mnt/stuff/filea.c fileb.c
nsh> ls /mnt/stuff
/mnt/stuff:
-rw-rw-rw- 16236 filea.c
-rw-rw-rw- 16 atest.txt
-rw-rw-rw- 16236 fileb.c
To prevent data loss, don't forget to un-mount the FLASH drive
before removing it:
nsh> umount /mnt/stuff
12. By default, this configuration supports /dev/random using the STM32's
RNG hardware. This can be disabled as follows::
-CONFIG_STM32_RNG=y
+CONFIG_STM32_RNG=n
-CONFIG_DEV_RANDOM=y
+CONFIG_DEV_RANDOM=n
13. This configuration requires that jumper JP22 be set to enable RS-232
operation.
nsh2
-----
This is an alternative NSH configuration. One limitation of the STM3240G-EVAL
board is that you cannot have both a UART-based NSH console and SDIO support.
The nsh2 differs from the nsh configuration in the following ways::
-CONFIG_STM32_USART3=y : USART3 is disabled
+CONFIG_STM32_USART3=n
-CONFIG_STM32_SDIO=n : SDIO is enabled
+CONFIG_STM32_SDIO=y
Logically, these are the only differences: This configuration has SDIO (and
the SD card) enabled and the serial console disabled. There is ONLY a
Telnet console!.
There are some special settings to make life with only a Telnet::
CONFIG_RAMLOG=y - Enable the RAM-based logging feature.
CONFIG_CONSOLE_SYSLOG=y - Use the RAM logger as the default console.
This means that any console output from non-Telnet threads will
go into the circular buffer in RAM.
CONFIG_RAMLOG_SYSLOG - This enables the RAM-based logger as the
system logger. This means that (1) in addition to the console
output from other tasks, ALL of the debug output will also to
to the circular buffer in RAM, and (2) NSH will now support a
command called 'dmesg' that can be used to dump the RAM log.
There are a few other configuration differences as necessary to support
this different device configuration. Just the do the 'diff' if you are
curious.
NOTES:
1. This configuration uses the mconf-based configuration tool. To
change this configurations using that tool, you should:
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
see additional README.txt files in the NuttX tools repository.
b. Execute 'make menuconfig' in nuttx/ in order to start the
reconfiguration process.
2. See the notes for the nsh configuration. Most also apply to the nsh2
configuration. Like the nsh configuration, this configuration can
be modified to support a variety of additional tests.
3. RS-232 is disabled, but Telnet is still available for use as a console.
Since RS-232 and SDIO use the same pins (one controlled by JP22), RS232
and SDIO cannot be used concurrently.
4. This configuration requires that jumper JP22 be set to enable SDIO
operation. To enable MicroSD Card, which shares same I/Os with RS-232,
JP22 is not fitted.
5. In order to use SDIO without overruns, DMA must be used. The STM32 F4
has 192Kb of SRAM in two banks: 112Kb of "system" SRAM located at
0x2000:0000 and 64Kb of "CCM" SRAM located at 0x1000:0000. It appears
that you cannot perform DMA from CCM SRAM. The work around that I have now
is simply to omit the 64Kb of CCM SRAM from the heap so that all memory is
allocated from System SRAM. This is done by setting:
CONFIG_MM_REGIONS=1
Then DMA works fine. The downside is, of course, is that we lose 64Kb
of precious SRAM.
6. Another SDIO/DMA issue. This one is probably a software bug. This is
the bug as stated in the TODO list:
"If you use a large I/O buffer to access the file system, then the
MMCSD driver will perform multiple block SD transfers. With DMA
ON, this seems to result in CRC errors detected by the hardware
during the transfer. Workaround: CONFIG_MMCSD_MULTIBLOCK_LIMIT=1"
For this reason, CONFIG_MMCSD_MULTIBLOCK_LIMIT=1 appears in the defconfig
file.
7. Another DMA-related concern. I see this statement in the reference
manual: "The burst configuration has to be selected in order to respect
the AHB protocol, where bursts must not cross the 1 KB address boundary
because the minimum address space that can be allocated to a single slave
is 1 KB. This means that the 1 KB address boundary should not be crossed
by a burst block transfer, otherwise an AHB error would be generated,
that is not reported by the DMA registers."
There is nothing in the DMA driver to prevent this now.
nxterm
------
This is yet another NSH configuration. This NSH configuration differs
from the others, however, in that it uses the NxTerm driver to host
the NSH shell.
NOTES:
1. This configuration uses the mconf-based configuration tool. To
change this configurations using that tool, you should:
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
see additional README.txt files in the NuttX tools repository.
b. Execute 'make menuconfig' in nuttx/ in order to start the
reconfiguration process.
2. Some of the differences in this configuration and the normal nsh
configuration include these settings in the defconfig file:
These select NX Multi-User mode:
CONFG_NX_MULTIUSER=y
CONFIG_DISABLE_MQUEUE=n
The following definition in the defconfig file to enables the NxTerm
driver:
CONFIG_NXTERM=y
And this selects examples/nxterm instead of examples/nsh:
CONFIG_EXAMPLES_NXTERM=y
LCD Orientation:
CONFIG_LCD_LANDSCAPE=y : 320x240 landscape
3. Default build environment (also easily reconfigured):
CONFIG_HOST_WINDOWS=y : Windows
CONFIG_WINDOWS_CYGWIN=y : With Cygwin
CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : GNU EABI toolchain for Windows
nxwm
----
This is a special configuration setup for the NxWM window manager
UnitTest. The NxWM window manager can be found here::
apps/graphics/NxWidgets/nxwm
The NxWM unit test can be found at::
apps/graphics/NxWidgets/UnitTests/nxwm
telnetd
-------
A simple test of the Telnet daemon(see apps/netutils/README.txt,
apps/examples/README.txt, and apps/examples/telnetd). This is
the same daemon that is used in the nsh configuration so if you
use NSH, then you don't care about this. This test is good for
testing the Telnet daemon only because it works in a simpler
environment than does the nsh configuration.
NOTES:
1. This configuration uses the mconf-based configuration tool. To
change this configurations using that tool, you should:
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
see additional README.txt files in the NuttX tools repository.
b. Execute 'make menuconfig' in nuttx/ in order to start the
reconfiguration process.
2. Default build environment (easily reconfigured)::
CONFIG_HOST_WINDOWS=y
CONFIG_WINDOWS_CYGWIN=y
CONFIG_ARM_TOOLCHAIN_GNU_EABI=y
xmlrpc
------
An example configuration for the Embeddable Lightweight XML-RPC
Server at apps/examples/xmlrpc. See http://www.drdobbs.com/web-development/\
an-embeddable-lightweight-xml-rpc-server/184405364 for more info.
Contributed by Max Holtzberg.

90
boards/arm/stm32/stm32f411-minimum/README.txt → Documentation/platforms/arm/stm32f4/boards/stm32f411-minimum/index.rst
View File

@ -1,19 +1,10 @@
README
======
=================
stm32f411-minimum
=================
This README discusses issues unique to NuttX configurations for the
WeAct Studio MiniF4 minimum system development board.
Contents
========
- Board information
- LEDs
- UARTs
- USB
- SPI NOR Flash
- Configurations
Board information
=================
@ -34,14 +25,14 @@ https://stm32-base.org/boards/STM32F401CEU6-WeAct-Black-Pill-V3.0.html
The board features:
- On-board 64 Mbits (8 MBytes) External SPI-NOR Flash (optional),
- nRST reset button and BOOT0 ST BootROM entry button,
- One user LED and one user push-button,
- HSE 25 Mhz and LSE 32.768 kHz,
- USB OTG FS with micro-AB connector,
- Around 30 remappable GPIOs on 2.54mm headers (after excluding 7 power pins,
two LSE pins, the LED pin, NRST, BOOT1 and the SWD header),
- Serial Wire Debug header for use with an external SWD/JTAG adapter.
- On-board 64 Mbits (8 MBytes) External SPI-NOR Flash (optional),
- nRST reset button and BOOT0 ST BootROM entry button,
- One user LED and one user push-button,
- HSE 25 Mhz and LSE 32.768 kHz,
- USB OTG FS with micro-AB connector,
- Around 30 remappable GPIOs on 2.54mm headers (after excluding 7 power pins,
two LSE pins, the LED pin, NRST, BOOT1 and the SWD header),
- Serial Wire Debug header for use with an external SWD/JTAG adapter.
As F4 series have a USB DFuSe-capable BootROM [AN2606], the board can be flashed
via `dfu-util` over USB, or via `stm32flash` over UART without any debuggers.
@ -49,33 +40,43 @@ via `dfu-util` over USB, or via `stm32flash` over UART without any debuggers.
LEDs
====
The STM32F411 Minimum board has only one software controllable LED on PC13.
This LED can be used by the board port when CONFIG_ARCH_LEDS option is
enabled.
The STM32F411 Minimum board has only one software controllable LED on PC13.
This LED can be used by the board port when CONFIG_ARCH_LEDS option is
enabled.
If enabled the LED is simply turned on when the board boots
successfully, and is blinking on panic / assertion failed.
If enabled the LED is simply turned on when the board boots
successfully, and is blinking on panic / assertion failed.
UARTs
=====
UART/USART PINS
---------------
USART1
------
USART1
TX PA9
RX PA10
USART2
CTS PA0
RTS PA1
TX PA2
RX PA3
CK PA4
========== =====
UART/USART PINS
========== =====
TX PA9
RX PA10
========== =====
USART2
------
========== =====
UART/USART PINS
========== =====
CTS PA0
RTS PA1
TX PA2
RX PA3
CK PA4
========== =====
Default USART/UART Configuration
--------------------------------
USART1 (RX & TX only) is available through pins PA9 (TX) and PA10 (RX).
USART1 (RX & TX only) is available through pins PA9 (TX) and PA10 (RX).
USB
===
@ -105,17 +106,18 @@ Configurations
==============
Each stm32f411-minimum configuration is maintained in a sub-directory and
can be selected as follow:
can be selected as follow::
tools/configure.sh stm32f411-minimum:<subdir>
Where <subdir> is one of the following:
Configuration Directories
-------------------------
Configuration Directories
-------------------------
nsh:
---
Configures the NuttShell (nsh) located at apps/examples/nsh. This
configuration enables a serial console on UART1.
nsh
---
Configures the NuttShell (nsh) located at apps/examples/nsh. This
configuration enables a serial console on UART1.

5
boards/arm/stm32/stm32f411e-disco/README.txt → Documentation/platforms/arm/stm32f4/boards/stm32f411e-disco/index.rst
View File

@ -1,5 +1,6 @@
README
======
=======================
ST STM32F411E-Discovery
=======================
This README discusses issues unique to NuttX configurations for the STMicro
STM32F411E-Discovery board. See

749
Documentation/platforms/arm/stm32f4/boards/stm32f429i-disco/index.rst Normal file
View File

@ -0,0 +1,749 @@
================
STM32F429I-DISCO
================
This README discusses issues unique to NuttX configurations for the
STMicro STM32F429I-DISCO development board featuring the STM32F429ZIT6
MCU. The STM32F429ZIT6 is a 180MHz Cortex-M4 operation with 2Mbit Flash
memory and 256kbytes. The board features:
- On-board ST-LINK/V2 for programming and debugging,
- On-board 64 Mbits (8 Mbytes) External SDRAM (1 Mbit x 16-bit x 4-bank)
- L3GD20, ST MEMS motion sensor, 3-axis digital output gyroscope,
- TFT 2.4" LCD, 262K color RGB, 240 x 320 pixels
- Touchscreen controller
- Two user LEDs and two push-buttons,
- USB OTG FS with micro-AB connector, and
- Easy access to most MCU pins.
NOTE: Includes basic NSH command support with full 8MByte SDRAM + the
internal 256K. Unsupported are the LCD and USB interfaces.
The board pin configuration to support on-board SDRAM and LCD
prevents use of the OTG FS module which is normally used for USB
NSH sessions. Instead, the board routes the OTG HS pins to the
USB OTG connector.
The NSH configuration / testing that has been done so far was
performed by connecting an external RS-232 line driver to pins
PA9 (TX) and PA10 (RX) and configuring USART1 as the NSH console.
Refer to the http://www.st.com website for further information about this
board (search keyword: 429i-disco)
NOTE: This port was based on the original discovery kit, STM32F429I-DISCO.
That board has been superseded by the new STM32F429I-DISC1.
Setup and Programming Flash
===========================
I use a USB cable to power and program it. And I use a USB/Serial
connected to pins PA9 and PA10 for the serial console (See the section
"UARTs" below).
FLASH may be programmed:
- Via USB using STM32 ST-Link Utility
- Via USB using OpenOCD. This command may be used to flash the
firmware using OpenOCD::
$ sudo openocd -f interface/stlink-v2.cfg -f target/stm32f4x.cfg -c init -c "reset halt" -c "flash write_image erase nuttx.bin 0x08000000"
- Via JTAG/SWD connected to the SWD connector CN2.
CN4 Jumpers. Remove jumpers to enable signals at SWD connector CN2.::
SWD 6-Pin STM32F429i-Discovery Connector CN2
Pin Signal Name Description
----- ------ ---------- ------------------------------
Pin 1 AIN_1 VDD_TARGET VDD from application
Pin 2 T_JCLK SWCLK SWD Clock
Pin 3 GND GND Ground
Pin 4 T_JTMS SWDIO SWD data input/output
Pin 5 T_NRST NRST Reset of target MCU
Pin 6 T_SWO SWO Reserved
SWD 20-pin J-Link Connector
Pin Name Type Description
------ --------- ------ ------------------------------
Pin 1 VTref Input Target reference voltage
Pin 2 Vsupply NC Not connected in J-Link
Pin 3 Not used NC Not used in J-Link
Pin 5 Not used NC Not used in J-Link
Pin 7 SWDIO I/O Bi-directional data pin
Pin 9 SWCLK Output Clock signal to target CPU
Pin 11 Not used NC Not used in J-Link
Pin 13 SWO Output Serial wire output trace port
Pin 15 RESET I/O Target CPU reset signal (nRST)
Pin 17 Not used NC Not connected in J-Link
Pin 19 5V-Supply Output Supplies power to some boards.
Pins 4, 45, 8, 10, 12, 14, 16, 18 and 20 are GND pins in J-Link. They
should also be connected to ground in the target system.
LEDs
====
The STM32F429I-DISCO board has two user LEDs; green, and red on the board.
These LEDs are not used by the board port unless CONFIG_ARCH_LEDS is
defined. In that case, the usage by the board port is defined in
include/board.h and src/up_leds.c. The LEDs are used to encode OS-related
events as follows::
SYMBOL Meaning LED1* LED2
green red
------------------- ----------------------- ------- -------
LED_STARTED NuttX has been started ON OFF
LED_HEAPALLOCATE Heap has been allocated OFF ON
LED_IRQSENABLED Interrupts enabled ON ON
LED_STACKCREATED Idle stack created OFF ON
LED_INIRQ In an interrupt** ON ON
LED_SIGNAL In a signal handler N/C ON
LED_ASSERTION An assertion failed ON ON
LED_PANIC The system has crashed ON BLINK
LED_IDLE STM32 is is sleep mode (Optional, not used)
* In normal mode, LED1 will be on and LED2 might flicker a bit as IRQs
and SIGNALS are processed.
* If LED1 is on and LED2 is blinking, then NuttX probably failed to boot
or is in a PANIC condition.
UARTs
=====
On the STM32F429I-DISCO board, because of pin mappings to support the
onboard SDRAM and LCD, the only UARTs that have both RX and TX pins
available are USART1 and UART5. Other USARTS could be used for RX or TX
only, or they could be used for full-duplex if the other pin functions
aren't being used (i.e. LCD or SDRAM).
UART/USART PINS
---------------
..
USART1
CK PA8[1]
CTS PA11[1]
RTS PA12[1]
RX PA10, PB7
TX PA9, PB6[1]
USART2
CK PA4[1], PD7
CTS PA0[1], PD3[1]
RTS PA1[1], PD4
RX PA3[1], PD6[1]
TX PA2[1], PD5
USART3
CK PB12[1], PC12, PD10[1]
CTS PB13[1], PD11[1]
RTS PB14[1], PD12[1]
RX PB11[1], PC11, PD9[1]
TX PB10[1], PC10[1], PD8[1]
UART4
RX PA1[1], PC11
TX PA0[1], PC10[1]
UART5
RX PD2
TX PC12
USART6
CK PC8, PG7[1]
CTS PG13[1], PG15[1]
RTS PG12[1], PG8[1]
RX PC7[1], PG9
TX PC6[1], PG14[1]
UART7
RX PE7[1], PF6
TX PE8[1], PF7[1]
[1] Indicates pins that have other on-board functions and should be used only
with care (See table 6 in the STM32F429I-DISCO User Guide for a list of free
I/O pins on the board).
Default Serial Console
----------------------
USART1 is enabled as the serial console in all configurations (see \*/defconfig).
USART1 RX and TX are configured on pins PA10 and PA9, respectively (see
include/board.h).::
Header 32X2 P1
--------------
Pin 1 5V
Pin 51 PA10
Pin 52 PA9
Pin 63 GND
If solder bridges SB11 and SB12 are closed, then USART1 will be connected to
the ST-Link and should be available over USB as a virtual COM interface.
Timer Inputs/Outputs
====================
::
TIM1
CH1 PA8[1], PE9[1]
CH2 PA9, PE11[1]
CH3 PA10, PE13[1]
CH4 PA11[1], PE14[1]
TIM2
CH1 PA0[1], PA15[1], PA5
CH2 PA1[1], PB3[1]
CH3 PA2[1], PB10[1]
CH4 PA3[1], PB11[1]
TIM3
CH1 PA6[1], PB4, PC6[1]
CH2 PA7[1], PB5[1], PC7[1]
CH3 PB0[1], PC8
CH4 PB1[1], PC9[1]
TIM4
CH1 PB6[1], PD12[1]
CH2 PB7, PD13[1]
CH3 PB8[1], PD14[1]
CH4 PB9[1], PD15[1]
TIM5
CH1 PA0[1], PH10[1]
CH2 PA1[1], PH11[1]
CH3 PA2[1], PH12[1]
CH4 PA3[1], PI0[2]
TIM8
CH1 PC6[1], PI5[2]
CH2 PC7[1], PI6[2]
CH3 PC8, PI7[2]
CH4 PC9[1], PI2[2]
TIM9
CH1 PA2[1], PE5
CH2 PA3[1], PE6
TIM10
CH1 PB8[1], PF6
TIM11
CH1 PB9[1], PF7[1]
TIM12
CH1 PH6[1], PB14[1]
CH2 PC15[1], PH9[1]
TIM13
CH1 PA6[1], PF8[1]
TIM14
CH1 PA7[1], PF9[1]
[1] Indicates pins that have other on-board functions and should be used only
with care (See table 6 in the STM32F429I-DISCO User Guide). The rest are
free I/O pins (This need to be updated. They are incorrect!)
[2] Port I pins are not supported by the MCU
FMC SDRAM
=========
On-board SDRAM
--------------
The STM32F429I-DISCO has 8 MBytes on-board SDRAM connected to the MCU's
SDRAM Bank 2 connections (Bank 6 of the FMC). This means the 8 MiB
(when enabled) is mapped to address 0xD0000000-0xD07FFFFF. The port for
the STM32F429I-DISCO board includes support for using the onboard 8M SDRAM.
Configuration Options
---------------------
Internal SRAM is available in all members of the STM32 family. The F4 family
also contains internal CCM SRAM. This SRAM is different because it cannot
be used for DMA. So if DMA needed, then the following should be defined
to exclude CCM SRAM from the heap::
CONFIG_STM32_CCMEXCLUDE : Exclude CCM SRAM from the HEAP
In addition to internal SRAM, SRAM may also be available through the FMC.
In order to use FMC SDRAM, the following additional things need to be
present in the NuttX configuration file::
CONFIG_STM32_FMC=y : Enables the FMC and the 8MiB SDRAM
CONFIG_STM32_EXTERNAL_RAM=y : Indicates that RAM is available via the
FMC (as opposed to an LCD or FLASH).
CONFIG_HEAP2_BASE : The base address of the RAM in the FMC
address space. This should be 0xD0000000.
CONFIG_HEAP2_SIZE : The size of the RAM in the FMC
address space. This should be 8388608.
CONFIG_MM_REGIONS : Must be set to a large enough value to
include the FMC SDRAM (1, 2 or 3 depending
if the CCM RAM and/or FMC SDRAM are enabled).
SRAM Configurations
--------------------
There are 4 possible SRAM configurations::
Configuration 1. System SRAM (only)
CONFIG_MM_REGIONS == 1
CONFIG_STM32_EXTERNAL_RAM NOT defined
CONFIG_STM32_CCMEXCLUDE defined
Configuration 2. System SRAM and CCM SRAM
CONFIG_MM_REGIONS == 2
CONFIG_STM32_EXTERNAL_RAM NOT defined
CONFIG_STM32_CCMEXCLUDE NOT defined
Configuration 3. System SRAM and FMC SDRAM
CONFIG_MM_REGIONS == 2
CONFIG_STM32_EXTERNAL_RAM defined
CONFIG_STM32_CCMEXCLUDE defined
Configuration 4. System SRAM, CCM SRAM, and FMC SDRAM
CONFIG_MM_REGIONS == 3
CONFIG_STM32_EXTERNAL_RAM defined
CONFIG_STM32_CCMEXCLUDE NOT defined
Configurations
==============
Each STM32F429I-DISCO configuration is maintained in a sub-directory and
can be selected as follow::
tools/configure.sh stm32f429i-disco:<subdir>
Where <subdir> is one of the following:
extflash:
---------
This is another NSH example. If differs from other 'nsh' configurations
in that this configuration defines an external 8 MByte SPI FLASH (the
SST25VF064C part from Silicon Storage Technology, Inc.) which must be
be connected to the Discovery board's SPI4 pins on the expansion pins.
Additionally, this demo uses UART1 for the console
NOTES:
1. This configuration assumes an SST25VF064C 8Mbyte SPI FLASH is
connected to SPI4 on the following Discovery board Pins::
SCK: Port PE2 Board Connector P1, Pin 15
MOSI: Port PE6 Board Connector P1, Pin 11
MISO: Port PE5 Board Connector P1, Pin 14
CS: Port PE4 Board Connector P1, Pin 13
2. This configuration does have UART1 output enabled and set up as
the system logging device. To use this UART, you must add an
external RS-232 line driver to the UART1 pins of the DISCO board
on PA9 and PA10 of connector P1.
fb
--
STM32F429I-DISCO LTDC Framebuffer demo example. This is a simple
configuration used for some basic (non-graphic) debug of the framebuffer
character drivers using apps/examples/fb. It simply opens the framebuffer
device and draws concentric rectangles of different colors in the
framebuffer::
nsh> fb
Also included is the touchscreen test of apps/examples/touchscreen. This
example will simply open the touchscreen driver then collect and display
touch inputs::
nsh> tc 1
tc_main: nsamples: 1
tc_main: Initializing external touchscreen device
tc_main: Opening /dev/input0
Sample :
npoints : 1
Point 1 :
id : 0
flags : 3c
x : 2296
y : 2311
h : 0
w : 0
pressure : 1
Terminating!
nsh>
lgvl
----
STM32F429I-DISCO LittlevGL demo example.
The ltdc is initialized during boot up. Interaction with NSH is via
the serial console at 115200 8N1 baud. From the nsh command line
execute the lvgldemo example::
nsh> lvgldemo
The test will execute the calibration process and then run the
LittlevGL demo project.
nsh
---
Configures the NuttShell (nsh) located at apps/examples/nsh. The
Configuration enables the serial interfaces on UART2. Support for
builtin applications is enabled, but in the base configuration no
builtin applications are selected (see NOTES below).
NOTES:
1. This configuration uses the mconf-based configuration tool. To
change this configuration using that tool, you should:
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
see additional README.txt files in the NuttX tools repository.
b. Execute 'make menuconfig' in nuttx/ in order to start the
reconfiguration process.
2. By default, this configuration uses the ARM EABI toolchain
for Windows and builds under Cygwin (or probably MSYS). That
can easily be reconfigured, of course.::
CONFIG_HOST_WINDOWS=y : Builds under Windows
CONFIG_WINDOWS_CYGWIN=y : Using Cygwin
CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : GNU EABI toolchain for Windows
3. This example supports the PWM test (apps/examples/pwm) but this must
be manually enabled by selecting::
CONFIG_PWM=y : Enable the generic PWM infrastructure
CONFIG_STM32_TIM4=y : Enable TIM4
CONFIG_STM32_TIM4_PWM=y : Use TIM4 to generate PWM output
See also apps/examples/README.txt
Special PWM-only debug options::
CONFIG_DEBUG_PWM_INFO
5. This example supports the Quadrature Encode test (apps/examples/qencoder)
but this must be manually enabled by selecting::
CONFIG_EXAMPLES_QENCODER=y : Enable the apps/examples/qencoder
CONFIG_SENSORS=y : Enable support for sensors
CONFIG_SENSORS_QENCODER=y : Enable the generic Quadrature Encoder infrastructure
CONFIG_STM32_TIM8=y : Enable TIM8
CONFIG_STM32_TIM2=n : (Or optionally TIM2)
CONFIG_STM32_TIM8_QE=y : Use TIM8 as the quadrature encoder
CONFIG_STM32_TIM2_QE=y : (Or optionally TIM2)
See also apps/examples/README.txt. Special debug options::
CONFIG_DEBUG_SENSORS
6. This example supports the watchdog timer test (apps/examples/watchdog)
but this must be manually enabled by selecting::
CONFIG_EXAMPLES_WATCHDOG=y : Enable the apps/examples/watchdog
CONFIG_WATCHDOG=y : Enables watchdog timer driver support
CONFIG_STM32_WWDG=y : Enables the WWDG timer facility, OR
CONFIG_STM32_IWDG=y : Enables the IWDG timer facility (but not both)
The WWDG watchdog is driven off the (fast) 42MHz PCLK1 and, as result,
has a maximum timeout value of 49 milliseconds. for WWDG watchdog, you
should also add the following to the configuration file::
CONFIG_EXAMPLES_WATCHDOG_PINGDELAY=20
CONFIG_EXAMPLES_WATCHDOG_TIMEOUT=49
The IWDG timer has a range of about 35 seconds and should not be an issue.
7. USB Support (CDC/ACM device)::
CONFIG_STM32_OTGFS=y : STM32 OTG FS support
CONFIG_USBDEV=y : USB device support must be enabled
CONFIG_CDCACM=y : The CDC/ACM driver must be built
CONFIG_NSH_BUILTIN_APPS=y : NSH built-in application support must be enabled
CONFIG_NSH_ARCHINIT=y : To perform USB initialization
8. Using the USB console.
The STM32F429I-DISCO NSH configuration can be set up to use a USB CDC/ACM
(or PL2303) USB console. The normal way that you would configure the
the USB console would be to change the .config file like this::
CONFIG_STM32_OTGFS=y : STM32 OTG FS support
CONFIG_USART2_SERIAL_CONSOLE=n : Disable the USART2 console
CONFIG_DEV_CONSOLE=n : Inhibit use of /dev/console by other logic
CONFIG_USBDEV=y : USB device support must be enabled
CONFIG_CDCACM=y : The CDC/ACM driver must be built
CONFIG_CDCACM_CONSOLE=y : Enable the CDC/ACM USB console.
NOTE: When you first start the USB console, you have hit ENTER a few
times before NSH starts. The logic does this to prevent sending USB data
before there is anything on the host side listening for USB serial input.
9. Here is an alternative USB console configuration. The following
configuration will also create a NSH USB console but this version
will use /dev/console. Instead, it will use the normal /dev/ttyACM0
USB serial device for the console::
CONFIG_STM32_OTGFS=y : STM32 OTG FS support
CONFIG_USART2_SERIAL_CONSOLE=y : Keep the USART2 console
CONFIG_DEV_CONSOLE=y : /dev/console exists (but NSH won't use it)
CONFIG_USBDEV=y : USB device support must be enabled
CONFIG_CDCACM=y : The CDC/ACM driver must be built
CONFIG_CDCACM_CONSOLE=n : Don't use the CDC/ACM USB console.
CONFIG_NSH_USBCONSOLE=y : Instead use some other USB device for the console
The particular USB device that is used is::
CONFIG_NSH_USBCONDEV="/dev/ttyACM0"
The advantage of this configuration is only that it is easier to
bet working. This alternative does has some side effects:
- When any other device other than /dev/console is used for a user
interface, linefeeds (\n) will not be expanded to carriage return /
linefeeds (\r\n). You will need to set your terminal program to account
for this.
- /dev/console still exists and still refers to the serial port. So
you can still use certain kinds of debug output (see include/debug.h, all
debug output from interrupt handlers will be lost.
- But don't enable USB debug output! Since USB is console is used for
USB debug output and you are using a USB console, there will be
infinite loops and deadlocks: Debug output generates USB debug
output which generatates USB debug output, etc. If you want USB
debug output, you should consider enabling USB trace
(CONFIG_USBDEV_TRACE) and perhaps the USB monitor (CONFIG_USBMONITOR).
See the usbnsh configuration below for more information on configuring
USB trace output and the USB monitor.
10. USB OTG FS Host Support. The following changes will enable support for
a USB host on the STM32F429I-DISCO, including support for a mass storage
class driver:
Device Drivers ->
CONFIG_USBDEV=n : Make sure the USB device support is disabled
CONFIG_USBHOST=y : Enable USB host support
CONFIG_USBHOST_ISOC_DISABLE=y
Device Drivers -> USB Host Driver Support
CONFIG_USBHOST_MSC=y : Enable the mass storage class
System Type -> STM32 Peripheral Support
CONFIG_STM32_OTGHS=y : Enable the STM32 USB OTG FH block (FS mode)
CONFIG_STM32_SYSCFG=y : Needed for all USB OTF HS support
RTOS Features -> Work Queue Support
CONFIG_SCHED_WORKQUEUE=y : High priority worker thread support is required
CONFIG_SCHED_HPWORK=y : for the mass storage class driver.
File Systems ->
CONFIG_FS_FAT=y : Needed by the USB host mass storage class.
Board Selection ->
CONFIG_BOARDCTL=y : Needed for CONFIG_NSH_ARCHINIT
Application Configuration -> NSH Library
CONFIG_NSH_ARCHINIT=y : Architecture specific USB initialization
: is needed for NSH
With those changes, you can use NSH with a FLASH pen driver as shown
belong. Here NSH is started with nothing in the USB host slot:
NuttShell (NSH) NuttX-x.yy
nsh> ls /dev
/dev:
console
null
ttyS0
After inserting the FLASH drive, the /dev/sda appears and can be
mounted like this:
nsh> ls /dev
/dev:
console
null
sda
ttyS0
nsh> mount -t vfat /dev/sda /mnt/stuff
nsh> ls /mnt/stuff
/mnt/stuff:
-rw-rw-rw- 16236 filea.c
And files on the FLASH can be manipulated to standard interfaces:
nsh> echo "This is a test" >/mnt/stuff/atest.txt
nsh> ls /mnt/stuff
/mnt/stuff:
-rw-rw-rw- 16236 filea.c
-rw-rw-rw- 16 atest.txt
nsh> cat /mnt/stuff/atest.txt
This is a test
nsh> cp /mnt/stuff/filea.c fileb.c
nsh> ls /mnt/stuff
/mnt/stuff:
-rw-rw-rw- 16236 filea.c
-rw-rw-rw- 16 atest.txt
-rw-rw-rw- 16236 fileb.c
To prevent data loss, don't forget to un-mount the FLASH drive
before removing it:
nsh> umount /mnt/stuff
11. I used this configuration to test the USB hub class. I did this
testing with the following changes to the configuration (in addition
to those listed above for base USB host/mass storage class support):
Drivers -> USB Host Driver Support
CONFIG_USBHOST_HUB=y : Enable the hub class
CONFIG_USBHOST_ASYNCH=y : Asynchronous I/O supported needed for hubs
Board Selection ->
CONFIG_STM32F429IDISCO_USBHOST_STACKSIZE=2048 (bigger than it needs to be)
RTOS Features -> Work Queue Support
CONFIG_SCHED_LPWORK=y : Low priority queue support is needed
CONFIG_SCHED_LPNTHREADS=1
CONFIG_SCHED_LPWORKSTACKSIZE=1024
NOTES:
1. It is necessary to perform work on the low-priority work queue
(vs. the high priority work queue) because deferred hub-related
work requires some delays and waiting that is not appropriate on
the high priority work queue.
2. Stack usage make increase when USB hub support is enabled because
the nesting depth of certain USB host class logic can increase.
STATUS:
2015-04-30
Appears to be fully functional.
nx
--
This a simple test using the graphic example at apps/example/nx. This
configuration illustrates the use of the LCD with the lower performance
SPI interface.
nxwm
----
This is a special configuration setup for the NxWM window manager
UnitTest.
NOTES:
1. The NxWM window manager can be found here::
apps/graphics/NxWidgets/nxwm
The NxWM unit test can be found at::
apps/graphics/NxWidgets/UnitTests/nxwm
STATUS:
17-01-08: There are instabilities in this configuration that make it
not usable on this platform. While the equivalent configuration works
on other platforms, this one does not: The calculator display does
not form properly. There are fails in the NxTerm display, usually
around the point where the display should scroll up.
Update: With all optimizations disabled, the issue seems to go away.
So this is most likely due to using high levels of optimization with a
bleeding edge GCC toolchain.
17-11-15: The original configuration used the slower SPI LCD interface.
The configuration was converted to use the high performance LTDC frame
buffer interface. Performance is now excellent and I see none of the
instabilities mentioned above even at high levels of optimization.
The difficulty that I experienced was touching the tiny icons on the
menus. The touscreen controller (along with my fat fingers) does not
appear to have sufficient precision to work in this way. Larger icons
would likely make the interface easier to use.
usbnsh
------
This is another NSH example. If differs from other 'nsh' configurations
in that this configurations uses a USB serial device for console I/O.
Such a configuration is useful on the stm32f429i-disco which has no
builtin RS-232 drivers.
NOTES:
1. This configuration uses the mconf-based configuration tool. To
change this configuration using that tool, you should:
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
see additional README.txt files in the NuttX tools repository.
b. Execute 'make menuconfig' in nuttx/ in order to start the
reconfiguration process.
2. This configuration does have UART1 output enabled and set up as
the system logging device. To use this UART, you must add an
external RS-232 line driver to the UART1 pins of the DISCO board
on PA9 and PA10 of connector P1.
usbmsc
------
This is an example of enabling the FS OTG port on the DISCO board for
mass storage use. It provides an NSH session on UART1 to allow
accessing the connected USB mass storage device. Such a configuration
is useful on the stm32f429i-disco which has no onboard SD card or mass
storage solution.
NOTES:
1. This configuration uses UART1 as the system console. To use this
UART, you must add an external RS-232 line driver to the UART1 pins
of the DISCO board on PA9 and PA10 of connector P1.
2. The mass storage device will appear as /dev/sda and supports FAT
formatted "thumb" flash drives with::
nsh> mount -t vfat /dev/sda /mount_name
STM32F429I-DISCO LTDC Framebuffer demo example
==============================================
STM32F429I-DISCO LTDC Framebuffer demo example
Configure and build
-------------------
::
cd tools
./configure -a <appdir> stm32f429i-disco/fb
cd ..
make
Framebuffer calculation
-----------------------
Use the helper script boards/stm32f429i-disco/tools/fbcalc.sh for calculating
the heap2 and framebuffer memory region. The script assumes that all overlay
buffers (LTDC and DMA2D) located in heap2 memory region starting at address
0xD0000000. When changing the display size (when using a custom display), DMA2D
overlay size or the pixel format you have to recalculate the heap2 settings.
In this configuration all overlays (LTDC and DMA2D) positioned at the end of
heap2.
Configuration
-------------
This configuration provides 2 LTDC (visible overlays) and 2 DMA2D overlays with
pixel format RGB565 and a resolution of 240x320.
Loading
-------
st-flash write nuttx.bin 0x8000000
Executing
---------
The ltdc is initialized during boot up. Interaction with NSH is via the serial
console at 115200 8N1 baud. From the nsh comandline execute the fb example::
nsh> fb
The test will put a pattern of concentric squares in the framebuffer and
terminate.
You can also test overlay hardware acceleration functionality by executing the
following command (shows a commandline help)::
nsh> fboverlay

2182
Documentation/platforms/arm/stm32f4/boards/stm32f4discovery/index.rst Normal file
View File

File diff suppressed because it is too large Load Diff

536
Documentation/platforms/arm/stm32f4/index.rst Normal file
View File

@ -0,0 +1,536 @@
==========
ST STM32F4
==========
Supported MCUs
==============
TODO
Peripheral Support
==================
The following list indicates peripherals supported in NuttX:
========== ======= =====
Peripheral Support Notes
========== ======= =====
IRQs Yes
GPIO Yes
EXTI Yes
HSE Yes
PLL Yes
HSI Yes
MSI Yes
LSE Yes
RCC Yes
SYSCFG Yes
USART Yes
FLASH Yes
DMA Yes
SPI Yes
I2C Yes
I2S Yes
FMPI2C No
SPDIFRX No
SAI No
RTC Yes
Timers Yes
PM Yes
RNG Yes
CRC No
HASH No
ADC Yes
DAC Yes
WWDG Yes
IWDG Yes
CAN Yes
USB FS Yes
USB HS Yes
ETH Yes
FMC Yes
QSPI Yes
DCMI No
AES Yes
HDMI-CED No
SDIO Yes
========== ======= =====
Memory
------
CONFIG_RAM_SIZE - Describes the installed DRAM (SRAM in this case):
CONFIG_RAM_SIZE=16384 (16Kb)
CONFIG_RAM_START - The start address of installed DRAM
CONFIG_RAM_START=0x20000000
CONFIG_STM32_CCMEXCLUDE - Exclude CCM SRAM from the HEAP
CONFIG_ARCH_INTERRUPTSTACK - This architecture supports an interrupt
stack. If defined, this symbol is the size of the interrupt
stack in bytes. If not defined, the user task stacks will be
used during interrupt handling.
Clock
-----
CONFIG_ARCH_BOARD_STM32_CUSTOM_CLOCKCONFIG - Enables special STM32 clock
configuration features.::
CONFIG_ARCH_BOARD_STM32_CUSTOM_CLOCKCONFIG=n
CONFIG_ARCH_LOOPSPERMSEC - Must be calibrated for correct operation
of delay loops
TIMER
-----
Timer devices may be used for different purposes. One special purpose is
to generate modulated outputs for such things as motor control. If CONFIG_STM32_TIMn
is defined (as above) then the following may also be defined to indicate that
the timer is intended to be used for pulsed output modulation, ADC conversion,
or DAC conversion. Note that ADC/DAC require two definition: Not only do you have
to assign the timer (n) for used by the ADC or DAC, but then you also have to
configure which ADC or DAC (m) it is assigned to.
CONFIG_STM32_TIMn_PWM Reserve timer n for use by PWM, n=1,..,14
CONFIG_STM32_TIMn_ADC Reserve timer n for use by ADC, n=1,..,14
CONFIG_STM32_TIMn_ADCm Reserve timer n to trigger ADCm, n=1,..,14, m=1,..,3
CONFIG_STM32_TIMn_DAC Reserve timer n for use by DAC, n=1,..,14
CONFIG_STM32_TIMn_DACm Reserve timer n to trigger DACm, n=1,..,14, m=1,..,2
For each timer that is enabled for PWM usage, we need the following additional
configuration settings:
CONFIG_STM32_TIMx_CHANNEL - Specifies the timer output channel {1,..,4}
NOTE: The STM32 timers are each capable of generating different signals on
each of the four channels with different duty cycles. That capability is
not supported by this driver: Only one output channel per timer.
JTAG
----
CONFIG_STM32_JTAG_FULL_ENABLE - Enables full SWJ (JTAG-DP + SW-DP)
CONFIG_STM32_JTAG_NOJNTRST_ENABLE - Enables full SWJ (JTAG-DP + SW-DP)
but without JNTRST.
CONFIG_STM32_JTAG_SW_ENABLE - Set JTAG-DP disabled and SW-DP enabled
USART
-----
CONFIG_U[S]ARTn_SERIAL_CONSOLE - selects the USARTn (n=1,2,3) or UART
m (m=4,5) for the console and ttys0 (default is the USART1).
CONFIG_U[S]ARTn_RXBUFSIZE - Characters are buffered as received.
This specific the size of the receive buffer
CONFIG_U[S]ARTn_TXBUFSIZE - Characters are buffered before
being sent. This specific the size of the transmit buffer
CONFIG_U[S]ARTn_BAUD - The configure BAUD of the UART. Must be
CONFIG_U[S]ARTn_BITS - The number of bits. Must be either 7 or 8.
CONFIG_U[S]ARTn_PARTIY - 0=no parity, 1=odd parity, 2=even parity
CONFIG_U[S]ARTn_2STOP - Two stop bits
CAN
---
CONFIG_CAN - Enables CAN support (one or both of CONFIG_STM32_CAN1 or
CONFIG_STM32_CAN2 must also be defined)
CONFIG_CAN_EXTID - Enables support for the 29-bit extended ID. Default
Standard 11-bit IDs.
CONFIG_CAN_FIFOSIZE - The size of the circular buffer of CAN messages.
Default: 8
CONFIG_CAN_NPENDINGRTR - The size of the list of pending RTR requests.
Default: 4
CONFIG_CAN_LOOPBACK - A CAN driver may or may not support a loopback
mode for testing. The STM32 CAN driver does support loopback mode.
CONFIG_STM32_CAN1_BAUD - CAN1 BAUD rate. Required if CONFIG_STM32_CAN1
is defined.
CONFIG_STM32_CAN2_BAUD - CAN1 BAUD rate. Required if CONFIG_STM32_CAN2
is defined.
CONFIG_STM32_CAN_TSEG1 - The number of CAN time quanta in segment 1.
Default: 6
CONFIG_STM32_CAN_TSEG2 - the number of CAN time quanta in segment 2.
Default: 7
CONFIG_STM32_CAN_REGDEBUG - If CONFIG_DEBUG_FEATURES is set, this will generate an
dump of all CAN registers.
SPI
---
CONFIG_STM32_SPI_INTERRUPTS - Select to enable interrupt driven SPI
support. Non-interrupt-driven, poll-waiting is recommended if the
interrupt rate would be to high in the interrupt driven case.
CONFIG_STM32_SPIx_DMA - Use DMA to improve SPIx transfer performance.
Cannot be used with CONFIG_STM32_SPI_INTERRUPT.
DMA
---
CONFIG_SDIO_DMA - Support DMA data transfers. Requires CONFIG_STM32_SDIO and CONFIG_STM32_DMA2.
CONFIG_STM32_SDIO_PRI - Select SDIO interrupt priority. Default: 128
CONFIG_STM32_SDIO_DMAPRIO - Select SDIO DMA interrupt priority. Default: Medium
CONFIG_STM32_SDIO_WIDTH_D1_ONLY - Select 1-bit transfer mode. Default:
4-bit transfer mode.
USB
---
STM32 USB OTG FS Host Driver Support
Pre-requisites::
CONFIG_USBDEV - Enable USB device support
CONFIG_USBHOST - Enable USB host support
CONFIG_STM32_OTGFS - Enable the STM32 USB OTG FS block
CONFIG_STM32_SYSCFG - Needed
CONFIG_SCHED_WORKQUEUE - Worker thread support is required
Options:
CONFIG_STM32_OTGFS_RXFIFO_SIZE - Size of the RX FIFO in 32-bit words.
Default 128 (512 bytes)
CONFIG_STM32_OTGFS_NPTXFIFO_SIZE - Size of the non-periodic Tx FIFO
in 32-bit words. Default 96 (384 bytes)
CONFIG_STM32_OTGFS_PTXFIFO_SIZE - Size of the periodic Tx FIFO in 32-bit
words. Default 96 (384 bytes)
CONFIG_STM32_OTGFS_DESCSIZE - Maximum size of a descriptor. Default: 128
CONFIG_STM32_OTGFS_SOFINTR - Enable SOF interrupts. Why would you ever
want to do that?
CONFIG_STM32_USBHOST_REGDEBUG - Enable very low-level register access
debug. Depends on CONFIG_DEBUG_FEATURES.
CONFIG_STM32_USBHOST_PKTDUMP - Dump all incoming and outgoing USB
packets. Depends on CONFIG_DEBUG_FEATURES.
LTDC hardware acceleration
--------------------------
The LTDC driver provides two 2 LTDC overlays and supports the following hardware
acceleration and features:
Configured at build time
- background color
- default color (outside visible screen)
Configurable by nuttx framebuffer interface
- cmap support (color table is shared by both LTDC overlays and DMA2D when enabled)
Configurable via the nuttx framebuffer interface (for each layer separately)
- chromakey
- transparency (const alpha and pixel alpha)
- blank
- color (if DMA2D is enabled and cmap is disabled)
- blit (if DMA2D is enabled)
- blend (if DMA2D is enabled and cmap is disabled)
LTDC overlays are similar to a non-destructive overlay. Both LTDC overlays will
be permanently blended in the order (background -> overlay 0 -> overlay 1) and
converted to a resulting video signal by the LTDC controller. That means each
operation with a LTDC overlay (Overlay 0 and Overlay 1) via nuttx framebuffer
interface will be visible immediately.
Think about continuous blending between both overlays.
DMA2D hardware acceleration
---------------------------
The DMA2D driver implements the following hardware acceleration:
Configurable via the nuttx framebuffer interface
- cmap support (color table is shared by all DMA2D overlays and LTDC overlays)
Configurable via the nuttx framebuffer interface (for each layer separately)
- color (fill memory region with a specific ARGB8888 color immediately), if
cmap is disabled
- blit (copy memory region to another memory region with pixel format
conversion if necessary)
- blend (blend two memory regions and copy the result to a third memory region
with pixel format conversion if necessary), if cmap is disabled
Blit and blend operation using a fixes memory size defined by the background
layer. DMA2D controller doesn't support scaling.
DMA2D overlays are similar to destructive overlays. They are invisible. They can
be used for image preprocessing. The memory region affected by the operations
(color, blit, blend) can be addressed by the area control command before. The
configured overlay transparency of DMA2D overlays will be used for subsequently
blend operation and is valid for the whole overlay.
FPU
===
FPU Configuration Options
-------------------------
There are two version of the FPU support built into the STM32 port.
1. Non-Lazy Floating Point Register Save
In this configuration floating point register save and restore is
implemented on interrupt entry and return, respectively. In this
case, you may use floating point operations for interrupt handling
logic if necessary. This FPU behavior logic is enabled by default
with::
CONFIG_ARCH_FPU=y
2. Lazy Floating Point Register Save.
An alternative implementation only saves and restores FPU registers only
on context switches. This means: (1) floating point registers are not
stored on each context switch and, hence, possibly better interrupt
performance. But, (2) since floating point registers are not saved,
you cannot use floating point operations within interrupt handlers.
This logic can be enabled by simply adding the following to your .config file::
CONFIG_ARCH_FPU=y
Development Environment
=======================
Either Linux or Cygwin on Windows can be used for the development environment.
The source has been built only using the GNU toolchain (see below). Other
toolchains will likely cause problems.
GNU Toolchain Options
=====================
Toolchain Configurations
------------------------
The NuttX make system has been modified to support the following different
toolchain options.
1. The NuttX buildroot Toolchain (see below), or
2. Any generic arm-none-eabi GNU toolchain.
All testing has been conducted using the NuttX Codesourcery toolchain. To use
a different toolchain, you simply need to modify the configuration. As an
example::
CONFIG_ARM_TOOLCHAIN_GNU_EABI : Generic arm-none-eabi toolchain
IDEs
====
NuttX is built using command-line make. It can be used with an IDE, but some
effort will be required to create the project.
Makefile Build
--------------
Under Eclipse, it is pretty easy to set up an "empty makefile project" and
simply use the NuttX makefile to build the system. That is almost for free
under Linux. Under Windows, you will need to set up the "Cygwin GCC" empty
makefile project in order to work with Windows (Google for "Eclipse Cygwin" -
there is a lot of help on the internet).
Using Sourcery CodeBench from http://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/overview
Download and install the latest version (as of this writing it was sourceryg++-2013.05-64-arm-none-eabi)
Import the project from git.
File->import->Git-URI, then import a Exiting code as a Makefile progject
from the working directory the git clone was done to.
Select the Sourcery CodeBench for ARM EABI. N.B. You must do one command line
build, before the make will work in CodeBench.
Native Build
------------
Here are a few tips before you start that effort:
1) Select the toolchain that you will be using in your .config file
2) Start the NuttX build at least one time from the Cygwin command line
before trying to create your project. This is necessary to create
certain auto-generated files and directories that will be needed.
3) Set up include paths: You will need include/, arch/arm/src/stm32,
arch/arm/src/common, arch/arm/src/armv7-m, and sched/.
4) All assembly files need to have the definition option -D __ASSEMBLY__
on the command line.
Startup files will probably cause you some headaches. The NuttX startup file
is arch/arm/src/stm32/stm32_vectors.S. With RIDE, I have to build NuttX
one time from the Cygwin command line in order to obtain the pre-built
startup object needed by RIDE.
NuttX EABI "buildroot" Toolchain
================================
A GNU GCC-based toolchain is assumed. The PATH environment variable should
be modified to point to the correct path to the Cortex-M3 GCC toolchain (if
different from the default in your PATH variable).
If you have no Cortex-M3 toolchain, one can be downloaded from the NuttX
Bitbucket download site (https://bitbucket.org/nuttx/buildroot/downloads/).
This GNU toolchain builds and executes in the Linux or Cygwin environment.
NXFLAT Toolchain
================
If you are *not* using the NuttX buildroot toolchain and you want to use
the NXFLAT tools, then you will still have to build a portion of the buildroot
tools -- just the NXFLAT tools. The buildroot with the NXFLAT tools can
be downloaded from the NuttX Bitbucket download site
(https://bitbucket.org/nuttx/nuttx/downloads/).
This GNU toolchain builds and executes in the Linux or Cygwin environment.
1. You must have already configured NuttX in <some-dir>/nuttx.
tools/configure.sh lpcxpresso-lpc1768:<sub-dir>
2. Download the latest buildroot package into <some-dir>
3. unpack the buildroot tarball. The resulting directory may
have versioning information on it like buildroot-x.y.z. If so,
rename <some-dir>/buildroot-x.y.z to <some-dir>/buildroot.
4. cd <some-dir>/buildroot
5. cp boards/cortexm3-defconfig-nxflat .config
6. make oldconfig
7. make
8. Make sure that the PATH variable includes the path to the newly built
NXFLAT binaries.
Protected Mode Build
====================
The "protected" mode build uses the Cormtex-M4 MPU to separate the FLASH and
SRAM into kernel-mode and user-mode regions. The kernel mode regions are
then protected from any errant or mischievous behavior from user-space
applications.
Common notes for all protected mode builds follow:
1. It is recommends to use a special make command; not just 'make' but make
with the following two arguments::
make pass1 pass2
In the normal case (just 'make'), make will attempt to build both user-
and kernel-mode blobs more or less interleaved. That actual works!
However, for me it is very confusing so I prefer the above make command:
Make the user-space binaries first (pass1), then make the kernel-space
binaries (pass2)
2. At the end of the build, there will be several files in the top-level
NuttX build directory::
PASS1:
nuttx_user.elf - The pass1 user-space ELF file
nuttx_user.hex - The pass1 Intel HEX format file (selected in defconfig)
User.map - Symbols in the user-space ELF file
PASS2:
nuttx - The pass2 kernel-space ELF file
nuttx.hex - The pass2 Intel HEX file (selected in defconfig)
System.map - Symbols in the kernel-space ELF file
The J-Link programmer will except files in .hex, .mot, .srec, and .bin
formats.
3. Combining .hex files. If you plan to use the .hex files with your
debugger or FLASH utility, then you may need to combine the two hex
files into a single .hex file. Here is how you can do that.
a. The 'tail' of the nuttx.hex file should look something like this
(with my comments added)::
$ tail nuttx.hex
# 00, data records
...
:10 9DC0 00 01000000000800006400020100001F0004
:10 9DD0 00 3B005A0078009700B500D400F300110151
:08 9DE0 00 30014E016D0100008D
# 05, Start Linear Address Record
:04 0000 05 0800 0419 D2
# 01, End Of File record
:00 0000 01 FF
Use an editor such as vi to remove the 05 and 01 records.
b. The 'head' of the nuttx_user.hex file should look something like
this (again with my comments added)::
$ head nuttx_user.hex
# 04, Extended Linear Address Record
:02 0000 04 0801 F1
# 00, data records
:10 8000 00 BD89 01084C800108C8110208D01102087E
:10 8010 00 0010 00201C1000201C1000203C16002026
:10 8020 00 4D80 01085D80010869800108ED83010829
...
Nothing needs to be done here. The nuttx_user.hex file should
be fine.
c. Combine the edited nuttx.hex and un-edited nuttx_user.hex
file to produce a single combined hex file::
$ cat nuttx.hex nuttx_user.hex >combined.hex
Then use the combined.hex file with the to write the FLASH image. With
GDB this would be::
gdb> mon reset
gdb> mon halt
gdb> mon clrbp
gdb> load combined.hex
If you do this a lot, you will probably want to invest a little time
to develop a tool to automate these steps.
Supported Boards
================
.. toctree::
:glob:
:maxdepth: 1
boards/*/*

6
Documentation/platforms/arm/stm32wl5/index.rst
View File

@ -1,6 +1,6 @@
========
STM32WL5
========
===========
ST STM32WL5
===========
The STM32WL5 is a dual CPU (not core!) chip based on ARM Cortex-M4 and
Cortex-M0 with integrated sub-GHz radio for LoRa (G)FSK, (G)MSK and BPSK

659
boards/arm/stm32/mikroe-stm32f4/README.txt
View File

@ -1,659 +0,0 @@
README
======
This README discusses issues unique to NuttX configurations for the
MikroElektronika Mikromedia for STM32F4 development board. This is
another board support by NuttX that uses the same STM32F407VGT6 MCU
as does the STM32F4-Discovery board. This board, however, has very
different on-board peripherals than does the STM32F4-Discovery:
- TFT display with touch panel,
- VS1053 stereo audio codec with headphone jack,
- SD card slot,
- Serial FLASH memory,
- USB OTG FS with micro-AB connector, and
- Battery connect and batter charger circuit.
See the http://www.mikroe.com/mikromedia/stm32-m4/ for more information
about this board.
Contents
========
- LEDs
- PWM
- UARTs
- Timer Inputs/Outputs
- FPU
- FSMC SRAM
- SSD1289
- Mikroe-STM32F4-specific Configuration Options
- Configurations
LEDs
====
The Mikroe-STM32F4 board has no user accessible LEDs onboard, only a power
and "charging" LED. All visual user output must be performed through the TFT
display.
External LEDs could be added via the expansion headers on the side of the
board, but as this would be a custom configuration, LEDs are not supported
in this port.
PWM
===
The Mikroe-STM32F4 has no real on-board PWM devices, but it does have PWM
pins routed to the expansion I/O headers on the side of the board.
UARTs
=====
The Mikroe-STM32F4 board has no onboard RS-232 line driver, however the
expansion I/O header provides access to USART2 on pins PD5/PD6. The port
includes support for USART2 configured as /dev/ttyS0.
UART/USART PINS
---------------
USART2
RX PD6
TX PD5
Default USART/UART Configuration
--------------------------------
USART2 is enabled in all configurations (see */defconfig). RX and TX are
configured on pins PD6 and PD5, respectively (see include/board.h).
Timer Inputs/Outputs
====================
TIM1
CH1 PA8, PE9
CH2 PA9*, PE11
CH3 PA10*, PE13
CH4 PA11*, PE14
TIM2
CH1 PA0*, PA15, PA5*
CH2 PA1, PB3*
CH3 PA2, PB10*
CH4 PA3, PB11
TIM3
CH1 PA6*, PB4, PC6
CH2 PA7*, PB5, PC7*
CH3 PB0, PC8
CH4 PB1, PC9
TIM4
CH1 PB6*, PD12*
CH2 PB7, PD13*
CH3 PB8, PD14*
CH4 PB9*, PD15*
TIM5
CH1 PA0*, PH10**
CH2 PA1, PH11**
CH3 PA2, PH12**
CH4 PA3, PI0
TIM8
CH1 PC6, PI5
CH2 PC7*, PI6
CH3 PC8, PI7
CH4 PC9, PI2
TIM9
CH1 PA2, PE5
CH2 PA3, PE6
TIM10
CH1 PB8, PF6
TIM11
CH1 PB9*, PF7
TIM12
CH1 PH6**, PB14
CH2 PC15, PH9**
TIM13
CH1 PA6*, PF8
TIM14
CH1 PA7*, PF9
* Indicates pins that have other on-board functions and should be used only
with care (See table 5 in the Mikroe-STM32F4 User Guide). The rest are
free I/O pins.
** Port H pins are not supported by the MCU
FPU
===
FPU Configuration Options
-------------------------
There are two version of the FPU support built into the STM32 port.
1. Non-Lazy Floating Point Register Save
In this configuration floating point register save and restore is
implemented on interrupt entry and return, respectively. In this
case, you may use floating point operations for interrupt handling
logic if necessary. This FPU behavior logic is enabled by default
with:
CONFIG_ARCH_FPU=y
2. Lazy Floating Point Register Save.
An alternative implementation only saves and restores FPU registers only
on context switches. This means: (1) floating point registers are not
stored on each context switch and, hence, possibly better interrupt
performance. But, (2) since floating point registers are not saved,
you cannot use floating point operations within interrupt handlers.
This logic can be enabled by simply adding the following to your .config
file:
CONFIG_ARCH_FPU=y
MIO283QT-2/MIO283QT-9A
======================
The original Mikroe-SMT32F4 board as an on-board MIO283QT-2 TFT LCD that can
be configured and used. This is a 320x240 resolution display with color
capability to 262K colors, though the mio283qt-2 driver in NuttX only
supports 16-bit color depth, or 65K colors. Changes to both the
mio283qt-2 driver and the driver interface layer would need to be made
to support 24 BPP mode.
UPDATE: New boards now support a MIO283QT-9A TFT LCD that is not compatible
with the MIO283QT-2. It uses a different LCD controller. The default in
all of these configurations is the MIO283QT-2. But MIO283QT-9A is also
supported and you can switch from the MIO283QT-2 to the MIO283QT-9A by simply
modifying the NuttX configuration
Mikroe-STM32F4-specific Configuration Options
===============================================
CONFIG_ARCH - Identifies the arch/ subdirectory. This should
be set to:
CONFIG_ARCH=arm
CONFIG_ARCH_family - For use in C code:
CONFIG_ARCH_ARM=y
CONFIG_ARCH_architecture - For use in C code:
CONFIG_ARCH_CORTEXM4=y
CONFIG_ARCH_CHIP - Identifies the arch/*/chip subdirectory
CONFIG_ARCH_CHIP=stm32
CONFIG_ARCH_CHIP_name - For use in C code to identify the exact
chip:
CONFIG_ARCH_CHIP_STM32F407VG=y
CONFIG_ARCH_BOARD_STM32_CUSTOM_CLOCKCONFIG - Enables special STM32 clock
configuration features.
CONFIG_ARCH_BOARD_STM32_CUSTOM_CLOCKCONFIG=n
CONFIG_ARCH_BOARD - Identifies the boards/ subdirectory and
hence, the board that supports the particular chip or SoC.
CONFIG_ARCH_BOARD=Mikroe-STM32F4 (for the Mikroe-STM32F4 development board)
CONFIG_ARCH_BOARD_name - For use in C code
CONFIG_ARCH_BOARD_STM32F4_DISCOVERY=y
CONFIG_ARCH_LOOPSPERMSEC - Must be calibrated for correct operation
of delay loops
CONFIG_ENDIAN_BIG - define if big endian (default is little
endian)
CONFIG_RAM_SIZE - Describes the installed DRAM (SRAM in this case):
CONFIG_RAM_SIZE=0x00010000 (64Kb)
CONFIG_RAM_START - The start address of installed DRAM
CONFIG_RAM_START=0x20000000
CONFIG_STM32_CCMEXCLUDE - Exclude CCM SRAM from the HEAP
In addition to internal SRAM, SRAM may also be available through the FSMC.
In order to use FSMC SRAM, the following additional things need to be
present in the NuttX configuration file:
CONFIG_HEAP2_BASE - The base address of the SRAM in the FSMC address space (hex)
CONFIG_HEAP2_SIZE - The size of the SRAM in the FSMC address space (decimal)
CONFIG_ARCH_FPU - The Mikroe-STM32F4 supports a floating point unit (FPU)
CONFIG_ARCH_FPU=y
CONFIG_ARCH_INTERRUPTSTACK - This architecture supports an interrupt
stack. If defined, this symbol is the size of the interrupt
stack in bytes. If not defined, the user task stacks will be
used during interrupt handling.
CONFIG_ARCH_STACKDUMP - Do stack dumps after assertions
CONFIG_ARCH_LEDS - Use LEDs to show state. Unique to board architecture.
Individual subsystems can be enabled:
AHB1
----
CONFIG_STM32_CRC
CONFIG_STM32_BKPSRAM
CONFIG_STM32_CCMDATARAM
CONFIG_STM32_DMA1
CONFIG_STM32_DMA2
CONFIG_STM32_ETHMAC
CONFIG_STM32_OTGHS
AHB2
----
CONFIG_STM32_DCMI
CONFIG_STM32_CRYP
CONFIG_STM32_HASH
CONFIG_STM32_RNG
CONFIG_STM32_OTGFS
AHB3
----
CONFIG_STM32_FSMC
APB1
----
CONFIG_STM32_TIM2
CONFIG_STM32_TIM3
CONFIG_STM32_TIM4
CONFIG_STM32_TIM5
CONFIG_STM32_TIM6
CONFIG_STM32_TIM7
CONFIG_STM32_TIM12
CONFIG_STM32_TIM13
CONFIG_STM32_TIM14
CONFIG_STM32_WWDG
CONFIG_STM32_IWDG
CONFIG_STM32_SPI2
CONFIG_STM32_SPI3
CONFIG_STM32_USART2
CONFIG_STM32_USART3
CONFIG_STM32_UART4
CONFIG_STM32_UART5
CONFIG_STM32_I2C1
CONFIG_STM32_I2C2
CONFIG_STM32_I2C3
CONFIG_STM32_CAN1
CONFIG_STM32_CAN2
CONFIG_STM32_DAC1
CONFIG_STM32_DAC2
CONFIG_STM32_PWR -- Required for RTC
APB2
----
CONFIG_STM32_TIM1
CONFIG_STM32_TIM8
CONFIG_STM32_USART1
CONFIG_STM32_USART6
CONFIG_STM32_ADC1
CONFIG_STM32_ADC2
CONFIG_STM32_ADC3
CONFIG_STM32_SDIO
CONFIG_STM32_SPI1
CONFIG_STM32_SYSCFG
CONFIG_STM32_TIM9
CONFIG_STM32_TIM10
CONFIG_STM32_TIM11
Timer devices may be used for different purposes. One special purpose is
to generate modulated outputs for such things as motor control. If CONFIG_STM32_TIMn
is defined (as above) then the following may also be defined to indicate that
the timer is intended to be used for pulsed output modulation, ADC conversion,
or DAC conversion. Note that ADC/DAC require two definition: Not only do you have
to assign the timer (n) for used by the ADC or DAC, but then you also have to
configure which ADC or DAC (m) it is assigned to.
CONFIG_STM32_TIMn_PWM Reserve timer n for use by PWM, n=1,..,14
CONFIG_STM32_TIMn_ADC Reserve timer n for use by ADC, n=1,..,14
CONFIG_STM32_TIMn_ADCm Reserve timer n to trigger ADCm, n=1,..,14, m=1,..,3
CONFIG_STM32_TIMn_DAC Reserve timer n for use by DAC, n=1,..,14
CONFIG_STM32_TIMn_DACm Reserve timer n to trigger DACm, n=1,..,14, m=1,..,2
For each timer that is enabled for PWM usage, we need the following additional
configuration settings:
CONFIG_STM32_TIMx_CHANNEL - Specifies the timer output channel {1,..,4}
NOTE: The STM32 timers are each capable of generating different signals on
each of the four channels with different duty cycles. That capability is
not supported by this driver: Only one output channel per timer.
JTAG Enable settings (by default only SW-DP is enabled):
CONFIG_STM32_JTAG_FULL_ENABLE - Enables full SWJ (JTAG-DP + SW-DP)
CONFIG_STM32_JTAG_NOJNTRST_ENABLE - Enables full SWJ (JTAG-DP + SW-DP)
but without JNTRST.
CONFIG_STM32_JTAG_SW_ENABLE - Set JTAG-DP disabled and SW-DP enabled
Mikroe-STM32F4 specific device driver settings
CONFIG_U[S]ARTn_SERIAL_CONSOLE - selects the USARTn (n=1,2,3) or UART
m (m=4,5) for the console and ttys0 (default is the USART1).
CONFIG_U[S]ARTn_RXBUFSIZE - Characters are buffered as received.
This specific the size of the receive buffer
CONFIG_U[S]ARTn_TXBUFSIZE - Characters are buffered before
being sent. This specific the size of the transmit buffer
CONFIG_U[S]ARTn_BAUD - The configure BAUD of the UART. Must be
CONFIG_U[S]ARTn_BITS - The number of bits. Must be either 7 or 8.
CONFIG_U[S]ARTn_PARTIY - 0=no parity, 1=odd parity, 2=even parity
CONFIG_U[S]ARTn_2STOP - Two stop bits
Mikroe-STM32F4 CAN Configuration
CONFIG_CAN - Enables CAN support (one or both of CONFIG_STM32_CAN1 or
CONFIG_STM32_CAN2 must also be defined)
CONFIG_CAN_EXTID - Enables support for the 29-bit extended ID. Default
Standard 11-bit IDs.
CONFIG_CAN_FIFOSIZE - The size of the circular buffer of CAN messages.
Default: 8
CONFIG_CAN_NPENDINGRTR - The size of the list of pending RTR requests.
Default: 4
CONFIG_CAN_LOOPBACK - A CAN driver may or may not support a loopback
mode for testing. The STM32 CAN driver does support loopback mode.
CONFIG_STM32_CAN1_BAUD - CAN1 BAUD rate. Required if CONFIG_STM32_CAN1
is defined.
CONFIG_STM32_CAN2_BAUD - CAN1 BAUD rate. Required if CONFIG_STM32_CAN2
is defined.
CONFIG_STM32_CAN_TSEG1 - The number of CAN time quanta in segment 1.
Default: 6
CONFIG_STM32_CAN_TSEG2 - the number of CAN time quanta in segment 2.
Default: 7
CONFIG_STM32_CAN_REGDEBUG - If CONFIG_DEBUG_FEATURES is set, this will generate an
dump of all CAN registers.
Mikroe-STM32F4 SPI Configuration
CONFIG_STM32_SPI_INTERRUPTS - Select to enable interrupt driven SPI
support. Non-interrupt-driven, poll-waiting is recommended if the
interrupt rate would be to high in the interrupt driven case.
CONFIG_STM32_SPIx_DMA - Use DMA to improve SPIx transfer performance.
Cannot be used with CONFIG_STM32_SPI_INTERRUPT.
Mikroe-STM32F4 DMA Configuration
CONFIG_SDIO_DMA - Support DMA data transfers. Requires CONFIG_STM32_SDIO
and CONFIG_STM32_DMA2.
CONFIG_STM32_SDIO_PRI - Select SDIO interrupt priority. Default: 128
CONFIG_STM32_SDIO_DMAPRIO - Select SDIO DMA interrupt priority.
Default: Medium
CONFIG_STM32_SDIO_WIDTH_D1_ONLY - Select 1-bit transfer mode. Default:
4-bit transfer mode.
STM32 USB OTG FS Host Driver Support
Pre-requisites
CONFIG_USBDEV - Enable USB device support
CONFIG_USBHOST - Enable USB host support
CONFIG_STM32_OTGFS - Enable the STM32 USB OTG FS block
CONFIG_STM32_SYSCFG - Needed
CONFIG_SCHED_WORKQUEUE - Worker thread support is required
Options:
CONFIG_STM32_OTGFS_RXFIFO_SIZE - Size of the RX FIFO in 32-bit words.
Default 128 (512 bytes)
CONFIG_STM32_OTGFS_NPTXFIFO_SIZE - Size of the non-periodic Tx FIFO
in 32-bit words. Default 96 (384 bytes)
CONFIG_STM32_OTGFS_PTXFIFO_SIZE - Size of the periodic Tx FIFO in 32-bit
words. Default 96 (384 bytes)
CONFIG_STM32_OTGFS_DESCSIZE - Maximum size of a descriptor. Default: 128
CONFIG_STM32_OTGFS_SOFINTR - Enable SOF interrupts. Why would you ever
want to do that?
CONFIG_STM32_USBHOST_REGDEBUG - Enable very low-level register access
debug. Depends on CONFIG_DEBUG_FEATURES.
CONFIG_STM32_USBHOST_PKTDUMP - Dump all incoming and outgoing USB
packets. Depends on CONFIG_DEBUG_FEATURES.
Configurations
==============
Each Mikroe-STM32F4 configuration is maintained in a sub-directory and
can be selected as follow:
tools/configure.sh mikroe-stm32f4:<subdir>
If this is a Windows native build, then configure.bat should be used
instead of configure.sh:
configure.bat Mikroe-STM32F4\<subdir>
Where <subdir> is one of the following:
fulldemo
--------
This is an example that includes an NSH shell over USB that also
enables all features of the Mikroe-STM32F4 board including the LCD,
on-board 1M Flash with SMART filesystem, Aux RS-232 serial port on the
expansion header, etc. A couple of the NX graphics commands are made
available via the NSH prompt for performing LCD demonstrations, and the
nximage example is used as a splash-screen at startup.
kostest:
-------
NOTE: This configuration compiles, but has not been fully tested
on the hardware yet.
This configuration directory, performs a simple OS test using
apps/examples/ostest with NuttX build as a kernel-mode monolithic
module and the user applications are built separately. Is
is recommended to use a special make command; not just 'make' but
make with the following two arguments:
make pass1 pass2
In the normal case (just 'make'), make will attempt to build both user-
and kernel-mode blobs more or less interleaved. This actual works!
However, for me it is very confusing so I prefer the above make command:
Make the user-space binaries first (pass1), then make the kernel-space
binaries (pass2)
NOTES:
1. This configuration uses the mconf-based configuration tool. To
change this configuration using that tool, you should:
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
see additional README.txt files in the NuttX tools repository.
b. Execute 'make menuconfig' in nuttx/ in order to start the
reconfiguration process.
2. This is the default platform/toolchain in the configuration:
CONFIG_HOST_WINDOWS=y : Windows
CONFIG_WINDOWS_CYGWIN=y : Cygwin environment on Windows
CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : GNU EABI toolchain for Windows
This is easily changed by modifying the configuration.
3. At the end of the build, there will be several files in the top-level
NuttX build directory:
PASS1:
nuttx_user.elf - The pass1 user-space ELF file
nuttx_user.hex - The pass1 Intel HEX format file (selected in defconfig)
User.map - Symbols in the user-space ELF file
PASS2:
nuttx - The pass2 kernel-space ELF file
nuttx.hex - The pass2 Intel HEX file (selected in defconfig)
System.map - Symbols in the kernel-space ELF file
4. Combining .hex files. If you plan to use the STM32 ST-Link Utility to
load the .hex files into FLASH, then you need to combine the two hex
files into a single .hex file. Here is how you can do that.
a. The 'tail' of the nuttx.hex file should look something like this
(with my comments added):
$ tail nuttx.hex
# 00, data records
...
:10 9DC0 00 01000000000800006400020100001F0004
:10 9DD0 00 3B005A0078009700B500D400F300110151
:08 9DE0 00 30014E016D0100008D
# 05, Start Linear Address Record
:04 0000 05 0800 0419 D2
# 01, End Of File record
:00 0000 01 FF
Use an editor such as vi to remove the 05 and 01 records.
b. The 'head' of the nuttx_user.hex file should look something like
this (again with my comments added):
$ head nuttx_user.hex
# 04, Extended Linear Address Record
:02 0000 04 0801 F1
# 00, data records
:10 8000 00 BD89 01084C800108C8110208D01102087E
:10 8010 00 0010 00201C1000201C1000203C16002026
:10 8020 00 4D80 01085D80010869800108ED83010829
...
Nothing needs to be done here. The nuttx_user.hex file should
be fine.
c. Combine the edited nuttx.hex and un-edited nuttx_user.hex
file to produce a single combined hex file:
$ cat nuttx.hex nuttx_user.hex >combined.hex
Then use the combined.hex file with the STM32 ST-Link tool. If
you do this a lot, you will probably want to invest a little time
to develop a tool to automate these steps.
nsh
---
This is an NSH example that uses USART2 as the console. Note that
the Mikroe-STM32F4 board doesn't actually have onboard line drivers
or a connector for USART2, but it does route the USART2 signals to
the expansion header. To use this demo, you would need to connect
an external 3.3V RS-232 line driver to the USART's I/O lines on the
expansion header.
NOTE: This demo doesn't quite work yet. I can get output to the
USART, but so far, I have not gotten nsh to actually come up.
nx
--
An example using the NuttX graphics system (NX). This example
focuses on general window controls, movement, mouse and keyboard
input.
CONFIG_LCD_LANDSCAPE=y : 320x240 landscape orientation
CONFIG_LCD_MIO283QT2=y : MIO283QT-2 is the default
You can the newer MIO283QT-9A by enabling it in the configuration.
CONFIG_LCD_MIO283QT2=n : Disable the MIO283QT-2
CONFIG_LCD_MIO283QT9A=y : Enable the MIO283QT-9A
nxlines:
------
An example using the NuttX graphics system (NX). This example focuses on
placing lines on the background in various orientations using the
on-board TFT LCD.
CONFIG_LCD_LANDSCAPE=y : 320x240 landscape orientation
CONFIG_LCD_MIO283QT2=y : MIO283QT-2 is the default
You can the newer MIO283QT-9A by enabling it in the configuration.
CONFIG_LCD_MIO283QT2=n : Disable the MIO283QT-2
CONFIG_LCD_MIO283QT9A=y : Enable the MIO283QT-9A
nxtext:
------
Another example using the NuttX graphics system (NX). This
example focuses on placing text on the background while pop-up
windows occur. Text should continue to update normally with
or without the popup windows present.
usbnsh:
-------
This is another NSH example. If differs from other 'nsh' configurations
in that this configurations uses a USB serial device for console I/O.
Such a configuration is useful on the stm32f4discovery which has no
builtin RS-232 drivers.
NOTES:
1. This configuration uses the mconf-based configuration tool. To
change this configuration using that tool, you should:
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
see additional README.txt files in the NuttX tools repository.
b. Execute 'make menuconfig' in nuttx/ in order to start the
reconfiguration process.
2. By default, this configuration uses the ARM EABI toolchain
for Windows and builds under Cygwin (or probably MSYS). That
can easily be reconfigured, of course.
CONFIG_HOST_WINDOWS=y : Builds under Windows
CONFIG_WINDOWS_CYGWIN=y : Using Cygwin
CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : GNU EABI toolchain for Windows
3. This configuration does have UART2 output enabled and set up as
the system logging device:
CONFIG_SYSLOG_CHAR=y : Use a character device for system logging
CONFIG_SYSLOG_DEVPATH="/dev/ttyS0" : UART2 will be /dev/ttyS0
However, there is nothing to generate SYSLOG output in the default
configuration so nothing should appear on UART2 unless you enable
some debug output or enable the USB monitor.
4. Enabling USB monitor SYSLOG output. If tracing is enabled, the USB
device will save encoded trace output in in-memory buffer; if the
USB monitor is enabled, that trace buffer will be periodically
emptied and dumped to the system logging device (UART2 in this
configuration):
CONFIG_USBDEV_TRACE=y : Enable USB trace feature
CONFIG_USBDEV_TRACE_NRECORDS=128 : Buffer 128 records in memory
CONFIG_NSH_USBDEV_TRACE=n : No builtin tracing from NSH
CONFIG_NSH_ARCHINIT=y : Automatically start the USB monitor
CONFIG_USBMONITOR=y : Enable the USB monitor daemon
CONFIG_USBMONITOR_STACKSIZE=2048 : USB monitor daemon stack size
CONFIG_USBMONITOR_PRIORITY=50 : USB monitor daemon priority
CONFIG_USBMONITOR_INTERVAL=2 : Dump trace data every 2 seconds
CONFIG_USBMONITOR_TRACEINIT=y : Enable TRACE output
CONFIG_USBMONITOR_TRACECLASS=y
CONFIG_USBMONITOR_TRACETRANSFERS=y
CONFIG_USBMONITOR_TRACECONTROLLER=y
CONFIG_USBMONITOR_TRACEINTERRUPTS=y
5. By default, this project assumes that you are *NOT* using the DFU
bootloader.
Using the Prolifics PL2303 Emulation
------------------------------------
You could also use the non-standard PL2303 serial device instead of
the standard CDC/ACM serial device by changing:
CONFIG_CDCACM=y : Disable the CDC/ACM serial device class
CONFIG_CDCACM_CONSOLE=y : The CDC/ACM serial device is NOT the console
CONFIG_PL2303=y : The Prolifics PL2303 emulation is enabled
CONFIG_PL2303_CONSOLE=y : The PL2303 serial device is the console

250
boards/arm/stm32/nucleo-f410rb/README.txt
View File

@ -1,250 +0,0 @@
README
======
This README discusses issues unique to NuttX configurations for the ST
NucleoF410RB board from ST Micro. See
http://www.st.com/en/evaluation-tools/nucleo-f410rb.html
NucleoF410RB:
Microprocessor: 32-bit ARM Cortex M4 at 100MHz STM32F410RB
Memory: 128 KB Flash and 32 KB SRAM
ADC: 1x12-bit, 2.4 MSPS A/D converter: up to 16 channels
DAC: 1x12-bit, 2.4 MSPS A/D converter: up to 1 channels
DMA: 16-stream DMA controllers with FIFOs and burst support
Timers: Up to 11 timers: up to 5 16-bit, 1 32-bit timers, two
watchdog timers, and a SysTick timer
GPIO: Up to 81 I/O ports with interrupt capability
I2C: Up to 3 I2C interfaces
USARTs: Up to 3 USARTs
SPIs: Up to 4 SPIs (2 I2S)
CRC calculation unit
RTC
Peripherals: 1 led, 1 push button
Debug: Serial wire debug and JTAG interfaces
Expansion I/F Ardino and Morpho Headers
Uses a STM32F103 to provide a ST-Link for programming, debug similar to the
OpenOcd FTDI function - USB to JTAG front-end.
See https://os.mbed.com/platforms/ST-Nucleo-F410RB for more
information about this board.
Contents
========
- Nucleo-64 Boards
- Button
- LED
- USARTs and Serial Consoles
- Configurations
Nucleo-64 Boards
================
The Nucleo-F410RB board is member of the Nucleo-64 board family. The
Nucleo-64 is a standard board for use with several STM32 parts in the
LQFP64 package. Variants include
Order code Targeted STM32
------------- --------------
NUCLEO-F030R8 STM32F030R8T6
NUCLEO-F070RB STM32F070RBT6
NUCLEO-F072RB STM32F072RBT6
NUCLEO-F091RC STM32F091RCT6
NUCLEO-F103RB STM32F103RBT6
NUCLEO-F302R8 STM32F302R8T6
NUCLEO-F303RE STM32F303RET6
NUCLEO-F334R8 STM32F334R8T6
NUCLEO-F401RE STM32F401RET6
NUCLEO-F410RB STM32F410RBT6
NUCLEO-F411RE STM32F411RET6
NUCLEO-F446RE STM32F446RET6
NUCLEO-L053R8 STM32L053R8T6
NUCLEO-L073RZ STM32L073RZT6
NUCLEO-L152RE STM32L152RET6
NUCLEO-L452RE STM32L452RET6
NUCLEO-L476RG STM32L476RGT6
Hardware
========
Buttons
-------
B1 USER: the user button is connected to the I/O PC13 (pin 2) of the STM32
microcontroller.
LEDs
----
The Nucleo F410RB provide a single user LED, LD2. LD2
is the green LED connected to Arduino signal D13 corresponding to MCU I/O
PA5 (pin 21) or PB13 (pin 34) depending on the STM32target.
- When the I/O is HIGH value, the LED is on.
- When the I/O is LOW, the LED is off.
These LEDs are not used by the board port unless CONFIG_ARCH_LEDS is
defined. In that case, the usage by the board port is defined in
include/board.h and src/sam_leds.c. The LEDs are used to encode OS-related
events as follows when the red LED (PE24) is available:
SYMBOL Meaning LD2
------------------- ----------------------- -----------
LED_STARTED NuttX has been started OFF
LED_HEAPALLOCATE Heap has been allocated OFF
LED_IRQSENABLED Interrupts enabled OFF
LED_STACKCREATED Idle stack created ON
LED_INIRQ In an interrupt No change
LED_SIGNAL In a signal handler No change
LED_ASSERTION An assertion failed No change
LED_PANIC The system has crashed Blinking
LED_IDLE MCU is is sleep mode Not used
Thus if LD2, NuttX has successfully booted and is, apparently, running
normally. If LD2 is flashing at approximately 2Hz, then a fatal error
has been detected and the system has halted.
Serial Consoles
===============
USART1
------
Pins and Connectors:
RXD: PA11 CN10 pin 14
PB7 CN7 pin 21
TXD: PA10 CN9 pin 3, CN10 pin 33
PB6 CN5 pin 3, CN10 pin 17
NOTE: You may need to edit the include/board.h to select different USART1
pin selections.
TTL to RS-232 converter connection:
Nucleo CN10 STM32F410RB
----------- ------------
Pin 21 PA9 USART1_RX *Warning you make need to reverse RX/TX on
Pin 33 PA10 USART1_TX some RS-232 converters
Pin 20 GND
Pin 8 U5V
To configure USART1 as the console:
CONFIG_STM32_USART1=y
CONFIG_USART1_SERIALDRIVER=y
CONFIG_USART1_SERIAL_CONSOLE=y
CONFIG_USART1_RXBUFSIZE=256
CONFIG_USART1_TXBUFSIZE=256
CONFIG_USART1_BAUD=115200
CONFIG_USART1_BITS=8
CONFIG_USART1_PARITY=0
CONFIG_USART1_2STOP=0
USART2
-----
Pins and Connectors:
RXD: PA3 CN9 pin 1 (See SB13, 14, 62, 63). CN10 pin 37
PD6
TXD: PA2 CN9 pin 2(See SB13, 14, 62, 63). CN10 pin 35
PD5
UART2 is the default in all of these configurations.
TTL to RS-232 converter connection:
Nucleo CN9 STM32F410RB
----------- ------------
Pin 1 PA3 USART2_RX *Warning you make need to reverse RX/TX on
Pin 2 PA2 USART2_TX some RS-232 converters
Solder Bridges. This configuration requires:
- SB62 and SB63 Closed: PA2 and PA3 on STM32 MCU are connected to D1 and D0
(pin 7 and pin 8) on Arduino connector CN9 and ST Morpho connector CN10
as USART signals. Thus SB13 and SB14 should be OFF.
- SB13 and SB14 Open: PA2 and PA3 on STM32F103C8T6 (ST-LINK MCU) are
disconnected to PA3 and PA2 on STM32 MCU.
To configure USART2 as the console:
CONFIG_STM32_USART2=y
CONFIG_USART2_SERIALDRIVER=y
CONFIG_USART2_SERIAL_CONSOLE=y
CONFIG_USART2_RXBUFSIZE=256
CONFIG_USART2_TXBUFSIZE=256
CONFIG_USART2_BAUD=115200
CONFIG_USART2_BITS=8
CONFIG_USART2_PARITY=0
CONFIG_USART2_2STOP=0
USART6
------
Pins and Connectors:
RXD: PC7 CN5 pin2, CN10 pin 19
PA12 CN10, pin 12
TXD: PC6 CN10, pin 4
PA11 CN10, pin 14
To configure USART6 as the console:
CONFIG_STM32_USART6=y
CONFIG_USART6_SERIALDRIVER=y
CONFIG_USART6_SERIAL_CONSOLE=y
CONFIG_USART6_RXBUFSIZE=256
CONFIG_USART6_TXBUFSIZE=256
CONFIG_USART6_BAUD=115200
CONFIG_USART6_BITS=8
CONFIG_USART6_PARITY=0
CONFIG_USART6_2STOP=0
Virtual COM Port
----------------
Yet another option is to use UART2 and the USB virtual COM port. This
option may be more convenient for long term development, but is painful
to use during board bring-up.
Solder Bridges. This configuration requires:
- SB62 and SB63 Open: PA2 and PA3 on STM32 MCU are disconnected to D1
and D0 (pin 7 and pin 8) on Arduino connector CN9 and ST Morpho
connector CN10.
- SB13 and SB14 Closed: PA2 and PA3 on STM32F103C8T6 (ST-LINK MCU) are
connected to PA3 and PA2 on STM32 MCU to have USART communication
between them. Thus SB61, SB62 and SB63 should be OFF.
Configuring USART2 is the same as given above.
Question: What BAUD should be configure to interface with the Virtual
COM port? 115200 8N1?
Default
-------
As shipped, SB62 and SB63 are open and SB13 and SB14 closed, so the
virtual COM port is enabled.
Configurations
==============
nsh:
---------
Configures the NuttShell (nsh) located at apps/examples/nsh for the
Nucleo-F410RB board. The Configuration enables the serial interfaces
on UART2. Support for builtin applications is enabled, but in the base
configuration no builtin applications are selected (see NOTES below).
NOTES:
1. This configuration uses the mconf-based configuration tool. To
change this configuration using that tool, you should:
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
see additional README.txt files in the NuttX tools repository.
b. Execute 'make menuconfig' in nuttx/ in order to start the
reconfiguration process.

253
boards/arm/stm32/nucleo-f412zg/README.txt
View File

@ -1,253 +0,0 @@
README
======
This README discusses issues unique to NuttX configurations for the ST
NucleoF410RB board from ST Micro. See
http://www.st.com/en/evaluation-tools/nucleo-f412zg.html
NucleoF412ZG:
Microprocessor: 32-bit ARM Cortex M4 at 100MHz STM32F412ZG
Memory: 1 MB Flash and 256 KB SRAM
ADC: 1x12-bit, 2.4 MSPS A/D converter: up to 16 channels
DMA: 2x8-stream DMA controllers with FIFOs and burst support
Timers: Up to 17 timers: up to 12 16-bit, 2 32-bit timers, two
watchdog timers, and a SysTick timer
GPIO: Up to 114 I/O ports with interrupt capability
I2C: Up to 4 I2C interfaces
USARTs: Up to 4 USARTs
SPIs: Up to 5 SPIs (5 I2S)
SDIO interface (SD/MMC/eMMC)
Advanced connectivity: USB 2.0 full-speed device/host/OTG controller with PHY
2x CAN (2.0B Active)
True random number generator
CRC calculation unit
96-bit unique ID
RTC
JAKE: TODO
See:
https://www.st.com/content/ccc/resource/technical/document/user_manual/group0/26/49/90/2e/33/0d/4a/da/DM00244518/files/DM00244518.pdf/jcr:content/translations/en.DM00244518.pdf
Peripherals: 3 led, 2 push button
Debug: Serial wire debug and JTAG interfaces
Expansion I/F Ardino and Morpho Headers
Contents
========
- Nucleo-64 Boards
- Button
- LED
- USARTs and Serial Consoles
- Configurations
Nucleo-64 Boards
================
The Nucleo-F410RB board is member of the Nucleo-64 board family. The
Nucleo-64 is a standard board for use with several STM32 parts in the
LQFP64 package. Variants include
Order code Targeted STM32
------------- --------------
NUCLEO-F030R8 STM32F030R8T6
NUCLEO-F070RB STM32F070RBT6
NUCLEO-F072RB STM32F072RBT6
NUCLEO-F091RC STM32F091RCT6
NUCLEO-F103RB STM32F103RBT6
NUCLEO-F302R8 STM32F302R8T6
NUCLEO-F303RE STM32F303RET6
NUCLEO-F334R8 STM32F334R8T6
NUCLEO-F401RE STM32F401RET6
NUCLEO-F410RB STM32F410RBT6
NUCLEO-F411RE STM32F411RET6
NUCLEO-F446RE STM32F446RET6
NUCLEO-L053R8 STM32L053R8T6
NUCLEO-L073RZ STM32L073RZT6
NUCLEO-L152RE STM32L152RET6
NUCLEO-L452RE STM32L452RET6
NUCLEO-L476RG STM32L476RGT6
Hardware
========
Buttons
-------
B1 USER: the user button is connected to the I/O PC13 (pin 2) of the STM32
microcontroller.
LEDs
----
The Nucleo F410RB provide a single user LED, LD2. LD2
is the green LED connected to Arduino signal D13 corresponding to MCU I/O
PA5 (pin 21) or PB13 (pin 34) depending on the STM32target.
- When the I/O is HIGH value, the LED is on.
- When the I/O is LOW, the LED is off.
These LEDs are not used by the board port unless CONFIG_ARCH_LEDS is
defined. In that case, the usage by the board port is defined in
include/board.h and src/sam_leds.c. The LEDs are used to encode OS-related
events as follows when the red LED (PE24) is available:
SYMBOL Meaning LD2
------------------- ----------------------- -----------
LED_STARTED NuttX has been started OFF
LED_HEAPALLOCATE Heap has been allocated OFF
LED_IRQSENABLED Interrupts enabled OFF
LED_STACKCREATED Idle stack created ON
LED_INIRQ In an interrupt No change
LED_SIGNAL In a signal handler No change
LED_ASSERTION An assertion failed No change
LED_PANIC The system has crashed Blinking
LED_IDLE MCU is is sleep mode Not used
Thus if LD2, NuttX has successfully booted and is, apparently, running
normally. If LD2 is flashing at approximately 2Hz, then a fatal error
has been detected and the system has halted.
Serial Consoles
===============
USART1
------
Pins and Connectors:
RXD: PA11 CN10 pin 14
PB7 CN7 pin 21
TXD: PA10 CN9 pin 3, CN10 pin 33
PB6 CN5 pin 3, CN10 pin 17
NOTE: You may need to edit the include/board.h to select different USART1
pin selections.
TTL to RS-232 converter connection:
Nucleo CN10 STM32F410RB
----------- ------------
Pin 21 PA9 USART1_RX *Warning you make need to reverse RX/TX on
Pin 33 PA10 USART1_TX some RS-232 converters
Pin 20 GND
Pin 8 U5V
To configure USART1 as the console:
CONFIG_STM32_USART1=y
CONFIG_USART1_SERIALDRIVER=y
CONFIG_USART1_SERIAL_CONSOLE=y
CONFIG_USART1_RXBUFSIZE=256
CONFIG_USART1_TXBUFSIZE=256
CONFIG_USART1_BAUD=115200
CONFIG_USART1_BITS=8
CONFIG_USART1_PARITY=0
CONFIG_USART1_2STOP=0
USART2
-----
Pins and Connectors:
RXD: PA3 CN9 pin 1 (See SB13, 14, 62, 63). CN10 pin 37
PD6
TXD: PA2 CN9 pin 2(See SB13, 14, 62, 63). CN10 pin 35
PD5
UART2 is the default in all of these configurations.
TTL to RS-232 converter connection:
Nucleo CN9 STM32F410RB
----------- ------------
Pin 1 PA3 USART2_RX *Warning you make need to reverse RX/TX on
Pin 2 PA2 USART2_TX some RS-232 converters
Solder Bridges. This configuration requires:
- SB62 and SB63 Closed: PA2 and PA3 on STM32 MCU are connected to D1 and D0
(pin 7 and pin 8) on Arduino connector CN9 and ST Morpho connector CN10
as USART signals. Thus SB13 and SB14 should be OFF.
- SB13 and SB14 Open: PA2 and PA3 on STM32F103C8T6 (ST-LINK MCU) are
disconnected to PA3 and PA2 on STM32 MCU.
To configure USART2 as the console:
CONFIG_STM32_USART2=y
CONFIG_USART2_SERIALDRIVER=y
CONFIG_USART2_SERIAL_CONSOLE=y
CONFIG_USART2_RXBUFSIZE=256
CONFIG_USART2_TXBUFSIZE=256
CONFIG_USART2_BAUD=115200
CONFIG_USART2_BITS=8
CONFIG_USART2_PARITY=0
CONFIG_USART2_2STOP=0
USART6
------
Pins and Connectors:
RXD: PC7 CN5 pin2, CN10 pin 19
PA12 CN10, pin 12
TXD: PC6 CN10, pin 4
PA11 CN10, pin 14
To configure USART6 as the console:
CONFIG_STM32_USART6=y
CONFIG_USART6_SERIALDRIVER=y
CONFIG_USART6_SERIAL_CONSOLE=y
CONFIG_USART6_RXBUFSIZE=256
CONFIG_USART6_TXBUFSIZE=256
CONFIG_USART6_BAUD=115200
CONFIG_USART6_BITS=8
CONFIG_USART6_PARITY=0
CONFIG_USART6_2STOP=0
Virtual COM Port
----------------
Yet another option is to use UART2 and the USB virtual COM port. This
option may be more convenient for long term development, but is painful
to use during board bring-up.
Solder Bridges. This configuration requires:
- SB62 and SB63 Open: PA2 and PA3 on STM32 MCU are disconnected to D1
and D0 (pin 7 and pin 8) on Arduino connector CN9 and ST Morpho
connector CN10.
- SB13 and SB14 Closed: PA2 and PA3 on STM32F103C8T6 (ST-LINK MCU) are
connected to PA3 and PA2 on STM32 MCU to have USART communication
between them. Thus SB61, SB62 and SB63 should be OFF.
Configuring USART2 is the same as given above.
Question: What BAUD should be configure to interface with the Virtual
COM port? 115200 8N1?
Default
-------
As shipped, SB62 and SB63 are open and SB13 and SB14 closed, so the
virtual COM port is enabled.
Configurations
==============
nsh:
---------
Configures the NuttShell (nsh) located at apps/examples/nsh for the
Nucleo-F410RB board. The Configuration enables the serial interfaces
on UART2. Support for builtin applications is enabled, but in the base
configuration no builtin applications are selected (see NOTES below).
NOTES:
1. This configuration uses the mconf-based configuration tool. To
change this configuration using that tool, you should:
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
see additional README.txt files in the NuttX tools repository.
b. Execute 'make menuconfig' in nuttx/ in order to start the
reconfiguration process.

662
boards/arm/stm32/nucleo-f446re/README.txt
View File

@ -1,662 +0,0 @@
README
======
This README discusses issues unique to NuttX configurations for the ST
NucleoF446RE boards from ST Micro. See
https://www.st.com/en/evaluation-tools/nucleo-f446re.html
NucleoF446RE:
Microprocessor: 32-bit ARM Cortex M4 at 180MHz STM32F446RE
Memory: 512 KB Flash and 128 KB SRAM
(todo)
ADC: 1×12-bit, 2.4 MSPS A/D converter: up to 10 channels
DMA: 16-stream DMA controllers with FIFOs and burst support
Timers: Up to 11 timers: up to six 16-bit, two 32-bit timers, two
watchdog timers, and a SysTick timer
GPIO: Up to 81 I/O ports with interrupt capability
I2C: Up to 3 × I2C interfaces
USARTs: Up to 3 USARTs
USARTs: Up to 3 USARTs
SPIs: Up to 4 SPIs (2 I2S)
SDIO interface
USB: USB 2.0 full-speed device/host/OTG controller with on-chip PHY
CRC calculation unit
RTC
The NucleoF446RE also has additional DMA and SPI peripheral capabilities.
Board features, however, are identical:
Peripherals: 1 led, 1 push button
Debug: Serial wire debug and JTAG interfaces
Expansion I/F Ardino and Morpho Headers
Uses a STM32F103 to provide a ST-Link for programming, debug similar to the
OpenOcd FTDI function - USB to JTAG front-end.
See https://os.mbed.com/platforms/ST-Nucleo-F446RE/ for more
information about this board.
Contents
========
- Nucleo-64 Boards
- Development Environment
- GNU Toolchain Options
- IDEs
- NuttX EABI "buildroot" Toolchain
- NXFLAT Toolchain
- Hardware
- Button
- LED
- USARTs and Serial Consoles
- LQFP64
- mbed
- Shields
- Configurations
Nucleo-64 Boards
================
The Nucleo-F446RE board is a member of the Nucleo-64 board family. The
Nucleo-64 is a standard board for use with several STM32 parts in the
LQFP64 package. Variants include
Order code Targeted STM32
------------- --------------
NUCLEO-F030R8 STM32F030R8T6
NUCLEO-F070RB STM32F070RBT6
NUCLEO-F072RB STM32F072RBT6
NUCLEO-F091RC STM32F091RCT6
NUCLEO-F103RB STM32F103RBT6
NUCLEO-F302R8 STM32F302R8T6
NUCLEO-F303RE STM32F303RET6
NUCLEO-F334R8 STM32F334R8T6
NUCLEO-F401RE STM32F401RET6
NUCLEO-F410RB STM32F410RBT6
NUCLEO-F411RE STM32F411RET6
NUCLEO-F446RE STM32F446RET6
NUCLEO-L053R8 STM32L053R8T6
NUCLEO-L073RZ STM32L073RZT6
NUCLEO-L152RE STM32L152RET6
NUCLEO-L452RE STM32L452RET6
NUCLEO-L476RG STM32L476RGT6
Development Environment
=======================
Either Linux or Cygwin on Windows can be used for the development environment.
The source has been built only using the GNU toolchain (see below). Other
toolchains will likely cause problems.
GNU Toolchain Options
=====================
Toolchain Configurations
------------------------
The NuttX make system has been modified to support the following different
toolchain options.
1. The NuttX buildroot Toolchain (see below), or
2. Any generic arm-none-eabi GNU toolchain.
All testing has been conducted using the NuttX Codesourcery toolchain. To use
a different toolchain, you simply need to modify the configuration. As an
example:
CONFIG_ARM_TOOLCHAIN_GNU_EABI : Generic arm-none-eabi toolchain
IDEs
====
NuttX is built using command-line make. It can be used with an IDE, but some
effort will be required to create the project.
Makefile Build
--------------
Under Eclipse, it is pretty easy to set up an "empty makefile project" and
simply use the NuttX makefile to build the system. That is almost for free
under Linux. Under Windows, you will need to set up the "Cygwin GCC" empty
makefile project in order to work with Windows (Google for "Eclipse Cygwin" -
there is a lot of help on the internet).
Using Sourcery CodeBench from http://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/overview
Download and install the latest version (as of this writing it was
sourceryg++-2013.05-64-arm-none-eabi)
Import the project from git.
File->import->Git-URI, then import a Exiting code as a Makefile progject
from the working directory the git clone was done to.
Select the Sourcery CodeBench for ARM EABI. N.B. You must do one command line
build, before the make will work in CodeBench.
Native Build
------------
Here are a few tips before you start that effort:
1) Select the toolchain that you will be using in your .config file
2) Start the NuttX build at least one time from the Cygwin command line
before trying to create your project. This is necessary to create
certain auto-generated files and directories that will be needed.
3) Set up include paths: You will need include/, arch/arm/src/stm32,
arch/arm/src/common, arch/arm/src/armv7-m, and sched/.
4) All assembly files need to have the definition option -D __ASSEMBLY__
on the command line.
Startup files will probably cause you some headaches. The NuttX startup file
is arch/arm/src/stm32/stm32_vectors.S. With RIDE, I have to build NuttX
one time from the Cygwin command line in order to obtain the pre-built
startup object needed by RIDE.
NuttX EABI "buildroot" Toolchain
================================
A GNU GCC-based toolchain is assumed. The PATH environment variable should
be modified to point to the correct path to the Cortex-M3 GCC toolchain (if
different from the default in your PATH variable).
If you have no Cortex-M3 toolchain, one can be downloaded from the NuttX
Bitbucket download site (https://bitbucket.org/nuttx/buildroot/downloads/).
This GNU toolchain builds and executes in the Linux or Cygwin environment.
1. You must have already configured NuttX in <some-dir>/nuttx.
$ tools/configure.sh nucleo-f446re:nsh
$ make qconfig
$ V=1 make context all 2>&1 | tee mout
2. Download the latest buildroot package into <some-dir>
3. unpack the buildroot tarball. The resulting directory may
have versioning information on it like buildroot-x.y.z. If so,
rename <some-dir>/buildroot-x.y.z to <some-dir>/buildroot.
4. cd <some-dir>/buildroot
5. cp boards/cortexm3-eabi-defconfig-4.6.3 .config
6. make oldconfig
7. make
8. Make sure that the PATH variable includes the path to the newly built
binaries.
See the file boards/README.txt in the buildroot source tree. That has more
details PLUS some special instructions that you will need to follow if you are
building a Cortex-M3 toolchain for Cygwin under Windows.
NOTE: Unfortunately, the 4.6.3 EABI toolchain is not compatible with the
the NXFLAT tools. See the top-level TODO file (under "Binary loaders") for
more information about this problem. If you plan to use NXFLAT, please do not
use the GCC 4.6.3 EABI toolchain; instead use the GCC 4.3.3 EABI toolchain.
NXFLAT Toolchain
================
If you are *not* using the NuttX buildroot toolchain and you want to use
the NXFLAT tools, then you will still have to build a portion of the buildroot
tools -- just the NXFLAT tools. The buildroot with the NXFLAT tools can
be downloaded from the NuttX Bitbucket download site
(https://bitbucket.org/nuttx/nuttx/downloads/).
This GNU toolchain builds and executes in the Linux or Cygwin environment.
1. You must have already configured NuttX in <some-dir>/nuttx.
tools/configure.sh lpcxpresso-lpc1768:<sub-dir>
2. Download the latest buildroot package into <some-dir>
3. unpack the buildroot tarball. The resulting directory may
have versioning information on it like buildroot-x.y.z. If so,
rename <some-dir>/buildroot-x.y.z to <some-dir>/buildroot.
4. cd <some-dir>/buildroot
5. cp boards/cortexm3-defconfig-nxflat .config
6. make oldconfig
7. make
8. Make sure that the PATH variable includes the path to the newly built
NXFLAT binaries.
mbed
====
The Nucleo-F401RE includes boot loader from mbed:
https://mbed.org/platforms/ST-Nucleo-F401RE/
https://mbed.org/handbook/Homepage
Using the mbed loader:
1. Connect the Nucleo-F4x1RE to the host PC using the USB connector.
2. A new file system will appear called NUCLEO; open it with Windows
Explorer (assuming that you are using Windows).
3. Drag and drop nuttx.bin into the MBED window. This will load the
nuttx.bin binary into the Nucleo-F4x1RE. The NUCLEO window will
close then re-open and the Nucleo-F4x1RE will be running the new code.
Hardware
========
GPIO
----
SERIAL_TX=PA_2 USER_BUTTON=PC_13
SERIAL_RX=PA_3 LED1 =PA_5
A0=PA_0 USART2RX D0=PA_3 D8 =PA_9
A1=PA_1 USART2TX D1=PA_2 D9 =PC_7
A2=PA_4 D2=PA_10 WIFI_CS=D10=PB_6 SPI_CS
A3=PB_0 WIFI_INT=D3=PB_3 D11=PA_7 SPI_MOSI
A4=PC_1 SDCS=D4=PB_5 D12=PA_6 SPI_MISO
A5=PC_0 WIFI_EN=D5=PB_4 LED1=D13=PA_5 SPI_SCK
LED2=D6=PB_10 I2C1_SDA=D14=PB_9 Probe
D7=PA_8 I2C1_SCL=D15=PB_8 Probe
From: https://mbed.org/platforms/ST-Nucleo-F401RE/
Buttons
-------
B1 USER: the user button is connected to the I/O PC13 (pin 2) of the STM32
microcontroller.
LEDs
----
The Nucleo F446RE provides a single user LED, LD2. LD2
is the green LED connected to Arduino signal D13 corresponding to MCU I/O
PA5 (pin 21) or PB13 (pin 34) depending on the STM32target.
- When the I/O is HIGH value, the LED is on.
- When the I/O is LOW, the LED is off.
These LEDs are not used by the board port unless CONFIG_ARCH_LEDS is
defined. In that case, the usage by the board port is defined in
include/board.h and src/sam_leds.c. The LEDs are used to encode OS-related
events as follows when the red LED (PE24) is available:
SYMBOL Meaning LD2
------------------- ----------------------- -----------
LED_STARTED NuttX has been started OFF
LED_HEAPALLOCATE Heap has been allocated OFF
LED_IRQSENABLED Interrupts enabled OFF
LED_STACKCREATED Idle stack created ON
LED_INIRQ In an interrupt No change
LED_SIGNAL In a signal handler No change
LED_ASSERTION An assertion failed No change
LED_PANIC The system has crashed Blinking
LED_IDLE MCU is is sleep mode Not used
Thus if LD2, NuttX has successfully booted and is, apparently, running
normally. If LD2 is flashing at approximately 2Hz, then a fatal error
has been detected and the system has halted.
Serial Consoles
===============
USART1
------
Pins and Connectors:
RXD: PA11 CN10 pin 14
PB7 CN7 pin 21
TXD: PA10 CN9 pin 3, CN10 pin 33
PB6 CN5 pin 3, CN10 pin 17
NOTE: You may need to edit the include/board.h to select different USART1
pin selections.
TTL to RS-232 converter connection:
Nucleo CN10 STM32F4x1RE
----------- ------------
Pin 21 PA9 USART1_RX *Warning you make need to reverse RX/TX on
Pin 33 PA10 USART1_TX some RS-232 converters
Pin 20 GND
Pin 8 U5V
To configure USART1 as the console:
CONFIG_STM32_USART1=y
CONFIG_USART1_SERIALDRIVER=y
CONFIG_USART1_SERIAL_CONSOLE=y
CONFIG_USART1_RXBUFSIZE=256
CONFIG_USART1_TXBUFSIZE=256
CONFIG_USART1_BAUD=115200
CONFIG_USART1_BITS=8
CONFIG_USART1_PARITY=0
CONFIG_USART1_2STOP=0
USART2
-----
Pins and Connectors:
RXD: PA3 CN9 pin 1 (See SB13, 14, 62, 63). CN10 pin 37
PD6
TXD: PA2 CN9 pin 2(See SB13, 14, 62, 63). CN10 pin 35
PD5
UART2 is the default in all of these configurations.
TTL to RS-232 converter connection:
Nucleo CN9 STM32F4x1RE
----------- ------------
Pin 1 PA3 USART2_RX *Warning you make need to reverse RX/TX on
Pin 2 PA2 USART2_TX some RS-232 converters
Solder Bridges. This configuration requires:
- SB62 and SB63 Closed: PA2 and PA3 on STM32 MCU are connected to D1 and D0
(pin 7 and pin 8) on Arduino connector CN9 and ST Morpho connector CN10
as USART signals. Thus SB13 and SB14 should be OFF.
- SB13 and SB14 Open: PA2 and PA3 on STM32F103C8T6 (ST-LINK MCU) are
disconnected to PA3 and PA2 on STM32 MCU.
To configure USART2 as the console:
CONFIG_STM32_USART2=y
CONFIG_USART2_SERIALDRIVER=y
CONFIG_USART2_SERIAL_CONSOLE=y
CONFIG_USART2_RXBUFSIZE=256
CONFIG_USART2_TXBUFSIZE=256
CONFIG_USART2_BAUD=115200
CONFIG_USART2_BITS=8
CONFIG_USART2_PARITY=0
CONFIG_USART2_2STOP=0
USART6
------
Pins and Connectors:
RXD: PC7 CN5 pin2, CN10 pin 19
PA12 CN10, pin 12
TXD: PC6 CN10, pin 4
PA11 CN10, pin 14
To configure USART6 as the console:
CONFIG_STM32_USART6=y
CONFIG_USART6_SERIALDRIVER=y
CONFIG_USART6_SERIAL_CONSOLE=y
CONFIG_USART6_RXBUFSIZE=256
CONFIG_USART6_TXBUFSIZE=256
CONFIG_USART6_BAUD=115200
CONFIG_USART6_BITS=8
CONFIG_USART6_PARITY=0
CONFIG_USART6_2STOP=0
Virtual COM Port
----------------
Yet another option is to use UART2 and the USB virtual COM port. This
option may be more convenient for long term development, but is painful
to use during board bring-up.
Solder Bridges. This configuration requires:
- SB62 and SB63 Open: PA2 and PA3 on STM32 MCU are disconnected to D1
and D0 (pin 7 and pin 8) on Arduino connector CN9 and ST Morpho
connector CN10.
- SB13 and SB14 Closed: PA2 and PA3 on STM32F103C8T6 (ST-LINK MCU) are
connected to PA3 and PA2 on STM32 MCU to have USART communication
between them. Thus SB61, SB62 and SB63 should be OFF.
Configuring USART2 is the same as given above.
Question: What BAUD should be configure to interface with the Virtual
COM port? 115200 8N1?
Default
-------
As shipped, SB62 and SB63 are open and SB13 and SB14 closed, so the
virtual COM port is enabled.
Shields
=======
RS-232 from Cutedigi.com
------------------------
Supports a single RS-232 connected via
Nucleo CN9 STM32F4x1RE Cutedigi
----------- ------------ --------
Pin 1 PA3 USART2_RX RXD
Pin 2 PA2 USART2_TX TXD
Support for this shield is enabled by selecting USART2 and configuring
SB13, 14, 62, and 63 as described above under "Serial Consoles"
Itead Joystick Shield
---------------------
See http://imall.iteadstudio.com/im120417014.html for more information
about this joystick.
Itead Joystick Connection:
--------- ----------------- ---------------------------------
ARDUINO ITEAD NUCLEO-F4x1
PIN NAME SIGNAL SIGNAL
--------- ----------------- ---------------------------------
D3 Button E Output PB3
D4 Button D Output PB5
D5 Button C Output PB4
D6 Button B Output PB10
D7 Button A Output PA8
D8 Button F Output PA9
D9 Button G Output PC7
A0 Joystick Y Output PA0 ADC1_0
A1 Joystick X Output PA1 ADC1_1
--------- ----------------- ---------------------------------
All buttons are pulled on the shield. A sensed low value indicates
when the button is pressed.
NOTE: Button F cannot be used with the default USART1 configuration
because PA9 is configured for USART1_RX by default. Use select
different USART1 pins in the board.h file or select a different
USART or select CONFIG_NUCLEO_F401RE_AJOY_MINBUTTONS which will
eliminate all but buttons A, B, and C.
Itead Joystick Signal interpretation:
--------- ----------------------- ---------------------------
BUTTON TYPE NUTTX ALIAS
--------- ----------------------- ---------------------------
Button A Large button A JUMP/BUTTON 3
Button B Large button B FIRE/BUTTON 2
Button C Joystick select button SELECT/BUTTON 1
Button D Tiny Button D BUTTON 6
Button E Tiny Button E BUTTON 7
Button F Large Button F BUTTON 4
Button G Large Button G BUTTON 5
--------- ----------------------- ---------------------------
Itead Joystick configuration settings:
System Type -> STM32 Peripheral Support
CONFIG_STM32_ADC1=y : Enable ADC1 driver support
Drivers
CONFIG_ANALOG=y : Should be automatically selected
CONFIG_ADC=y : Should be automatically selected
CONFIG_INPUT=y : Select input device support
CONFIG_INPUT_AJOYSTICK=y : Select analog joystick support
There is nothing in the configuration that currently uses the joystick.
For testing, you can add the following configuration options to enable the
analog joystick example at apps/examples/ajoystick:
CONFIG_NSH_ARCHINIT=y
CONFIG_EXAMPLES_AJOYSTICK=y
CONFIG_EXAMPLES_AJOYSTICK_DEVNAME="/dev/ajoy0"
STATUS:
2014-12-04:
- Without ADC DMA support, it is not possible to sample both X and Y
with a single ADC. Right now, only one axis is being converted.
- There is conflicts with some of the Arduino data pins and the
default USART1 configuration. I am currently running with USART1
but with CONFIG_NUCLEO_F401RE_AJOY_MINBUTTONS to eliminate the
conflict.
- Current showstopper: I appear to be getting infinite interrupts as
soon as joystick button interrupts are enabled.
Configurations
==============
nsh:
----
Configures the NuttShell (nsh) located at apps/examples/nsh for the
Nucleo-F446RE board. The Configuration enables the serial interfaces
on UART2. Support for builtin applications is enabled, but in the base
configuration no builtin applications are selected (see NOTES below).
NOTES:
1. This configuration uses the mconf-based configuration tool. To
change this configuration using that tool, you should:
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
see additional README.txt files in the NuttX tools repository.
b. Execute 'make menuconfig' in nuttx/ in order to start the
reconfiguration process.
2. By default, this configuration uses the ARM EABI toolchain
for Linux. That can easily be reconfigured, of course.
CONFIG_HOST_LINUX=y : Builds under Linux
CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : GNU EABI toolchain for Linux
3. Although the default console is USART2 (which would correspond to
the Virtual COM port) I have done all testing with the console
device configured for USART1 (see instruction above under "Serial
Consoles). I have been using a TTL-to-RS-232 converter connected
as shown below:
Nucleo CN10 STM32F446RE
----------- ------------
Pin 21 PA9 USART1_RX *Warning you make need to reverse RX/TX on
Pin 33 PA10 USART1_TX some RS-232 converters
Pin 20 GND
Pin 8 U5V
can:
----
This is basically an nsh configuration (see above) with added support
for CAN driver. Both CAN 1 (RX: PB_8, TX: PB_9) and CAN 2 (RX: PB_5, TX: PB_6)
are turn on.
Functionality of CAN driver can be tested by calling application
"can" in NuttShell. This application sends 100 messages over CAN 1.
dac:
----
This is an nsh configuration (see above) with added support
for digital analog converter driver.
Functionality of DAC driver can be tested by calling application
"dac" in NuttShell. GPIO_DAC1_OUT1 pin is set on PA_4.
gpio:
-----
This is an nsh configuration (see above) with added support for GPIO
driver and GPIO test application "gpio". Three pins are configured for
testing purposes:
PA_7 - GPIO_INPUT
PB_6 - GPIO_OUTPUT
PC_7 - GPIO_INPUT_INTERRUPT
ihm08m1_f32 and ihm08m1_b16:
----------------------------
These examples are dedicated for the X-NUCLEO-IHM08M1 expansion board with
L6398 gate drivers and discrete transistors.
WARNING: L6398 gate drivers require channel 2 negative polarisation and
negative sign for the deadtime. Make sure that your gate drivers logic
is compatible with this configuration.
X-NUCLEO-IHM08M1 must be configured to work with FOC and 3-shunt
resistors. See ST documentation for details.
Pin configuration for the X-NUCLEO-IHM08M1 (TIM1 configuration):
Board Function Chip Function Chip Pin Number
------------- ---------------- -----------------
Phase U high TIM1_CH1 PA8
Phase U low TIM1_CH1N PA7
Phase V high TIM1_CH2 PA9
Phase V low TIM1_CH2N PB0
Phase W high TIM1_CH3 PA10
Phase W low TIM1_CH3N PB1
Current U ADC1_IN0 PA0
Current V ADC1_IN11 PC1
Current W ADC1_IN10 PC0
Temperature ADC1_IN12 PC2
VBUS ADC1_IN1 PA1
BEMF1 (NU) PC3
BEMF2 (NU) PC4
BEMF3 (NU) PC5
LED GPIO_PB2 PB2
+3V3 (CN7_16)
GND (CN7_20)
GPIO_BEMF (NU) PC9
ENCO_A/HALL_H1 TIM2_CH1 PA15
ENCO_B/HALL_H2 TIM2_CH2 PB3
ENCO_Z/HALL_H3 TIM2_CH3 PB10
DAC (NU) PA5
GPIO3 (NU) PB13
CPOUT (NU) PA12
BKIN1 (NU) PA6
BKIN2 (NU) PA11
BKIN3 (NU) PB14
POT/DAC DAC1_CH1/ADC1_IN4 PA4
CURR_REF (NU) PB4
DEBUG0 GPIO PB12
DEBUG1 GPIO PB9
DEBUG2 GPIO PC6
DEBUG3 GPIO PB5
DEBUG4 GPIO PC8
Current shunt resistance = 0.01
Current sense gain = -5.18 (inverted current)
Vbus sense gain = 9.31k/(9.31k+169k) = 0.0522
Vbus min = 10V
Vbus max = 48V
Iout max = 15A RMS
IPHASE_RATIO = 1/(R_shunt*gain) = -19.3
VBUS_RATIO = 1/VBUS_gain = 19.152
For now only 3-shunt resistors configuration is supported.
lcd:
----
This is basically an nsh configuration (see above) with added support
of ILI9225 176x220 TFT display and test framebuffer application.
Display connection is set to SPI 3 and pinout is following:
CS D8
RST D6
RS D7
SDA D4
CLK D3
Framebuffer application can be started from terminal by typing "fb".
pwm:
----
This is an nsh configuration (see above) with added capability of pulse width
modulation. PWM output is on Timer 3 channel 1, which is pin PA_6 (D12) on
Nucleo board. Example program can be stared by "pwm" command.

580
boards/arm/stm32/nucleo-f4x1re/README.txt
View File

@ -1,580 +0,0 @@
README
======
This README discusses issues unique to NuttX configurations for the ST
NucleoF401RE and NucleoF411RE boards from ST Micro. See
http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1577/LN1810/PF258797
http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1577/LN1877/PF260049
These two boards are very similar, both supporting STM32 "Dynamic Efficiency
Line" parts but differing in the specific STM32 chip mounted on board. The
chips themselves are also very similar with the STM32F411RE having some
additional capability:
NucleoF401RE:
Microprocessor: 32-bit ARM Cortex M4 at 84MHz STM32F104RE
Memory: 512 KB Flash and 96 KB SRAM
ADC: 1×12-bit, 2.4 MSPS A/D converter: up to 10 channels
DMA: 16-stream DMA controllers with FIFOs and burst support
Timers: Up to 11 timers: up to six 16-bit, two 32-bit timers, two
watchdog timers, and a SysTick timer
GPIO: Up to 81 I/O ports with interrupt capability
I2C: Up to 3 × I2C interfaces
USARTs: Up to 3 USARTs
SPIs: Up to 4 SPIs (2 I2S)
SDIO interface
USB: USB 2.0 full-speed device/host/OTG controller with on-chip PHY
CRC calculation unit
RTC
NucleoF411RE:
Microprocessor: 32-bit ARM Cortex M4 at 100MHz STM32F411RE
Memory: 512 KB Flash and 128 KB SRAM
ADC: 1×12-bit, 2.4 MSPS A/D converter: up to 10 channels
DMA: 16-stream DMA controllers with FIFOs and burst support
Timers: Up to 11 timers: up to six 16-bit, two 32-bit timers, two
watchdog timers, and a SysTick timer
GPIO: Up to 81 I/O ports with interrupt capability
I2C: Up to 3 × I2C interfaces
USARTs: Up to 3 USARTs
USARTs: Up to 3 USARTs
SPIs: Up to 4 SPIs (2 I2S)
SDIO interface
USB: USB 2.0 full-speed device/host/OTG controller with on-chip PHY
CRC calculation unit
RTC
The NucleoF411RE also has additional DMA and SPI peripheral capabilities.
Board features, however, are identical:
Peripherals: 1 led, 1 push button
Debug: Serial wire debug and JTAG interfaces
Expansion I/F Ardino and Morpho Headers
Uses a STM32F103 to provide a ST-Link for programming, debug similar to the
OpenOcd FTDI function - USB to JTAG front-end.
See http://mbed.org/platforms/ST-Nucleo-F401RE and
http://developer.mbed.org/platforms/ST-Nucleo-F411RE for more
information about these boards.
Contents
========
- Nucleo-64 Boards
- Development Environment
- GNU Toolchain Options
- IDEs
- NuttX EABI "buildroot" Toolchain
- NXFLAT Toolchain
- Hardware
- Button
- LED
- USARTs and Serial Consoles
- LQFP64
- mbed
- Shields
- Configurations
Nucleo-64 Boards
================
The Nucleo-F4x1RE boards are members of the Nucleo-64 board family. The
Nucleo-64 is a standard board for use with several STM32 parts in the
LQFP64 package. Variants include
Order code Targeted STM32
------------- --------------
NUCLEO-F030R8 STM32F030R8T6
NUCLEO-F070RB STM32F070RBT6
NUCLEO-F072RB STM32F072RBT6
NUCLEO-F091RC STM32F091RCT6
NUCLEO-F103RB STM32F103RBT6
NUCLEO-F302R8 STM32F302R8T6
NUCLEO-F303RE STM32F303RET6
NUCLEO-F334R8 STM32F334R8T6
NUCLEO-F401RE STM32F401RET6
NUCLEO-F410RB STM32F410RBT6
NUCLEO-F411RE STM32F411RET6
NUCLEO-F446RE STM32F446RET6
NUCLEO-L053R8 STM32L053R8T6
NUCLEO-L073RZ STM32L073RZT6
NUCLEO-L152RE STM32L152RET6
NUCLEO-L452RE STM32L452RET6
NUCLEO-L476RG STM32L476RGT6
Development Environment
=======================
Either Linux or Cygwin on Windows can be used for the development environment.
The source has been built only using the GNU toolchain (see below). Other
toolchains will likely cause problems.
GNU Toolchain Options
=====================
Toolchain Configurations
------------------------
The NuttX make system has been modified to support the following different
toolchain options.
1. The NuttX buildroot Toolchain (see below), or
2. Any generic arm-none-eabi GNU toolchain.
All testing has been conducted using the NuttX Codesourcery toolchain. To use
a different toolchain, you simply need to modify the configuration. As an
example:
CONFIG_ARM_TOOLCHAIN_GNU_EABI : Generic arm-none-eabi toolchain
IDEs
====
NuttX is built using command-line make. It can be used with an IDE, but some
effort will be required to create the project.
Makefile Build
--------------
Under Eclipse, it is pretty easy to set up an "empty makefile project" and
simply use the NuttX makefile to build the system. That is almost for free
under Linux. Under Windows, you will need to set up the "Cygwin GCC" empty
makefile project in order to work with Windows (Google for "Eclipse Cygwin" -
there is a lot of help on the internet).
Using Sourcery CodeBench from http://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/overview
Download and install the latest version (as of this writing it was
sourceryg++-2013.05-64-arm-none-eabi)
Import the project from git.
File->import->Git-URI, then import a Exiting code as a Makefile progject
from the working directory the git clone was done to.
Select the Sourcery CodeBench for ARM EABI. N.B. You must do one command line
build, before the make will work in CodeBench.
Native Build
------------
Here are a few tips before you start that effort:
1) Select the toolchain that you will be using in your .config file
2) Start the NuttX build at least one time from the Cygwin command line
before trying to create your project. This is necessary to create
certain auto-generated files and directories that will be needed.
3) Set up include paths: You will need include/, arch/arm/src/stm32,
arch/arm/src/common, arch/arm/src/armv7-m, and sched/.
4) All assembly files need to have the definition option -D __ASSEMBLY__
on the command line.
Startup files will probably cause you some headaches. The NuttX startup file
is arch/arm/src/stm32/stm32_vectors.S. With RIDE, I have to build NuttX
one time from the Cygwin command line in order to obtain the pre-built
startup object needed by RIDE.
NuttX EABI "buildroot" Toolchain
================================
A GNU GCC-based toolchain is assumed. The PATH environment variable should
be modified to point to the correct path to the Cortex-M3 GCC toolchain (if
different from the default in your PATH variable).
If you have no Cortex-M3 toolchain, one can be downloaded from the NuttX
Bitbucket download site (https://bitbucket.org/nuttx/buildroot/downloads/).
This GNU toolchain builds and executes in the Linux or Cygwin environment.
1. You must have already configured NuttX in <some-dir>/nuttx.
$ tools/configure.sh nucleo-f4x1re:f401-nsh
$ make qconfig
$ V=1 make context all 2>&1 | tee mout
Use the f411-nsh configuration if you have the Nucleo-F411RE board.
2. Download the latest buildroot package into <some-dir>
3. unpack the buildroot tarball. The resulting directory may
have versioning information on it like buildroot-x.y.z. If so,
rename <some-dir>/buildroot-x.y.z to <some-dir>/buildroot.
4. cd <some-dir>/buildroot
5. cp boards/cortexm3-eabi-defconfig-4.6.3 .config
6. make oldconfig
7. make
8. Make sure that the PATH variable includes the path to the newly built
binaries.
See the file boards/README.txt in the buildroot source tree. That has more
details PLUS some special instructions that you will need to follow if you are
building a Cortex-M3 toolchain for Cygwin under Windows.
NOTE: Unfortunately, the 4.6.3 EABI toolchain is not compatible with the
the NXFLAT tools. See the top-level TODO file (under "Binary loaders") for
more information about this problem. If you plan to use NXFLAT, please do not
use the GCC 4.6.3 EABI toolchain; instead use the GCC 4.3.3 EABI toolchain.
NXFLAT Toolchain
================
If you are *not* using the NuttX buildroot toolchain and you want to use
the NXFLAT tools, then you will still have to build a portion of the buildroot
tools -- just the NXFLAT tools. The buildroot with the NXFLAT tools can
be downloaded from the NuttX Bitbucket download site
(https://bitbucket.org/nuttx/nuttx/downloads/).
This GNU toolchain builds and executes in the Linux or Cygwin environment.
1. You must have already configured NuttX in <some-dir>/nuttx.
tools/configure.sh lpcxpresso-lpc1768:<sub-dir>
2. Download the latest buildroot package into <some-dir>
3. unpack the buildroot tarball. The resulting directory may
have versioning information on it like buildroot-x.y.z. If so,
rename <some-dir>/buildroot-x.y.z to <some-dir>/buildroot.
4. cd <some-dir>/buildroot
5. cp boards/cortexm3-defconfig-nxflat .config
6. make oldconfig
7. make
8. Make sure that the PATH variable includes the path to the newly built
NXFLAT binaries.
mbed
====
The Nucleo-F401RE includes boot loader from mbed:
https://mbed.org/platforms/ST-Nucleo-F401RE/
https://mbed.org/handbook/Homepage
Using the mbed loader:
1. Connect the Nucleo-F4x1RE to the host PC using the USB connector.
2. A new file system will appear called NUCLEO; open it with Windows
Explorer (assuming that you are using Windows).
3. Drag and drop nuttx.bin into the MBED window. This will load the
nuttx.bin binary into the Nucleo-F4x1RE. The NUCLEO window will
close then re-open and the Nucleo-F4x1RE will be running the new code.
Hardware
========
GPIO
----
SERIAL_TX=PA_2 USER_BUTTON=PC_13
SERIAL_RX=PA_3 LED1 =PA_5
A0=PA_0 USART2RX D0=PA_3 D8 =PA_9
A1=PA_1 USART2TX D1=PA_2 D9 =PC_7
A2=PA_4 D2=PA_10 WIFI_CS=D10=PB_6 SPI_CS
A3=PB_0 WIFI_INT=D3=PB_3 D11=PA_7 SPI_MOSI
A4=PC_1 SDCS=D4=PB_5 D12=PA_6 SPI_MISO
A5=PC_0 WIFI_EN=D5=PB_4 LED1=D13=PA_5 SPI_SCK
LED2=D6=PB_10 I2C1_SDA=D14=PB_9 Probe
D7=PA_8 I2C1_SCL=D15=PB_8 Probe
From: https://mbed.org/platforms/ST-Nucleo-F401RE/
Buttons
-------
B1 USER: the user button is connected to the I/O PC13 (pin 2) of the STM32
microcontroller.
LEDs
----
The Nucleo F401RE and Nucleo F411RE provide a single user LED, LD2. LD2
is the green LED connected to Arduino signal D13 corresponding to MCU I/O
PA5 (pin 21) or PB13 (pin 34) depending on the STM32target.
- When the I/O is HIGH value, the LED is on.
- When the I/O is LOW, the LED is off.
These LEDs are not used by the board port unless CONFIG_ARCH_LEDS is
defined. In that case, the usage by the board port is defined in
include/board.h and src/sam_leds.c. The LEDs are used to encode OS-related
events as follows when the red LED (PE24) is available:
SYMBOL Meaning LD2
------------------- ----------------------- -----------
LED_STARTED NuttX has been started OFF
LED_HEAPALLOCATE Heap has been allocated OFF
LED_IRQSENABLED Interrupts enabled OFF
LED_STACKCREATED Idle stack created ON
LED_INIRQ In an interrupt No change
LED_SIGNAL In a signal handler No change
LED_ASSERTION An assertion failed No change
LED_PANIC The system has crashed Blinking
LED_IDLE MCU is is sleep mode Not used
Thus if LD2, NuttX has successfully booted and is, apparently, running
normally. If LD2 is flashing at approximately 2Hz, then a fatal error
has been detected and the system has halted.
Serial Consoles
===============
USART1
------
Pins and Connectors:
RXD: PA11 CN10 pin 14
PB7 CN7 pin 21
TXD: PA10 CN9 pin 3, CN10 pin 33
PB6 CN5 pin 3, CN10 pin 17
NOTE: You may need to edit the include/board.h to select different USART1
pin selections.
TTL to RS-232 converter connection:
Nucleo CN10 STM32F4x1RE
----------- ------------
Pin 21 PA9 USART1_RX *Warning you make need to reverse RX/TX on
Pin 33 PA10 USART1_TX some RS-232 converters
Pin 20 GND
Pin 8 U5V
To configure USART1 as the console:
CONFIG_STM32_USART1=y
CONFIG_USART1_SERIALDRIVER=y
CONFIG_USART1_SERIAL_CONSOLE=y
CONFIG_USART1_RXBUFSIZE=256
CONFIG_USART1_TXBUFSIZE=256
CONFIG_USART1_BAUD=115200
CONFIG_USART1_BITS=8
CONFIG_USART1_PARITY=0
CONFIG_USART1_2STOP=0
USART2
-----
Pins and Connectors:
RXD: PA3 CN9 pin 1 (See SB13, 14, 62, 63). CN10 pin 37
PD6
TXD: PA2 CN9 pin 2(See SB13, 14, 62, 63). CN10 pin 35
PD5
UART2 is the default in all of these configurations.
TTL to RS-232 converter connection:
Nucleo CN9 STM32F4x1RE
----------- ------------
Pin 1 PA3 USART2_RX *Warning you make need to reverse RX/TX on
Pin 2 PA2 USART2_TX some RS-232 converters
Solder Bridges. This configuration requires:
- SB62 and SB63 Closed: PA2 and PA3 on STM32 MCU are connected to D1 and D0
(pin 7 and pin 8) on Arduino connector CN9 and ST Morpho connector CN10
as USART signals. Thus SB13 and SB14 should be OFF.
- SB13 and SB14 Open: PA2 and PA3 on STM32F103C8T6 (ST-LINK MCU) are
disconnected to PA3 and PA2 on STM32 MCU.
To configure USART2 as the console:
CONFIG_STM32_USART2=y
CONFIG_USART2_SERIALDRIVER=y
CONFIG_USART2_SERIAL_CONSOLE=y
CONFIG_USART2_RXBUFSIZE=256
CONFIG_USART2_TXBUFSIZE=256
CONFIG_USART2_BAUD=115200
CONFIG_USART2_BITS=8
CONFIG_USART2_PARITY=0
CONFIG_USART2_2STOP=0
USART6
------
Pins and Connectors:
RXD: PC7 CN5 pin2, CN10 pin 19
PA12 CN10, pin 12
TXD: PC6 CN10, pin 4
PA11 CN10, pin 14
To configure USART6 as the console:
CONFIG_STM32_USART6=y
CONFIG_USART6_SERIALDRIVER=y
CONFIG_USART6_SERIAL_CONSOLE=y
CONFIG_USART6_RXBUFSIZE=256
CONFIG_USART6_TXBUFSIZE=256
CONFIG_USART6_BAUD=115200
CONFIG_USART6_BITS=8
CONFIG_USART6_PARITY=0
CONFIG_USART6_2STOP=0
Virtual COM Port
----------------
Yet another option is to use UART2 and the USB virtual COM port. This
option may be more convenient for long term development, but is painful
to use during board bring-up.
Solder Bridges. This configuration requires:
- SB62 and SB63 Open: PA2 and PA3 on STM32 MCU are disconnected to D1
and D0 (pin 7 and pin 8) on Arduino connector CN9 and ST Morpho
connector CN10.
- SB13 and SB14 Closed: PA2 and PA3 on STM32F103C8T6 (ST-LINK MCU) are
connected to PA3 and PA2 on STM32 MCU to have USART communication
between them. Thus SB61, SB62 and SB63 should be OFF.
Configuring USART2 is the same as given above.
Question: What BAUD should be configure to interface with the Virtual
COM port? 115200 8N1?
Default
-------
As shipped, SB62 and SB63 are open and SB13 and SB14 closed, so the
virtual COM port is enabled.
Shields
=======
RS-232 from Cutedigi.com
------------------------
Supports a single RS-232 connected via
Nucleo CN9 STM32F4x1RE Cutedigi
----------- ------------ --------
Pin 1 PA3 USART2_RX RXD
Pin 2 PA2 USART2_TX TXD
Support for this shield is enabled by selecting USART2 and configuring
SB13, 14, 62, and 63 as described above under "Serial Consoles"
Itead Joystick Shield
---------------------
See http://imall.iteadstudio.com/im120417014.html for more information
about this joystick.
Itead Joystick Connection:
--------- ----------------- ---------------------------------
ARDUINO ITEAD NUCLEO-F4x1
PIN NAME SIGNAL SIGNAL
--------- ----------------- ---------------------------------
D3 Button E Output PB3
D4 Button D Output PB5
D5 Button C Output PB4
D6 Button B Output PB10
D7 Button A Output PA8
D8 Button F Output PA9
D9 Button G Output PC7
A0 Joystick Y Output PA0 ADC1_0
A1 Joystick X Output PA1 ADC1_1
--------- ----------------- ---------------------------------
All buttons are pulled on the shield. A sensed low value indicates
when the button is pressed.
NOTE: Button F cannot be used with the default USART1 configuration
because PA9 is configured for USART1_RX by default. Use select
different USART1 pins in the board.h file or select a different
USART or select CONFIG_NUCLEO_F401RE_AJOY_MINBUTTONS which will
eliminate all but buttons A, B, and C.
Itead Joystick Signal interpretation:
--------- ----------------------- ---------------------------
BUTTON TYPE NUTTX ALIAS
--------- ----------------------- ---------------------------
Button A Large button A JUMP/BUTTON 3
Button B Large button B FIRE/BUTTON 2
Button C Joystick select button SELECT/BUTTON 1
Button D Tiny Button D BUTTON 6
Button E Tiny Button E BUTTON 7
Button F Large Button F BUTTON 4
Button G Large Button G BUTTON 5
--------- ----------------------- ---------------------------
Itead Joystick configuration settings:
System Type -> STM32 Peripheral Support
CONFIG_STM32_ADC1=y : Enable ADC1 driver support
Drivers
CONFIG_ANALOG=y : Should be automatically selected
CONFIG_ADC=y : Should be automatically selected
CONFIG_INPUT=y : Select input device support
CONFIG_INPUT_AJOYSTICK=y : Select analog joystick support
There is nothing in the configuration that currently uses the joystick.
For testing, you can add the following configuration options to enable the
analog joystick example at apps/examples/ajoystick:
CONFIG_NSH_ARCHINIT=y
CONFIG_EXAMPLES_AJOYSTICK=y
CONFIG_EXAMPLES_AJOYSTICK_DEVNAME="/dev/ajoy0"
STATUS:
2014-12-04:
- Without ADC DMA support, it is not possible to sample both X and Y
with a single ADC. Right now, only one axis is being converted.
- There is conflicts with some of the Arduino data pins and the
default USART1 configuration. I am currently running with USART1
but with CONFIG_NUCLEO_F401RE_AJOY_MINBUTTONS to eliminate the
conflict.
- Current showstopper: I appear to be getting infinite interrupts as
soon as joystick button interrupts are enabled.
Configurations
==============
f401-nsh:
---------
Configures the NuttShell (nsh) located at apps/examples/nsh for the
Nucleo-F401RE board. The Configuration enables the serial interfaces
on UART2. Support for builtin applications is enabled, but in the base
configuration no builtin applications are selected (see NOTES below).
NOTES:
1. This configuration uses the mconf-based configuration tool. To
change this configuration using that tool, you should:
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
see additional README.txt files in the NuttX tools repository.
b. Execute 'make menuconfig' in nuttx/ in order to start the
reconfiguration process.
2. By default, this configuration uses the ARM EABI toolchain
for Linux. That can easily be reconfigured, of course.
CONFIG_HOST_LINUX=y : Builds under Linux
CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : GNU EABI toolchain for Linux
3. Although the default console is USART2 (which would correspond to
the Virtual COM port) I have done all testing with the console
device configured for USART1 (see instruction above under "Serial
Consoles). I have been using a TTL-to-RS-232 converter connected
as shown below:
Nucleo CN10 STM32F4x1RE
----------- ------------
Pin 21 PA9 USART1_RX *Warning you make need to reverse RX/TX on
Pin 33 PA10 USART1_TX some RS-232 converters
Pin 20 GND
Pin 8 U5V
f411-nsh
--------
This configuration is the same as the f401-nsh configuration, except
that it is configured to support the Nucleo-F411RE.

196
boards/arm/stm32/olimex-stm32-e407/README.txt
View File

@ -1,196 +0,0 @@
README
======
The Olimex STM32-E407 configuration is based on the configuration
olimex-stm32-h407 and stm32f4discovery.
Configurations
==============
Instantiating Configurations
----------------------------
Each Olimex-STM32-E407 configuration is maintained in a sub-directory and
can be selected as follow:
tools/configure.sh [OPTIONS] olimex-stm32-e407:<subdir>
Typical options include -l for a Linux host platform or -c for Cygwin
host platform. See 'tools/configure.sh -h' for other options. And
<subdir> is one of the sub-directories listed below.
Compile Firmware
----------------
Once you've set the proper configuration, you just need to execute the next
command:
make
If everything goes find, it should return the next two files:
nuttx.hex
nuttx.bin
You can return more kinds of files by setting on menuconfig.
Flashing the Board
-----------------
You can flash this board in different ways, but the easiest way is using
ARM-USB-TINY-H JTAG flasher device.
Connect this device to the JTAG connector and type the next command:
openocd -f interface/ftdi/olimex-arm-usb-tiny-h.cfg -f target/stm32f4x.cfg -c init -c "reset halt" -c "flash write_image erase nuttx.bin 0x08000000"
Configuration Directories
-------------------------
nsh:
---
Configures the NuttShell (nsh) located at apps/examples/nsh. This
configuration enables a console on UART2. Support for
builtin applications is enabled, but in the base configuration no
builtin applications are selected.
usbnsh:
------
Configures the NuttShell (nsh) located at apps/examples/nsh. This
configuration enables a console on USB_OTG1. Support for
builtin applications is enabled, but in the base configuration no
builtin applications are selected.
netnsh:
------
Configures the NuttShell (nsh) located at examples/nsh. This
configuration is focused on network testing.
bmp180:
------
This is a configuration example for the BMP180 barometer sensor. This
sensor works with I2C, you need to do the next connections:
BMP180 VIN -> Board 3.3V
BMP180 GND -> Board GND
BMP180 SCL -> Board PB6 (Arduino header D1)
BMP180 SDA -> Board PB7 (Arduino header D0)
This example is configured to work with the USBNSH instead of UART NSH, so
the console will be shown over the USB_OTG1 connector.
On the console, type "ls /dev " and if the registration process goes fine,
you should see a device called "press0". Now execute the app
BMP180 to see the ambient pressure value.
dac:
---
This is a configuration example to use the DAC1 of the board. The DAC1
is attached to the PA4 pin (Arduino header D10).
This example is configured to work with the USBNSH instead of UART NSH, so
the console will be shown over the USB_OTG1 connector.
On the console, type "ls /dev " and if the registration process goes fine,
you should see a device called "dac0". Now execute the app
dac put a value at the output.
ina219:
------
This is a configuration example for the INA219 DC current sensor. This
sensor works with I2C, you need to do the next connections:
INA219 VIN -> Board 3.3V
INA219 GND -> Board GND
INA219 SCL -> Board PB6 (Arduino header D1)
INA219 SDA -> Board PB7 (Arduino header D0)
This example is configured to work with the USBNSH instead of UART NSH, so
the console will be shown over the USB_OTG1 connector.
On the console, type "ls /dev " and if the registration process goes fine,
you should see a device called "ina219". Now execute the app
ina219 to see the ambient pressure value.
timer:
-----
This configuration set the proper configuration to use the timer1 of the
board. This example is configured to work with the USBNSH instead of
UART NSH, so the console will be shown over the USB_OTG1 connector.
On the console, type "ls /dev " and if the registration process goes fine,
you should see a device called "timer1".
mrf24j40-mac:
------------
This configuration set the proper configuration to set the 802.15.4
communication layer with the MRF24J40 radio. This radio works with
SPI, you need to do the next connections:
MRF24J40 VCC -> Board 3.3V
MRF24J40 GND -> Board GND
MRF24J40 SCLK -> Board PA5 (Arduino header D13)
MRF24J40 MISO -> Board PA6 (Arduino header D12)
MRF24J40 MOSI -> Board PB5 (Arduino header D11)
MRF24J40 CS -> Board PA4 (Arduino header D10)
MRF24J40 INT -> Board PG12 (Arduino header D8)
This example is configured to work with the USBNSH instead of UART NSH,
so the console will be shown over the USB_OTG1 connector.
Once you're on the console, you need to check if the initialization
process was fine. To do so, you need to type "ls /dev" and you should
see a device call "ieee0". At this point we need to set-up the network,
follow the next steps:
This is an example of how to configure a coordinator:
i8sak /dev/ieee0 startpan cd:ab
i8sak set chan 11
i8sak set saddr 42:01
i8sak acceptassoc
This is an example of how to configure the endpoint:
i8sak /dev/ieee0
i8sak set chan 11
i8sak set panid cd:ab
i8sak set saddr 42:02
i8sak set ep_saddr 42:01
i8sak assoc
mrf24j40-6lowpan:
----------------
This configuration set the proper configuration to use 6lowpan protocol with the MRF24J40
radio. This radio works with SPI, you need to do the next connections:
MRF24J40 VCC -> Board 3.3V
MRF24J40 GND -> Board GND
MRF24J40 SCLK -> Board PA5 (Arduino header D13)
MRF24J40 MISO -> Board PA6 (Arduino header D12)
MRF24J40 MOSI -> Board PB5 (Arduino header D11)
MRF24J40 CS -> Board PA4 (Arduino header D10)
MRF24J40 INT -> Board PG12 (Arduino header D8)
This example is configured to work with the USBNSH instead of UART NSH, so
the console will be shown over the USB_OTG1 connector.
Once you're on the console, you need to check if the initialization process
was fine. To do so, you need to type "ls /dev" and you should see a device
call "ieee0". At this point we need to set-up the network, follow the next steps:
This is an example of how to configure a coordinator:
i8sak wpan0 startpan cd:ab
i8sak set chan 11
i8sak set saddr 42:01
i8sak acceptassoc
When the association was complete, you need to bring-up the network:
ifup wpan0
This is an example of how to configure the endpoint:
i8sak wpan0
i8sak set chan 11
i8sak set panid cd:ab
i8sak set saddr 42:02
i8sak set ep_saddr 42:01
i8sak assoc
When the association was complete, you need to bring-up the network:
ifup wpan0
If you execute the command "ifconfig", you will be able to see the info of the WPAN0 interface
and see the assigned IP. This interface can be use with an UDP or TCP server/client application.

655
boards/arm/stm32/olimex-stm32-p407/README.txt
View File

@ -1,655 +0,0 @@
README
======
The NuttX configuration for the Olimex STM32-P407 is derives more or less
directly from the Olimex STM32-P207 board support. The P207 and P407 seem
to share the same board design. Other code comes from the STM3240G board
support (which has the same crystal and clocking) and from the STM32 F4
Discovery (which has the same STM32 part)
Contents
========
o Board Support
o microSD Card Interface
o OTGFS Host
o Protect Mode Build
o Configurations
Board Support
=============
The following peripherals are available in this configuration.
- LEDs: Show the system status
- Buttons: TAMPER-button, WKUP-button, J1-Joystick (consists of RIGHT-,
UP-, LEFT-, DOWN-, and CENTER-button).
- ADC: ADC1 samples the red trim potentiometer AN_TR
Built in app 'adc' works.
- USB-FS-OTG: There is a USB-A-connector (host) connected to the full
speed STM32 OTG inputs.
- USB-HS-OTG: The other connector (device) is connected to the high speed
STM32 OTG inputs.
- CAN: Built in app 'can' works, but apart from that not really
tested.
- Ethernet: Ping to other station on the network works.
- microSD: Not fully functional. See below.
- LCD: Nokia 6610. This is similar the Nokia 6100 LCD used on other
Olimex boards. There is a driver for that LCD at
Obsoleted/nuttx/drivers/lcd/nokia6100.c, however, it was removed
because it was not properly integrated. It uses a 9-bit SPI
interface which is difficult to get working properly.
- External Support is included for the onboard SRAM. It uses SRAM
SRAM: settings from another board that might need to be tweaked.
Difficult to test because the SRAM conflicts with both
RS232 ports.
- Other: Buzzer, Camera, Temperature sensor, audio have not been
tested.
If so, then it requires a 9-bit
microSD Card Interface
======================
microSD Connector
-----------------
----------------- ----------------- ------------------------
SD/MMC CONNECTOR BOARD GPIO CONFIGURATION(s
PIN SIGNAL SIGNAL (no remapping)
--- ------------- ----------------- -------------------------
1 DAT2/RES SD_D2/USART3_TX/ PC10 GPIO_SDIO_D2
SPI3_SCK
2 CD/DAT3/CS SD_D3/USART3_RX/ PC11 GPIO_SDIO_D3
SPI3_MISO
3 CMD/DI SD_CMD PD2 GPIO_SDIO_CMD
4 VDD N/A N/A
5 CLK/SCLK SD_CLK/SPI3_MOSI PC12 GPIO_SDIO_CK
6 VSS N/A N/A
7 DAT0/D0 SD_D0/DCMI_D2 PC8 GPIO_SDIO_D0
8 DAT1/RES SD_D1/DCMI_D3 PC9 GPIO_SDIO_D1
--- ------------- ----------------- -------------------------
NOTES:
1. DAT4, DAT4, DAT6, and DAT7 not connected.
2. There are no alternative pin selections.
3. There is no card detect (CD) GPIO input so we will not
sense if there is a card in the SD slot or not. This will
make usage very awkward.
Configuration
-------------
Enabling SDIO-based MMC/SD support:
System Type->STM32 Peripheral Support
CONFIG_STM32_SDIO=y : Enable SDIO support
CONFIG_STM32_DMA2=y : DMA2 is needed by the driver
Device Drivers -> MMC/SD Driver Support
CONFIG_MMCSD=y : Enable MMC/SD support
CONFIG_MMSCD_NSLOTS=1 : One slot per driver instance
# CONFIG_MMCSD_HAVE_CARDDETECT is not set : No card-detect GPIO
# CONFIG_MMCSD_MMCSUPPORT is not set : Interferes with some SD cards
# CONFIG_MMCSD_SPI is not set : No SPI-based MMC/SD support
CONFIG_MMCSD_SDIO=y : SDIO-based MMC/SD support
CONFIG_MMCSD_MULTIBLOCK_LIMIT=1 : Disable to keep things simple
CONFIG_SDIO_DMA=y : Use SDIO DMA
# CONFIG_SDIO_BLOCKSETUP is not set : (not implemented)
Library Routines
CONFIG_SCHED_WORKQUEUE=y : Driver needs work queue support
Application Configuration -> NSH Library
CONFIG_NSH_ARCHINIT=y : NSH board-initialization
Using the SD card
-----------------
1. Since there is no CD GPIO pin, the firmware sill not know if there is
a card in the SD slot or not. It will assume that there is and attempt
to mount the SD card on power-up. If there is no SD card in the card
slot, there will be a long delay during initialization as the firmware
attempts to query the non-existent card, timeout, and retry.
2. After booting, an SDIO device will appear as /dev/mmcsd0
3. If you try mounting an SD card with nothing in the slot, the
mount will fail:
nsh> mount -t vfat /dev/mmcsd0 /mnt/sdcard
nsh: mount: mount failed: 19
STATUS:
-------
2017-01-28: There is no card communication. All commands to the SD card timeout.
OTGFS Host
==========
STM32 USB OTG FS Host Board Support
-----------------------------------
A USB-A-connector (host) is connected to the full speed STM32 inputs. These
are the pins supported by the STM32:
PIN SIGNAL DIRECTION
---- ----------- ----------
PA8 OTG_FS_SOF SOF clock output
PA9 OTG_FS_VBUS VBUS input for device, Driven by external regulator by
host (not an alternate function)
PA10 OTG_FS_ID OTG ID pin (only needed in Dual mode)
PA11 OTG_FS_DM D- I/O
PA12 OTG_FS_DP D+ I/O
These are the signals available on-board:
OTG_FS_VBUS Used host VBUS sensing (device input only)
OTG_FS_DM Data minus
OTG_FS_DP Dta plus
NOTE: PA10 is currently used for DCMI_D1. The USB OTGFS host will
configure this as the ID input.
VBUS power is provided via an LM3526 and driven by USB_FS_VBUSON:
USB_FS_VBUSON PC2 power on output to LM3526 #ENA
USB_FS_FAULT PB10 overcurrent input from LM3526 FLAG_A.
STM32 USB OTG FS Host Driver Configuration
------------------------------------------
Pre-requisites
CONFIG_USBDEV - Enable USB device support
CONFIG_USBHOST - Enable USB host support
CONFIG_STM32_OTGFS - Enable the STM32 USB OTG FS block
CONFIG_STM32_SYSCFG - Needed
CONFIG_SCHED_WORKQUEUE - Worker thread support is required
STM32 Options:
CONFIG_STM32_OTGFS_RXFIFO_SIZE - Size of the RX FIFO in 32-bit words.
Default 128 (512 bytes)
CONFIG_STM32_OTGFS_NPTXFIFO_SIZE - Size of the non-periodic Tx FIFO
in 32-bit words. Default 96 (384 bytes)
CONFIG_STM32_OTGFS_PTXFIFO_SIZE - Size of the periodic Tx FIFO in 32-bit
words. Default 96 (384 bytes)
CONFIG_STM32_OTGFS_DESCSIZE - Maximum size of a descriptor. Default: 128
CONFIG_STM32_OTGFS_SOFINTR - Enable SOF interrupts. Why would you ever
want to do that?
CONFIG_STM32_USBHOST_REGDEBUG - Enable very low-level register access
debug. Depends on CONFIG_DEBUG_FEATURES.
CONFIG_STM32_USBHOST_PKTDUMP - Dump all incoming and outgoing USB
packets. Depends on CONFIG_DEBUG_FEATURES.
Olimex STM32 P407 Configuration:
CONFIG_STM32F_OLIMEXP407_PRIO - Priority of the USB host watier
thread (default 100).
CONFIG_STM32_OLIMEXP407_STACKSIZE - Stacksize of the USB host
waiter thread (default 1024)
Class Driver Configuration
--------------------------
Individual class drivers have additional configuration requirements. The
USB mass storage class, for example, requires FAT file system support.
CONFIG_USBHOST_MSC=y
CONFIG_FS_FAT=y
CONFIG_FAT_LCNAMES=y
CONFIG_FAT_LFN=y
CONFIG_FAT_MAXFNAME=32
This will enable USB HID keyboard support:
CONFIG_USBHOST_HIDKBD=y
CONFIG_HIDKBD_BUFSIZE=64
CONFIG_HIDKBD_DEFPRIO=50
CONFIG_HIDKBD_POLLUSEC=100000
CONFIG_HIDKBD_STACKSIZE=1024
And this will enable the USB keyboard example:
CONFIG_EXAMPLES_HIDKBD=y
CONFIG_EXAMPLES_HIDKBD_DEFPRIO=50
CONFIG_EXAMPLES_HIDKBD_DEVNAME="/dev/kbda"
CONFIG_EXAMPLES_HIDKBD_STACKSIZE=1024
STATUS: The MSC configurations seems fully functional. The HIDKBD seems rather
flaky. Sometimes the LEDs become very bright (indicating that it is being
swamped with interrupts). Data input is not clean with apps/examples/hidkbd:
There are missing characters and sometimes duplicated characters. This implies
some logic issues, probably in drivers/usbhost/usbhost_hidkbd.c, with polling
and data filtering.
Protected Mode Build
====================
The "protected" mode build uses the Cormtex-M4 MPU to separate the FLASH and
SRAM into kernel-mode and user-mode regions. The kernel mode regions are
then protected from any errant or mischievous behavior from user-space
applications.
Common notes for all protected mode builds follow:
1. It is recommends to use a special make command; not just 'make' but make
with the following two arguments:
make pass1 pass2
In the normal case (just 'make'), make will attempt to build both user-
and kernel-mode blobs more or less interleaved. That actual works!
However, for me it is very confusing so I prefer the above make command:
Make the user-space binaries first (pass1), then make the kernel-space
binaries (pass2)
2. At the end of the build, there will be several files in the top-level
NuttX build directory:
PASS1:
nuttx_user.elf - The pass1 user-space ELF file
nuttx_user.hex - The pass1 Intel HEX format file (selected in defconfig)
User.map - Symbols in the user-space ELF file
PASS2:
nuttx - The pass2 kernel-space ELF file
nuttx.hex - The pass2 Intel HEX file (selected in defconfig)
System.map - Symbols in the kernel-space ELF file
The J-Link programmer will except files in .hex, .mot, .srec, and .bin
formats.
3. Combining .hex files. If you plan to use the .hex files with your
debugger or FLASH utility, then you may need to combine the two hex
files into a single .hex file. Here is how you can do that.
a. The 'tail' of the nuttx.hex file should look something like this
(with my comments added):
$ tail nuttx.hex
# 00, data records
...
:10 9DC0 00 01000000000800006400020100001F0004
:10 9DD0 00 3B005A0078009700B500D400F300110151
:08 9DE0 00 30014E016D0100008D
# 05, Start Linear Address Record
:04 0000 05 0800 0419 D2
# 01, End Of File record
:00 0000 01 FF
Use an editor such as vi to remove the 05 and 01 records.
b. The 'head' of the nuttx_user.hex file should look something like
this (again with my comments added):
$ head nuttx_user.hex
# 04, Extended Linear Address Record
:02 0000 04 0801 F1
# 00, data records
:10 8000 00 BD89 01084C800108C8110208D01102087E
:10 8010 00 0010 00201C1000201C1000203C16002026
:10 8020 00 4D80 01085D80010869800108ED83010829
...
Nothing needs to be done here. The nuttx_user.hex file should
be fine.
c. Combine the edited nuttx.hex and un-edited nuttx_user.hex
file to produce a single combined hex file:
$ cat nuttx.hex nuttx_user.hex >combined.hex
Then use the combined.hex file with the to write the FLASH image. With
GDB this would be:
gdb> mon reset
gdb> mon halt
gdb> mon clrbp
gdb> load combined.hex
If you do this a lot, you will probably want to invest a little time
to develop a tool to automate these steps.
Configurations
==============
Information Common to All Configurations
----------------------------------------
Each Olimex STM32-P407 configuration is maintained in a sub-directory and can be
selected as follow:
tools/configure.sh olimex-stm32-p407:<subdir>
Where <subdir> is one of the configuration sub-directories listed in the
following section.
Before building, make sure the PATH environment variable includes the
correct path to the directory than holds your toolchain binaries.
And then build NuttX by simply typing the following. At the conclusion of
the make, the nuttx binary will reside in an ELF file called, simply, nuttx.
make oldconfig
make
NOTES:
1. This configuration uses the mconf-based configuration tool. To
change this configurations using that tool, you should:
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
see additional README.txt files in the NuttX tools repository.
b. Execute 'make menuconfig' in nuttx/ in order to start the
reconfiguration process.
2. Serial Output
This configuraiont produces all of its test output on the serial
console. This configuration has USART3 enabled as a serial console.
This is the connector labeled RS232_2. This can easily be changed
by reconfiguring with 'make menuconfig'.
3. Toolchain
By default, the host platform is set to be Linux using the NuttX
buildroot toolchain. The host and/or toolchain selection can easily
be changed with 'make menuconfig'.
4. Note that CONFIG_STM32_DISABLE_IDLE_SLEEP_DURING_DEBUG is enabled so
that the JTAG connection is not disconnected by the idle loop.
Configuration sub-directories
-----------------------------
The <subdir> that is provided above as an argument to the tools/configure.sh
must be is one of the following.
dhtxx:
Configuration added by Abdelatif Guettouche for testing the the DHTxx
sensor. This configuration expects this setup:
DHTXX_PIN_OUTPUT PG9
DHTXX_PIN_INPUT PG9
The STM32 free-running timer is also required.
hidkbd
This is another NSH configuration that supports a USB HID Keyboard
device and the HID keyboard example at apps/examples/hidkbd.
STATUS:
2018-10-07: Not all keyboards will connect successfully. I have not
looked into the details but it may be that those keyboards are not
compatible with the driver (which only accepts "boot" keyboards).
Also, when typing input into the HID keyboard, characters are often
missing and sometimes duplicated. This is like some issue with the
read logic of drivers/usbhost_hidkbc.c.
kelf:
This is a protected mode version of the apps/examples/elf test of
loadable ELF programs. This version is unique because the ELF programs
are loaded into user space.
NOTES:
1. See build recommendations and instructions for combining the .hex
files under the section entitled "Protected Mode Build" above.
2. Unlike other versions of apps/examples/elf configurations, the test
ELF programs are not provided internally on a ROMFS or CROMFS file
system. This is due to the fact that those file systems are built in
user space and there is no mechanism in the build system to easily
get them into the kernel space.
Instead, the programs must be copied to a USB FLASH drive from your
host PC. The programs can be found at apps/examples/elf/tests/romfs.
All of those files should be copied to the USB FLASH drive. The
apps/example/elf will wait on power up until the USB FLASH drive
has been inserted and initialized.
kmodule:
This is a protected mode version of the apps/examples/module test of
loadable ELF kernel modules. This version is unique because the ELF
programs are loaded into the protected kernel space.
NOTES:
1. See build recommendations and instructions for combining the .hex
files under the section entitled "Protected Mode Build" above.
2. Unlike other versions of apps/examples/module configurations, the test
ELF modules are not provided internally on a ROMFS or CROMFS file
system. This is due to the fact that those file systems are built in
user space and there is no mechanism in the build system to easily
get them into the kernel space.
Instead, the module(s) must be copied to a USB FLASH drive from your
host PC. The module(s) can be found at apps/examples/module/driver/fsroot.
All of those file(s) should be copied to the USB FLASH drive. Like the
kelf configuration, the logic in apps/example/module will wait on power
up until the USB FLASH drive has been inserted and initialized.
STATUS:
2018-08-07: After some struggle, the configuration appears to be
working correctly.
knsh:
This is identical to the nsh configuration below except that NuttX
is built as a PROTECTED mode, monolithic module and the user applications
are built separately.
NOTES:
1. See build recommendations and instructions for combining the .hex
files under the section entitled "Protected Mode Build" above.
module:
A simple stripped down NSH configuration that was used for testing NuttX
OS modules using the test at apps/examples/module. Key difference from
the nsh configuration include these additions to the configuration file:
CONFIG_BOARDCTL_OS_SYMTAB=y
CONFIG_EXAMPLES_MODULE=y
CONFIG_EXAMPLES_MODULE_BUILTINFS=y
CONFIG_EXAMPLES_MODULE_DEVMINOR=0
CONFIG_EXAMPLES_MODULE_DEVPATH="/dev/ram0"
CONFIG_FS_ROMFS=y
CONFIG_LIBC_ARCH_ELF=y
CONFIG_MODULE=y
CONFIG_LIBC_MODLIB=y
CONFIG_MODLIB_MAXDEPEND=2
CONFIG_MODLIB_ALIGN_LOG2=2
CONFIG_MODLIB_BUFFERSIZE=128
CONFIG_MODLIB_BUFFERINCR=32
The could be followed may be added for testing shared libraries in the
FLAT build using apps/examples/sotest (assuming that you also have SD
card support enabled and that the SD card is mount at /mnt/sdcard):
CONFIG_LIBC_DLFCN=y
CONFIG_EXAMPLES_SOTEST=y
CONFIG_EXAMPLES_SOTEST_BINDIR="/mnt/sdcard"
NOTE: You must always have:
CONFIG_STM32_CCMEXCLUDE=y
because code cannot be executed from CCM memory.
STATUS:
2018-06-01: Configuration added. Works perfectly.
nsh:
This is the NuttShell (NSH) using the NSH startup logic at
apps/examples/nsh
NOTES:
1. USB host support for USB FLASH sticks is enabled. See the notes
above under "OTGFS Host".
STATUS: I have seen this work with some FLASH sticks but not with
others. I have not studied the failure case carefully. They seem
to fail because the request is NAKed. That is not a failure, however,
that is normal behavior when the FLASH is not ready.
There have been other cases like this with the STM32 host drivers:
in the event of NAKs, other drivers retry and wait for the data. The
STM32 does not but returns the NAK failure immediately. My guess is
that there needs to be be some retry logic to the driver 100%
reliable.
2. Kernel Modules / Shared Libraries
I used this configuration for testing NuttX kernel modules in the
FLAT build with the following configuration additions to the
configuration file:
CONFIG_BOARDCTL_OS_SYMTAB=y
CONFIG_EXAMPLES_MODULE=y
CONFIG_EXAMPLES_MODULE_BUILTINFS=y
CONFIG_EXAMPLES_MODULE_DEVMINOR=0
CONFIG_EXAMPLES_MODULE_DEVPATH="/dev/ram0"
CONFIG_FS_ROMFS=y
CONFIG_LIBC_ARCH_ELF=y
CONFIG_MODULE=y
CONFIG_LIBC_MODLIB=y
CONFIG_MODLIB_ALIGN_LOG2=2
CONFIG_MODLIB_BUFFERINCR=32
CONFIG_MODLIB_BUFFERSIZE=128
Add the following for testing shared libraries in the FLAT
build:
CONFIG_LIBC_DLFCN=y
CONFIG_EXAMPLES_SOTEST=y
CONFIG_EXAMPLES_SOTEST_BUILTINFS=y
CONFIG_EXAMPLES_SOTEST_DEVMINOR=1
CONFIG_EXAMPLES_SOTEST_DEVPATH="/dev/ram1"
zmodem:
This configuration was used to test the zmodem utilities at
apps/system/zmodem. Two serial ports are used in this configuration:
1. USART6 (RS232_1) is the serial console (because it does not support
hardware flow control). It is configured 115200 8N1.
2. USART3 (RS232_2) is the zmodem port and does require that hardware
flow control be enabled for use. It is configured 9600 8N1.
On the target these will correspond to /dev/ttyS0 and /dev/ttyS1,
respectively.
It is possible to configure a system without hardware flow control and
using the same USART for both the serial console and for zmodem.
However, you would have to take extreme care with buffering and data
throughput considerations to assure that there is no Rx data overrun.
General usage instructions:
1. Common Setup
[on target]
nsh> mount -t vfat /dev/sda /mnt
[on Linux host]
$ sudo stty -F /dev/ttyS0 9600
$ sudo stty -F /dev/ttyS0 crtscts *
$ sudo stty -F /dev/ttyS0 raw
$ sudo stty -F /dev/ttyS0
* Because hardware flow control will be enabled on the target side
in this configuration.
2. Host-to-Target File Transfer
[on target]
nsh> rz
[on host]
$ sudo sz <filename> [-l nnnn] </dev/ttyS0 >/dev/ttyS0
Where <filename> is the file that you want to transfer. If -l nnnn is
not specified, then there will likely be packet buffer overflow errors.
nnnn should be set to a strictly less than CONFIG_SYSTEM_ZMODEM_PKTBUFSIZE.
All testing was performed with -l 512.
If you are using the NuttX implementation of rz and sz on the Linux host,
then the last command simplifies to just:
[on host]
$ cp README.txt /tmp/.
$ sudo ./sz -d /dev/ttyS1 README.txt
Assuming that /dev/ttyS0 is the serial and /dev/ttyS1 is the zmodem port
on the Linux host as well. NOTE: By default, files will be transferred
to and from the /tmp directory only.
Refer to the README file at apps/examples/zmodem for detailed information
about building rz/sz for the host and about zmodem usage in general.
3. Target-to-Host File Transfer
[on host]
$ rz </dev/ttyS0 >/dev/ttyS0
The transferred file will end up in the current directory.
If you are using the NuttX implementation of rz and sz on the Linux host,
then the last command simplifies to just:
[on host]
$ ./rz
The transferred file will lie in the /tmp directory.
Then on the target side:
[on target]
nsh sz <filename>
Where <filename> is the file that you want to transfer.
STATUS
======
2016-12-21: This board configuration was ported from the Olimex STM32 P207
port. Note that none of the above features have been verified. USB, CAN,
ADC, and Ethernet are disabled in the base NSH configuration until they
can be verified. These features should be functional but may required
some tweaks due to the different clock configurations. The Olimex STM32
P207 nsh/defconfig would be a good starting place for restoring these
feature configurations.
CCM memory is not included in the heap (CONFIG_STM32_CCMEXCLUDE=y) because
it does not support DMA, leaving only 128KiB for program usage.
2017-01-23: Added the knsh configuration and support for the PROTECTED
build mode.
2018-05-27: Added the zmodem configuration. Verified correct operation
with host-to-target transfers (using Linux sz command). There appears
to be a problem using the NuttX sz command running on the host???
2018-05-28: Verified correct operation with target-to-host transfers (using
Linux rz command). There appears to be a problem using the NuttX rz
command running on the host???
2018-06-01: Added the module configuration. Works perfectly.

80
boards/arm/stm32/omnibusf4/README.txt
View File

@ -1,80 +0,0 @@
OMNIBUSF4 Target Support README
===============================
"OmnibusF4" is not a product name per se, but rather a design spec
that many product vendors within the drone flight management unit
(FMU) community adhere to. The spec defines the major components, and
how those components are wired into the STM32F405RGT6 microcontroller.
Airbot is one such vendor, and they publish a schematic here:
http://bit.ly/obf4pro
Other software that supports the OmnibusF4 family include Betaflight,
iNAV, and many others. PX4 recently added support as well. No code
from any of those sources is included in this port.
Since OmnibusF4 is a drone FMU, most of its IO is already allocated to
FMU-specific tasks. As such, we don't need to make the board support
package as flexible as, say, an STM32F4 Discovery board.
The following are some of the committed IO pins. Most of the pins not
mentioned here are inaccessible, the details vary by board vendor:
io peripheral signal notes
==================================
XIN 8MHz crystal oscillator
PB0 TIM3 CH3 S1_OUT motor 1 PWM output
PB1 TIM3 CH4 S2_OUT motor 2 PWM output
PA3 TIM2 CH4 S3_OUT motor 3 PWM output
PA2 TIM2 CH3 S4_OUT motor 4 PWM output
PA1 TIM2 CH2 S5_OUT motor 5 PWM output
PA8 TIM1 CH4 S6_OUT motor 6 PWM output
PA4 SPI1 SPI1_NSS mpu6000
PA5 SPI1 SPI1_SCL
PA6 SPI1 SPI1_MISO
PA7 SPI1 SPI1_MOSI
PC4 GPIO GYRO_INT mpu6000 EXTI
PB10 UART3/I2C UART3_TX ttl UART tx or i2c_scl (used as console)
PB11 UART3/I2C UART3_RX ttl UART rx or i2c_sda (used as console)
PB9 RC_CH2 (rx pwm input)
PB8 RC_CH1 (rx pwm input)
PC9 RC_CH6 (rx pwm input)
PC8 RC_CH5 (rx pwm input)
PC7 RC_CH4 or USART6_RX (ttl)
PC6 RC_CH3 or USART6_TX (ttl)
PB7 GPIO SD_DET SD card detection pin (low when card inserted)
PB5 GPIO STAT LED output (active low)
PB4 GPIO BUZZER buzzer output (active low)
PD2 GPIO LED_STRIP one-wire interface for LED strips
PC12 SPI3 SPI3_MOSI bmp280 barometer (if populated) and/or max7456 OSD
PC11 SPI3 SPI3_MISO
PC10 SPI3 SPI3_SCL
PA15 GPIO SPI3_NSS OSD NSS
PB3 GPIO BARO_CS bmp280 NSS (if populated)
PA12 OTG USB_DP
PA11 OTG USB_DN
PA10 UART1 USART1_RX SBUS_IN (through inverter) or PPM
PA9 UART1 USART1_TX
PB15 SPI2 SPI2_MOSI sd/mmc card interface
PB14 SPI2 SPI2_MISO
PB13 SPI2 SPI2_SCLK
PB12 SPI2 SPI2_NSS
Build Instructions
==================
The boards/arm/stm32/omnibusf4/nsh/defconfig file creates a basic setup, and
includes drivers for all supported onboard chips. The console and
command prompt are sent to USART3.

1217
boards/arm/stm32/stm3240g-eval/README.txt
View File

File diff suppressed because it is too large Load Diff

1004
boards/arm/stm32/stm32f429i-disco/README.txt
View File

File diff suppressed because it is too large Load Diff

105
boards/arm/stm32/stm32f429i-disco/configs/fb/README.txt
View File

@ -1,105 +0,0 @@
README.txt
==========
STM32F429I-DISCO LTDC Framebuffer demo example
Configure and build
-------------------
cd tools
./configure -a <appdir> stm32f429i-disco/fb
cd ..
make
Framebuffer calculation
----------------------
Use the helper script boards/stm32f429i-disco/tools/fbcalc.sh for calculating
the heap2 and framebuffer memory region. The script assumes that all overlay
buffers (LTDC and DMA2D) located in heap2 memory region starting at address
0xD0000000. When changing the display size (when using a custom display), DMA2D
overlay size or the pixel format you have to recalculate the heap2 settings.
In this configuration all overlays (LTDC and DMA2D) positioned at the end of
heap2.
LTDC hardware acceleration
--------------------------
The LTDC driver provides two 2 LTDC overlays and supports the following hardware
acceleration and features:
Configured at build time
- background color
- default color (outside visible screen)
Configurable by nuttx framebuffer interface
- cmap support (color table is shared by both LTDC overlays and DMA2D when
enabled)
Configurable via the nuttx framebuffer interface (for each layer separately)
- chromakey
- transparency (const alpha and pixel alpha)
- blank
- color (if DMA2D is enabled and cmap is disabled)
- blit (if DMA2D is enabled)
- blend (if DMA2D is enabled and cmap is disabled)
LTDC overlays are similar to a non-destructive overlay. Both LTDC overlays will
be permanently blended in the order (background -> overlay 0 -> overlay 1) and
converted to a resulting video signal by the LTDC controller. That means each
operation with a LTDC overlay (Overlay 0 and Overlay 1) via nuttx framebuffer
interface will be visible immediately.
Think about continuous blending between both overlays.
DMA2D hardware acceleration
---------------------------
The DMA2D driver implements the following hardware acceleration:
Configurable via the nuttx framebuffer interface
- cmap support (color table is shared by all DMA2D overlays and LTDC overlays)
Configurable via the nuttx framebuffer interface (for each layer separately)
- color (fill memory region with a specific ARGB8888 color immediately), if
cmap is disabled
- blit (copy memory region to another memory region with pixel format
conversion if necessary)
- blend (blend two memory regions and copy the result to a third memory region
with pixel format conversion if necessary), if cmap is disabled
Blit and blend operation using a fixes memory size defined by the background
layer. DMA2D controller doesn't support scaling.
DMA2D overlays are similar to destructive overlays. They are invisible. They can
be used for image preprocessing. The memory region affected by the operations
(color, blit, blend) can be addressed by the area control command before. The
configured overlay transparency of DMA2D overlays will be used for subsequently
blend operation and is valid for the whole overlay.
Configuration
------------
This configuration provides 2 LTDC (visible overlays) and 2 DMA2D overlays with
pixel format RGB565 and a resolution of 240x320.
Loading
-------
st-flash write nuttx.bin 0x8000000
Executing
---------
The ltdc is initialized during boot up. Interaction with NSH is via the serial
console at 115200 8N1 baud. From the nsh comandline execute the fb example:
nsh> fb
The test will put a pattern of concentric squares in the framebuffer and
terminate.
You can also test overlay hardware acceleration functionality by executing the
following command (shows a commandline help):
nsh> fboverlay

2427
boards/arm/stm32/stm32f4discovery/README.txt
View File

File diff suppressed because it is too large Load Diff

75
boards/arm/stm32wl5/nucleo-wl55jc/README.txt
View File

@ -1,75 +0,0 @@
Nucleo-WL55JC README
====================
This README file discusses the port of NuttX to the STMicro Nucleo-WL55JC
board. That board features the STM32WL55JCI7 MCU with 256KiB of FLASH and
64KiB of SRAM. This is dual CPU (not core) chip. There is integrated LORA
hardware on board which is only available via CPU0.
Contents
========
- Status
- LEDs
- Buttons
- Serial Console
- Configurations
- Flashing
Status
======
2022.06.07: Board boots and nsh works without problems. Both arduino and
virtual com port UARTs work.
LEDs
====
There are user controlled 3 LEDs. Blue (PB15), Green(PB9) and Red(PB11).
To turn on the LED, GPIO has to be driven to HIGH state.
Green and Red LEDs are used by the system at boot to show system state.
Once system is booted these LEDs are for user to control. When
CONFIG_ARCH_LEDS is set, Blue LED is reserved by OS for reporting system
status. When CONFIG_ARCH_LEDS is not set, OS state won't be reported on
any of the LEDs and all 3 LEDs are available for user right from the start.
Buttons
=======
There are 3 buttons that are available for the user to program, and one
reset button.
Serial Console
==============
There are 2 serial ports - USART1 and LPUART1.
USART1 is connected to arduino D0/D1 pin and LPUART is connected to
stlink that provides virtual serial port.
NSH is configured to use LPUART and virtual serial port. After flashing
you can open /dev/ttyACM0 (may change depending on your system) and nsh
prompt will be waiting for you there. Serial device does not disappear
when flashing and resetting board - it can be left opened and flashing
will work without problems.
Configuration
=============
Configuration sub-directories
-----------------------------
nsh:
Configures the NuttShell (nsh) located at examples/nsh. NSH is will
work on virtual serial port over usb.
Flashing
========
Easiest way to flash nucleo is to use openocd tool. Openocd supports
stlink v3 which is on the board. It's as easy as running:
openocd -f interface/stlink.cfg -f target/stm32wlx.cfg \
-c "program nuttx.bin exit 0x08000000"