From 00db279c00cb5e435b83b4f2c626295d2587bb47 Mon Sep 17 00:00:00 2001
From: raiden00pl <raiden00@railab.me>
Date: Wed, 23 Aug 2023 10:22:31 +0200
Subject: [PATCH] Documentation: migrate STM32F4
---
.../arm/stm32f4/boards/axoloti/index.rst | 5 +-
.../stm32f4/boards/clicker2-stm32/index.rst | 543 ++--
.../stm32f4/boards/mikroe-stm32f4/index.rst | 372 +++
.../stm32f4/boards/nucleo-f401re/index.rst | 394 +++
.../stm32f4/boards/nucleo-f410rb/index.rst | 223 ++
.../stm32f4/boards/nucleo-f411re/index.rst | 394 +++
.../stm32f4/boards/nucleo-f412zg/index.rst | 222 ++
.../stm32f4/boards/nucleo-f429zi/index.rst | 3 +
.../stm32f4/boards/nucleo-f446re/index.rst | 494 ++++
.../boards/olimex-stm32-e407/index.rst | 210 ++
.../boards/olimex-stm32-h405/index.rst | 18 +-
.../boards/olimex-stm32-h407/index.rst | 15 +-
.../boards/olimex-stm32-p407/index.rst | 574 ++++
.../arm/stm32f4/boards/omnibusf4/index.rst | 82 +
.../stm32f4/boards/stm3240g-eval/index.rst | 842 ++++++
.../boards/stm32f411-minimum/index.rst | 90 +-
.../stm32f4/boards/stm32f411e-disco/index.rst | 5 +-
.../stm32f4/boards/stm32f429i-disco/index.rst | 749 +++++
.../stm32f4/boards/stm32f4discovery/index.rst | 2182 +++++++++++++++
Documentation/platforms/arm/stm32f4/index.rst | 536 ++++
.../platforms/arm/stm32wl5/index.rst | 6 +-
boards/arm/stm32/mikroe-stm32f4/README.txt | 659 -----
boards/arm/stm32/nucleo-f410rb/README.txt | 250 --
boards/arm/stm32/nucleo-f412zg/README.txt | 253 --
boards/arm/stm32/nucleo-f446re/README.txt | 662 -----
boards/arm/stm32/nucleo-f4x1re/README.txt | 580 ----
boards/arm/stm32/olimex-stm32-e407/README.txt | 196 --
boards/arm/stm32/olimex-stm32-p407/README.txt | 655 -----
boards/arm/stm32/omnibusf4/README.txt | 80 -
boards/arm/stm32/stm3240g-eval/README.txt | 1217 ---------
boards/arm/stm32/stm32f429i-disco/README.txt | 1004 -------
.../stm32f429i-disco/configs/fb/README.txt | 105 -
boards/arm/stm32/stm32f4discovery/README.txt | 2427 -----------------
boards/arm/stm32wl5/nucleo-wl55jc/README.txt | 75 -
34 files changed, 7626 insertions(+), 8496 deletions(-)
rename boards/arm/stm32/axoloti/README.txt => Documentation/platforms/arm/stm32f4/boards/axoloti/index.rst (96%)
rename boards/arm/stm32/clicker2-stm32/README.txt => Documentation/platforms/arm/stm32f4/boards/clicker2-stm32/index.rst (52%)
create mode 100644 Documentation/platforms/arm/stm32f4/boards/mikroe-stm32f4/index.rst
create mode 100644 Documentation/platforms/arm/stm32f4/boards/nucleo-f401re/index.rst
create mode 100644 Documentation/platforms/arm/stm32f4/boards/nucleo-f410rb/index.rst
create mode 100644 Documentation/platforms/arm/stm32f4/boards/nucleo-f411re/index.rst
create mode 100644 Documentation/platforms/arm/stm32f4/boards/nucleo-f412zg/index.rst
create mode 100644 Documentation/platforms/arm/stm32f4/boards/nucleo-f429zi/index.rst
create mode 100644 Documentation/platforms/arm/stm32f4/boards/nucleo-f446re/index.rst
create mode 100644 Documentation/platforms/arm/stm32f4/boards/olimex-stm32-e407/index.rst
rename boards/arm/stm32/olimex-stm32-h405/README.txt => Documentation/platforms/arm/stm32f4/boards/olimex-stm32-h405/index.rst (58%)
rename boards/arm/stm32/olimex-stm32-h407/README.txt => Documentation/platforms/arm/stm32f4/boards/olimex-stm32-h407/index.rst (70%)
create mode 100644 Documentation/platforms/arm/stm32f4/boards/olimex-stm32-p407/index.rst
create mode 100644 Documentation/platforms/arm/stm32f4/boards/omnibusf4/index.rst
create mode 100644 Documentation/platforms/arm/stm32f4/boards/stm3240g-eval/index.rst
rename boards/arm/stm32/stm32f411-minimum/README.txt => Documentation/platforms/arm/stm32f4/boards/stm32f411-minimum/index.rst (65%)
rename boards/arm/stm32/stm32f411e-disco/README.txt => Documentation/platforms/arm/stm32f4/boards/stm32f411e-disco/index.rst (79%)
create mode 100644 Documentation/platforms/arm/stm32f4/boards/stm32f429i-disco/index.rst
create mode 100644 Documentation/platforms/arm/stm32f4/boards/stm32f4discovery/index.rst
create mode 100644 Documentation/platforms/arm/stm32f4/index.rst
delete mode 100644 boards/arm/stm32/mikroe-stm32f4/README.txt
delete mode 100644 boards/arm/stm32/nucleo-f410rb/README.txt
delete mode 100644 boards/arm/stm32/nucleo-f412zg/README.txt
delete mode 100644 boards/arm/stm32/nucleo-f446re/README.txt
delete mode 100644 boards/arm/stm32/nucleo-f4x1re/README.txt
delete mode 100644 boards/arm/stm32/olimex-stm32-e407/README.txt
delete mode 100644 boards/arm/stm32/olimex-stm32-p407/README.txt
delete mode 100644 boards/arm/stm32/omnibusf4/README.txt
delete mode 100644 boards/arm/stm32/stm3240g-eval/README.txt
delete mode 100644 boards/arm/stm32/stm32f429i-disco/README.txt
delete mode 100644 boards/arm/stm32/stm32f429i-disco/configs/fb/README.txt
delete mode 100644 boards/arm/stm32/stm32f4discovery/README.txt
delete mode 100644 boards/arm/stm32wl5/nucleo-wl55jc/README.txt
diff --git a/boards/arm/stm32/axoloti/README.txt b/Documentation/platforms/arm/stm32f4/boards/axoloti/index.rst
similarity index 96%
rename from boards/arm/stm32/axoloti/README.txt
rename to Documentation/platforms/arm/stm32f4/boards/axoloti/index.rst
index ee0bc92251..07df510e52 100644
--- a/boards/arm/stm32/axoloti/README.txt
+++ b/Documentation/platforms/arm/stm32f4/boards/axoloti/index.rst
@@ -1,5 +1,6 @@
-README
-======
+=======
+Axoloti
+=======
This README discusses issues unique to NuttX configurations for the
Axoloti open source synthesizer board featuring the STM32F427IGH6
diff --git a/boards/arm/stm32/clicker2-stm32/README.txt b/Documentation/platforms/arm/stm32f4/boards/clicker2-stm32/index.rst
similarity index 52%
rename from boards/arm/stm32/clicker2-stm32/README.txt
rename to Documentation/platforms/arm/stm32f4/boards/clicker2-stm32/index.rst
index 9c50830929..507687caed 100644
--- a/boards/arm/stm32/clicker2-stm32/README.txt
+++ b/Documentation/platforms/arm/stm32f4/boards/clicker2-stm32/index.rst
@@ -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
diff --git a/Documentation/platforms/arm/stm32f4/boards/mikroe-stm32f4/index.rst b/Documentation/platforms/arm/stm32f4/boards/mikroe-stm32f4/index.rst
new file mode 100644
index 0000000000..6686c6b300
--- /dev/null
+++ b/Documentation/platforms/arm/stm32f4/boards/mikroe-stm32f4/index.rst
@@ -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
diff --git a/Documentation/platforms/arm/stm32f4/boards/nucleo-f401re/index.rst b/Documentation/platforms/arm/stm32f4/boards/nucleo-f401re/index.rst
new file mode 100644
index 0000000000..9bfbbdc589
--- /dev/null
+++ b/Documentation/platforms/arm/stm32f4/boards/nucleo-f401re/index.rst
@@ -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.
diff --git a/Documentation/platforms/arm/stm32f4/boards/nucleo-f410rb/index.rst b/Documentation/platforms/arm/stm32f4/boards/nucleo-f410rb/index.rst
new file mode 100644
index 0000000000..29db291d43
--- /dev/null
+++ b/Documentation/platforms/arm/stm32f4/boards/nucleo-f410rb/index.rst
@@ -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.
diff --git a/Documentation/platforms/arm/stm32f4/boards/nucleo-f411re/index.rst b/Documentation/platforms/arm/stm32f4/boards/nucleo-f411re/index.rst
new file mode 100644
index 0000000000..f428a1ae4e
--- /dev/null
+++ b/Documentation/platforms/arm/stm32f4/boards/nucleo-f411re/index.rst
@@ -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.
diff --git a/Documentation/platforms/arm/stm32f4/boards/nucleo-f412zg/index.rst b/Documentation/platforms/arm/stm32f4/boards/nucleo-f412zg/index.rst
new file mode 100644
index 0000000000..cbad2e3d64
--- /dev/null
+++ b/Documentation/platforms/arm/stm32f4/boards/nucleo-f412zg/index.rst
@@ -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.
diff --git a/Documentation/platforms/arm/stm32f4/boards/nucleo-f429zi/index.rst b/Documentation/platforms/arm/stm32f4/boards/nucleo-f429zi/index.rst
new file mode 100644
index 0000000000..1f9d506965
--- /dev/null
+++ b/Documentation/platforms/arm/stm32f4/boards/nucleo-f429zi/index.rst
@@ -0,0 +1,3 @@
+================
+ST Nucleo F429ZI
+================
diff --git a/Documentation/platforms/arm/stm32f4/boards/nucleo-f446re/index.rst b/Documentation/platforms/arm/stm32f4/boards/nucleo-f446re/index.rst
new file mode 100644
index 0000000000..bc9a19bd13
--- /dev/null
+++ b/Documentation/platforms/arm/stm32f4/boards/nucleo-f446re/index.rst
@@ -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.
diff --git a/Documentation/platforms/arm/stm32f4/boards/olimex-stm32-e407/index.rst b/Documentation/platforms/arm/stm32f4/boards/olimex-stm32-e407/index.rst
new file mode 100644
index 0000000000..90a523154f
--- /dev/null
+++ b/Documentation/platforms/arm/stm32f4/boards/olimex-stm32-e407/index.rst
@@ -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.
diff --git a/boards/arm/stm32/olimex-stm32-h405/README.txt b/Documentation/platforms/arm/stm32f4/boards/olimex-stm32-h405/index.rst
similarity index 58%
rename from boards/arm/stm32/olimex-stm32-h405/README.txt
rename to Documentation/platforms/arm/stm32f4/boards/olimex-stm32-h405/index.rst
index efd6190da5..d5f486e754 100644
--- a/boards/arm/stm32/olimex-stm32-h405/README.txt
+++ b/Documentation/platforms/arm/stm32f4/boards/olimex-stm32-h405/index.rst
@@ -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.
diff --git a/boards/arm/stm32/olimex-stm32-h407/README.txt b/Documentation/platforms/arm/stm32f4/boards/olimex-stm32-h407/index.rst
similarity index 70%
rename from boards/arm/stm32/olimex-stm32-h407/README.txt
rename to Documentation/platforms/arm/stm32f4/boards/olimex-stm32-h407/index.rst
index 38e562d755..a68ab26a1c 100644
--- a/boards/arm/stm32/olimex-stm32-h407/README.txt
+++ b/Documentation/platforms/arm/stm32f4/boards/olimex-stm32-h407/index.rst
@@ -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
-===============================================
diff --git a/Documentation/platforms/arm/stm32f4/boards/olimex-stm32-p407/index.rst b/Documentation/platforms/arm/stm32f4/boards/olimex-stm32-p407/index.rst
new file mode 100644
index 0000000000..a4771651bb
--- /dev/null
+++ b/Documentation/platforms/arm/stm32f4/boards/olimex-stm32-p407/index.rst
@@ -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.
diff --git a/Documentation/platforms/arm/stm32f4/boards/omnibusf4/index.rst b/Documentation/platforms/arm/stm32f4/boards/omnibusf4/index.rst
new file mode 100644
index 0000000000..46c37b248a
--- /dev/null
+++ b/Documentation/platforms/arm/stm32f4/boards/omnibusf4/index.rst
@@ -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.
diff --git a/Documentation/platforms/arm/stm32f4/boards/stm3240g-eval/index.rst b/Documentation/platforms/arm/stm32f4/boards/stm3240g-eval/index.rst
new file mode 100644
index 0000000000..e7c9fc5389
--- /dev/null
+++ b/Documentation/platforms/arm/stm32f4/boards/stm3240g-eval/index.rst
@@ -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.
diff --git a/boards/arm/stm32/stm32f411-minimum/README.txt b/Documentation/platforms/arm/stm32f4/boards/stm32f411-minimum/index.rst
similarity index 65%
rename from boards/arm/stm32/stm32f411-minimum/README.txt
rename to Documentation/platforms/arm/stm32f4/boards/stm32f411-minimum/index.rst
index d7b9729d22..00f17cee80 100644
--- a/boards/arm/stm32/stm32f411-minimum/README.txt
+++ b/Documentation/platforms/arm/stm32f4/boards/stm32f411-minimum/index.rst
@@ -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.
diff --git a/boards/arm/stm32/stm32f411e-disco/README.txt b/Documentation/platforms/arm/stm32f4/boards/stm32f411e-disco/index.rst
similarity index 79%
rename from boards/arm/stm32/stm32f411e-disco/README.txt
rename to Documentation/platforms/arm/stm32f4/boards/stm32f411e-disco/index.rst
index 6cf2090b77..f3d473f10c 100644
--- a/boards/arm/stm32/stm32f411e-disco/README.txt
+++ b/Documentation/platforms/arm/stm32f4/boards/stm32f411e-disco/index.rst
@@ -1,5 +1,6 @@
-README
-======
+=======================
+ST STM32F411E-Discovery
+=======================
This README discusses issues unique to NuttX configurations for the STMicro
STM32F411E-Discovery board. See
diff --git a/Documentation/platforms/arm/stm32f4/boards/stm32f429i-disco/index.rst b/Documentation/platforms/arm/stm32f4/boards/stm32f429i-disco/index.rst
new file mode 100644
index 0000000000..0157443911
--- /dev/null
+++ b/Documentation/platforms/arm/stm32f4/boards/stm32f429i-disco/index.rst
@@ -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
diff --git a/Documentation/platforms/arm/stm32f4/boards/stm32f4discovery/index.rst b/Documentation/platforms/arm/stm32f4/boards/stm32f4discovery/index.rst
new file mode 100644
index 0000000000..58a39f26e6
--- /dev/null
+++ b/Documentation/platforms/arm/stm32f4/boards/stm32f4discovery/index.rst
@@ -0,0 +1,2182 @@
+====================
+ST STM32F4-Discovery
+====================
+
+This page discusses issues unique to NuttX configurations for the
+STMicro STM32F4Discovery development board featuring the STM32F407VGT6
+MCU. The STM32F407VGT6 is a 168MHz Cortex-M4 operation with 1Mbit Flash
+memory and 128kbytes. The board features:
+
+- On-board ST-LINK/V2 for programming and debugging,
+- LIS302DL, ST MEMS motion sensor, 3-axis digital output accelerometer,
+- MP45DT02, ST MEMS audio sensor, omni-directional digital microphone,
+- CS43L22, audio DAC with integrated class D speaker driver,
+- Four user LEDs and two push-buttons,
+- USB OTG FS with micro-AB connector, and
+- Easy access to most MCU pins.
+
+Refer to http://www.st.com/internet/evalboard/product/252419.jsp for
+further information about this board.
+
+NOTE: This port was developed on the original board, order code
+STM32F4DISCOVERY. That board has been replaced with the new order code
+STM32F407VG-DISC1. The new version of the board differs in at least these
+ways:
+
+- The ST-LINK/V2 has been updated to ST-LINK/V2-A on STM32F407G-DISC1
+ with a Virtual Com port and Mass storage.
+- LIS3DSH ST MEMS 3-axis accelerometer
+
+LEDs
+====
+
+The STM32F4Discovery board has four LEDs; green, orange, red and blue 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
+ green orange red blue
+ =================== ======================= ======= ======= ======= ======
+ 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
+ =================== ======================= ======= ======= ======= ======
+
+[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.
+
+RGB LED Driver
+==============
+
+Alan Carvalho de Assis has used the STM32F4-Discovery to drive an RGB LED
+using PWM output. The external RGB connected this way::
+
+ R = TIM1 CH1 on PE9
+ G = TIM2 CH2 on PA1
+ B = TIM3 CH3 on PB0
+
+The RGB LED driver that uses PWM to control the red, green, and blue color
+components can be enabled with the following configuration settings::
+
+ +CONFIG_RGBLED=y
+
+ +CONFIG_PWM
+
+ +CONFIG_STM32_TIM1
+ +CONFIG_STM32_TIM2
+ +CONFIG_STM32_TIM3
+ +CONFIG_STM32_TIM1_PWM=y
+ +CONFIG_STM32_TIM1_MODE=0
+ +CONFIG_STM32_TIM1_CHANNEL=1
+ +CONFIG_STM32_TIM1_CHMODE=0
+ +CONFIG_STM32_TIM2_PWM=y
+ +CONFIG_STM32_TIM2_MODE=0
+ +CONFIG_STM32_TIM2_CHANNEL=2
+ +CONFIG_STM32_TIM2_CHMODE=0
+ +CONFIG_STM32_TIM3_PWM=y
+ +CONFIG_STM32_TIM3_MODE=0
+ +CONFIG_STM32_TIM3_CHANNEL=3
+ +CONFIG_STM32_TIM3_CHMODE=0
+
+PWM
+===
+
+The STM32F4Discovery has no real on-board PWM devices, but the board can be
+configured to output a pulse train using TIM4 CH2 on PD3. This pin is
+available next to the audio jack.
+
+UARTs
+=====
+
+UART/USART PINS
+---------------
+
+USART1
+------
+
+ ======== ================
+ Function Pin
+ ======== ================
+ CK PA8
+ CTS PA11*
+ RTS PA12*
+ RX PA10*, PB7
+ TX PA9*, PB6*
+ ======== ================
+
+USART2
+------
+
+ ======== ================
+ Function Pin
+ ======== ================
+ CK PA4*, PD7
+ CTS PA0*, PD3
+ RTS PA1, PD4*
+ RX PA3, PD6
+ TX PA2, PD5*
+ ======== ================
+
+USART3
+------
+
+ ======== ================
+ Function Pin
+ ======== ================
+ CK PB12, PC12*, PD10
+ CTS PB13, PD11
+ RTS PB14, PD12*
+ RX PB11, PC11, PD9
+ TX PB10*, PC10*, PD8
+ ======== ================
+
+UART4
+------
+
+ ======== ================
+ Function Pin
+ ======== ================
+ RX PA1, PC11
+ TX PA0*, PC10*
+ ======== ================
+
+UART5
+------
+
+ ======== ================
+ Function Pin
+ ======== ================
+ RX PD2
+ TX PC12*
+ ======== ================
+
+USART6
+------
+
+ ======== ================
+ Function Pin
+ ======== ================
+ CK PC8, PG7[2]
+ CTS PG13[2], PG15[2]
+ RTS PG12[2], PG8[]
+ RX PC7[1], PG9[2]
+ TX PC6, PG14[2]
+ ======== ================
+
+[1] Indicates pins that have other on-board functions and should be used only
+with care (See table 5 in the STM32F4Discovery User Guide). The rest are
+free I/O pins.
+
+[2] Port G pins are not supported by the MCU
+
+Default USART/UART Configuration
+--------------------------------
+
+USART2 is enabled in most configurations (see \*/defconfig). RX and TX are
+configured on pins PA3 and PA2, respectively (see include/board.h).
+
+These pins selections, however, conflict with Ethernet pin usage on the
+STM32F4DIS-BB base board. The STM32F4DIS-BB base board provides RS-232
+drivers and a DB9 connector for USART6. USART6 is the preferred serial
+console for use with the STM32F4DIS-BB.
+
+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 STM32F4Discovery User Guide). The rest are
+ free I/O pins.
+ [2] Port H pins are not supported by the MCU
+
+Nintendo Wii Nunchuck
+=====================
+
+There is a driver on NuttX to support Nintendo Wii Nunchuck Joystick. If you
+want to use it please select these options:
+
+- Enable the I2C1 at System Type -> STM32 Peripheral Support, it will enable::
+
+ CONFIG_STM32_I2C1=y
+
+- Enable to Custom board/driver initialization at RTOS Features -> RTOS hooks::
+
+ CONFIG_BOARD_LATE_INITIALIZE=y
+
+- Enable the I2C Driver Support at Device Drivers, it will enable this symbol::
+
+ CONFIG_I2C=y
+
+- Nintendo Wii Nunchuck Joystick at Device Drivers -> [*] Input Device Support::
+
+ CONFIG_INPUT=y
+ CONFIG_INPUT_NUNCHUCK=y
+
+- Enable the Nunchuck joystick example at Application Configuration -> Examples::
+
+ CONFIG_EXAMPLES_NUNCHUCK=y
+ CONFIG_EXAMPLES_NUNCHUCK_DEVNAME="/dev/nunchuck0"
+
+You need to connect GND and +3.3V pins from Nunchuck connector to GND and 3V
+of stm32f4discovery respectively (Nunchuck also can work connected to 5V, but
+I don't recommend it). Connect I2C Clock from Nunchuck to SCK (PB6) and the
+I2C Data to SDA (PB9).
+
+Quadrature Encoder:
+===================
+
+The nsh configuration has been used to test the Quadrture Encoder
+(QEncoder, QE) with the following modifications to the configuration
+file:
+
+- These setting enable support for the common QEncode upper half driver::
+
+ CONFIG_BOARD_LATE_INITIALIZE=y
+
+ CONFIG_SENSORS=y
+ CONFIG_SENSORS_QENCODER=y
+
+- The timer 2 needs to be enabled::
+
+ CONFIG_STM32_TIM2=y
+
+- This is a board setting that selected timer 2 for use with the
+ quadrature encode::
+
+ CONFIG_STM32F4DISCO_QETIMER=2
+
+- These settings enable the STM32 Quadrature encoder on timer 2::
+
+ CONFIG_STM32_TIM2_QE=y
+ CONFIG_STM32_TIM4_QECLKOUT=2800000
+ CONFIG_STM32_QENCODER_FILTER=y
+ CONFIG_STM32_QENCODER_SAMPLE_EVENT_6=y
+ CONFIG_STM32_QENCODER_SAMPLE_FDTS_4=y
+
+- These settings enable the test case at apps/examples/qencoder::
+
+ CONFIG_EXAMPLES_QENCODER=y
+ CONFIG_EXAMPLES_QENCODER_DELAY=100
+ CONFIG_EXAMPLES_QENCODER_DEVPATH="/dev/qe0"
+
+In this configuration, the QEncoder inputs will be on the TIM2 inputs of
+PA15 and PA1 (CH1 and CH2 respectively).
+
+You can also use QEncoder with other timers, but keep in mind that only TIM2
+and TIM5 are 32bits timers, all other timers are 16-bit then the QE counter
+will overflow after 65535.
+
+If TIM4 is selected, then PB6 and PB7 will be used for CH1 and CH2.
+If TIM8 is selected, then PC6 and PI5 will be used for CH1 and CH2.
+
+STM32F4DIS-BB
+=============
+
+..
+ On-board PIO usage:
+
+ ---------- ------------- ------------------------------
+ PIO SIGNAL FUNCTION
+ ---------- ------------- ------------------------------
+ PB11 TXEN LAN8720
+ PB12 TXD0
+ PB13 TXD1
+ PC4 RXD0/MODE0
+ PC5 RXD1/MODE1
+ PA7 RXDR/PHYAD0
+ PA2 MDIO
+ PC1 MDC
+ PA1 NINT/REFCLK0
+ PE2 NRST
+ ---------- ------------- ------------------------------
+ PC6 D2 DCMI
+ PC7 D3
+ PE0 D4
+ PE1 D5
+ PE4 D6
+ PB6 D7
+ PE5 D8
+ PE6 D9
+ PA6 PCLK
+ PA4 HS
+ PB7 VS
+ PD6 PWR_EN
+ PD12 RST
+ PB9 SDA
+ PB8 SCL
+ ---------- ------------- ------------------------------
+ USART6_TX T1IN SP3232EEY-L
+ USART6_RX T2OUT
+ ---------- ------------- ------------------------------
+ PB15 NCD MicroSD
+ PC9 DAT1
+ PC8 DAT0
+ PC12 CLK
+ PD2 CMD
+ PC11 CD/DAT3
+ PC10 DAT2
+ ---------- ------------- ------------------------------
+
+RTC DS1307
+==========
+
+It is possible to use a low cost extern DS1307 RTC to keep date and time
+always updated. These DS1307 RTC modules come with a 3V button battery, then
+even when the board is turned OFF the Date/Time registers keep running.
+
+You can connect the module this way (STM32F4Discovery to DS1307 board): GND
+to GND; 5V to VCC; PB9 to SDA; PB6 to SCL. In the NuttX menuconfig you need
+to enable these options::
+
+ System Type --->
+ STM32 Peripheral Support --->
+ [*] I2C1
+
+ Device Drivers --->
+ Timer Driver Support --->
+ [*] RTC Driver Support --->
+ -*- Date/Time RTC Support
+ [*] External RTC Support
+ [*] DS130x/DS323x RTC Driver
+ Maxim Integrated RTC (DS1307) --->
+ (100000) DS1307/DS323x I2C frequency
+
+ Application Configuration --->
+ NSH Library --->
+ Disable Individual commands --->
+ [ ] Disable date ( <-- Deselect )
+
+It is also a good idea to enable the DEBUG to RTC initially, you will see::
+
+ ABCDF
+ stm32_ds1307_init: Initialize I2C1
+ stm32_ds1307_init: Bind the DS1307 RTC driver to I2C1
+ rtc_dumptime: Returning:
+ rtc_dumptime: tm_sec: 00000039
+ rtc_dumptime: tm_min: 00000001
+ rtc_dumptime: tm_hour: 00000009
+ rtc_dumptime: tm_mday: 00000016
+ rtc_dumptime: tm_mon: 00000008
+ rtc_dumptime: tm_year: 00000077
+
+ NuttShell (NSH)
+ nsh> date
+ Sep 22 09:01:58 2019
+
+SSD1289
+=======
+
+I purchased an LCD display on eBay from China. The LCD is 320x240 RGB565 and
+is based on an SSD1289 LCD controller and an XPT2046 touch IC. The pin out
+from the 2x16 connect on the LCD is labelled as follows::
+
+ LCD CONNECTOR: SSD1289 MPU INTERFACE PINS:
+
+ +------+------+ DEN I Display enable pin
+ 1 | GND | 3V3 | 2 VSYNC I Frame synchronization signal
+ +------+------+ HSYNC I Line synchronization signal
+ 3 | D1 | D0 | 4 DOTCLK I Dot clock and OSC source
+ +------+------+ DC I Data or command
+ 5 | D3 | D2 | 6 E (~RD) I Enable/Read strobe
+ +------+------+ R (~WR) I Read/Write strobe
+ 7 | D5 | D4 | 8 D0-D17 IO For parallel mode, 8/9/16/18 bit interface
+ +------+------+ WSYNC O RAM write synchronizatin output
+ 9 | D7 | D6 | 10 ~RES I System reset
+ +------+------+ ~CS I Chip select of serial interface
+ 11 | D9 | D8 | 12 SCK I Clock of serial interface
+ +------+------+ SDI I Data input in serial mode
+ 13 | D11 | D10 | 14 SDO O Data output in serial moce
+ +------+------+
+ 15 | D13 | D12 | 16
+ +------+------+
+ 17 | D15 | D14 | 18
+ +------+------+
+ 19 | RS | CS | 20
+ +------+------+
+ 21 | RD | WR | 22 NOTES:
+ +------+------+
+ 23 |BL_CNT|RESET | 24 BL_CNT is the PWM backlight level control.
+ +------+------+
+ 25 |TP_RQ |TP_S0 | 26 These pins are for the touch panel: TP_REQ
+ +------+------+ TP_S0, TP_SI, TP_SCX, and TP_CS
+ 27 | NC |TP_SI | 28
+ +------+------+
+ 29 | NC |TP_SCX| 30
+ +------+------+
+ 31 | NC |TP_CS | 32
+ +------+------+
+
+MAPPING TO STM32 F4::
+
+ ---------------- -------------- ----------------------------------
+ STM32 FUNCTION LCD PIN STM32F4Discovery PIN
+ ---------------- -------------- ----------------------------------
+ FSMC_D0 D0 pin 4 PD14 P1 pin 46 Conflict (Note 1)
+ FSMC_D1 D1 pin 3 PD15 P1 pin 47 Conflict (Note 2)
+ FSMC_D2 D2 pin 6 PD0 P2 pin 36 Free I/O
+ FSMC_D3 D3 pin 5 PD1 P2 pin 33 Free I/O
+ FSMC_D4 D4 pin 8 PE7 P1 pin 25 Free I/O
+ FSMC_D5 D5 pin 7 PE8 P1 pin 26 Free I/O
+ FSMC_D6 D6 pin 10 PE9 P1 pin 27 Free I/O
+ FSMC_D7 D7 pin 9 PE10 P1 pin 28 Free I/O
+ FSMC_D8 D8 pin 12 PE11 P1 pin 29 Free I/O
+ FSMC_D9 D9 pin 11 PE12 P1 pin 30 Free I/O
+ FSMC_D10 D10 pin 14 PE13 P1 pin 31 Free I/O
+ FSMC_D11 D11 pin 13 PE14 P1 pin 32 Free I/O
+ FSMC_D12 D12 pin 16 PE15 P1 pin 33 Free I/O
+ FSMC_D13 D13 pin 15 PD8 P1 pin 40 Free I/O
+ FSMC_D14 D14 pin 18 PD9 P1 pin 41 Free I/O
+ FSMC_D15 D15 pin 17 PD10 P1 pin 42 Free I/O
+ FSMC_A16 RS pin 19 PD11 P1 pin 27 Free I/O
+ FSMC_NE1 ~CS pin 10 PD7 P2 pin 27 Free I/O
+ FSMC_NWE ~WR pin 22 PD5 P2 pin 29 Conflict (Note 3)
+ FSMC_NOE ~RD pin 21 PD4 P2 pin 32 Conflict (Note 4)
+ PC6 RESET pin 24 PC6 P2 pin 47 Free I/O
+ Timer output BL_CNT pin 23 (to be determined)
+ ---------------- -------------- ----------------------------------
+
+ 1 Used for the RED LED
+ 2 Used for the BLUE LED
+ 3 Used for the RED LED and for OTG FS Overcurrent. It may be okay to use
+ for the parallel interface if PC0 is held high (or floating). PC0 enables
+ the STMPS2141STR IC power switch that drives the OTG FS host VBUS.
+ 4 Also the reset pin for the CS43L22 audio Codec.
+
+NOTE: The configuration to test this LCD configuration is available at
+boards/arm/stm32/stm32f4discovery/nxlines. As of this writing, I have not seen the
+LCD working so I probably have some things wrong.
+
+I might need to use a bit-banging interface. Below is the pin configuration
+of a similar LCD to support a (write-only), bit banging interface::
+
+ LCD PIN BOARD CONNECTION
+ LEDA 5V
+ VCC 5V
+ RD 3.3V
+ GND GND
+ DB0-7 Port C pins configured as outputs
+ DB8-15 Port A pins configured as outputs
+ RS Pin configured as output
+ WR Pin configured as output
+ CS Pin configured as output
+ RSET Pin configured as output
+
+The following summarize the bit banging operations::
+
+ /* Rese the LCD */
+ void Reset(void)
+ {
+ Set RSET output
+ delay
+ Clear RSET output
+ delay
+ Set RSET output
+ }
+
+ /* Write 16-bits of whatever */
+ void Write16(uint8_t ms, uint8_t ls)
+ {
+ Set port A to ms
+ Set port B to ls
+
+ Clear WR pin
+ Set WR pin
+ }
+
+ /* Set the index register to an LCD register address */
+ void Index(uint8_t address)
+ {
+ Clear RS
+ Write16(0, address);
+ }
+
+ /* Write data to the LCD register or GRAM memory */
+ void WriteData(uin16_t data)
+ {
+ Set RS
+ Write16(data >> 8, data & 0xff);
+ }
+
+ /* Write to a register */
+ void WriteRegister(uint8_t address, uint16_t data)
+ {
+ Index(address);
+ WriteData(data);
+ }
+
+UG-2864AMBAG01 / UG-2864HSWEG01
+===============================
+
+I purchased an OLED display on eBay. The OLED is 128x64 monochrome and
+is based on an UG-2864AMBAG01 OLED controller. The OLED can run in either
+parallel or SPI mode. I am using SPI mode. In SPI mode, the OLED is
+write only so the driver keeps a 128*64/8 = 1KB framebuffer to remember
+the display contents:
+
+Here is how I have the OLED connected. But you can change this with the
+settings in include/board.h and src/stm324fdiscovery.h. Connector
+pinout for the UG-2864AMBAG01 is specific to the theO.net display board
+that I am using::
+
+ --------------------------+----------------------------------------------
+ Connector CON10 J1: | STM32F4Discovery
+ --------------+-----------+----------------------------------------------
+ CON10 J1: | CON20 J2: | P1/P2:
+ --------------+-----------+----------------------------------------------
+ 1 3v3 | 3,4 3v3 | P2 3V
+ 3 /RESET | 8 /RESET | P2 PB6 (Arbitrary selection)
+ 5 /CS | 7 /CS | P2 PB7 (Arbitrary selection)
+ 7 A0 | 9 A0 | P2 PB8 (Arbitrary selection)
+ 9 LED+ (N/C) | ----- | -----
+ 2 5V Vcc | 1,2 Vcc | P2 5V
+ 4 DI | 18 D1/SI | P1 PA7 (GPIO_SPI1_MOSI == GPIO_SPI1_MOSI_1 (1))
+ 6 SCLK | 19 D0/SCL | P1 PA5 (GPIO_SPI1_SCK == GPIO_SPI1_SCK_1 (1))
+ 8 LED- (N/C) | ----- | ------
+ 10 GND | 20 GND | P2 GND
+ --------------+-----------+----------------------------------------------
+ (1) Required because of on-board MEMS
+ -------------------------------------------------------------------------
+
+Darcy Gong recently added support for the UG-2864HSWEG01 OLED which is also
+an option with this configuration. I have little technical information about
+the UG-2864HSWEG01 interface (see boards/arm/stm32/stm32f4discovery/src/up_ug2864hsweg01.c).
+
+NiceRF LoRa (2AD66-LoRa V2)
+===========================
+
+It is possible to wire an external LoRa module to STM32F4Discovery board.
+
+First connect the GND and VCC (to 3.3V) and then connect the SCK label to PA5,
+connect the MISO to PA6, connect the MOSI to PA7, connect the NSS to PD8,
+connect DIO0 to PD0 and finally connect NRESET to PD4.
+
+Ethernet SPI Module ENC28J60
+============================
+
+You can use an external Ethernet SPI Module ENC28J60 with STM32F4Discovery board.
+
+First connect the GND and VCC (to 3.3V). Note: according with ENC28J60 datasheet
+the Operating Voltage should be between 3.1V to 3.6V, but STM32F4Discover only
+supply 3.0V. You can modify your board to supply 3.3V: just remove the D3 diode
+and short-circuit the board pads where it was soldered).
+
+Connect the SCK label to PA5, connect the SO to PA6, connect the SI to PA7,
+connect the CS to PA4, connect RST to PE1 and finally connect INT to PE4.
+
+The next step is to enable the ENC28J60 in the menuconfig ("make menuconfig")
+and the necessary Network configuration, you can use the
+boards/arm/stm32/fire-stm32v2/configs/nsh/defconfig as reference.
+
+HCI UART
+========
+
+BT860
+-----
+
+I have been testing with the DVK_BT960_SA board via J10 as follows::
+
+ DVK_BT860-SA J10 STM32F4 Discovery P1
+ pin 1 GND P1 pin 49
+ pin 2 Module_RTS_O USART3_CTS PB13, P1 pin 37
+ pin 3 N/C
+ pin 4 Module_RX_I USART3_TXD PB10, P1 pin 34
+ pin 5 Module_TX_O USART3_RX PB11, P1 pin 35
+ pin 6 Module_CTS_I USART3_RTS PB14, P1 pin 38
+
+Due to conflicts, USART3 many not be used if Ethernet is enabled with
+the STM32F4DIS-BB base board::
+
+ PB-11 conflicts with Ethernet TXEN
+ PB-13 conflicts with Ethernet TXD1
+
+If you need to use the HCI uart with Ethernet, then you will need to
+configure a new U[S]ART and/or modify the pin selections in
+include/board.h.
+
+CC2564
+------
+
+[To be provided]
+
+One confusing thing compared with the BT860 is in the naming of the pins
+at the 4-pin RS232 TTL interface: The BT860 uses BT860-centric naming,
+the Rx pin is for BT860 receive and needs to connect with the STM32 Tx
+pin, the Tx pin is for BT860 transmit an needs to be connected with the
+STM32 Rx pin, etc. The CC2564, on the hand, uses host-centric naming so
+that the CC2564 Rx pin connects to the STM32 Rx pin, Tx to Tx pin, etc.
+
+Troubleshooting
+---------------
+
+First you should enable CONFIG_DEBUG_WIRELESS_ERR, WARN, and INFO options
+so that you can see what the driver is doing.
+
+The bring-up problems that I encountered mostly involved setting up the
+4-wire UART interface: Remember to cross Rx/Tx and RTS/CTS. The active
+state for RTS and CTS is low. For bringup of the BT860, I used a Seleae
+logic analyzer connected to the Tx, Rx, RTS, and CTS pins. When the
+BT860 is working correctly you would see this:
+
+1. All signals high initially,
+2. When NuttX starts, RTS goes low
+3. The BT860 sees RTS go low and responds by setting CTS low after a
+ delay. This is when it selects between USB and UART.
+4. After another delay, the STM32 sends the 4 Tx bytes.
+5. The BT860 responds with 3 bytes.
+6. If successful, additional commands and responses follow.
+
+Some of these steps may be different for other HCI UARTs. Steps 4-5 are
+the reset sequence. the 4 Tx bytes comes from the code in the function
+hci_initialize() in the file wireless/bluetooth/bt_hcicore.c::
+
+ /* Send HCI_RESET */
+
+ bt_hci_cmd_send(BT_HCI_OP_RESET, NULL);
+
+The code is actually working one command ahead. It has already queued up
+the reset command and is requesting the HCI UART device features while the
+reset command is being sent::
+
+ ret = bt_hci_cmd_send_sync(BT_HCI_OP_READ_LOCAL_FEATURES, NULL, &rsp);
+ if (ret < 0)
+ {
+ wlerr("ERROR: bt_hci_cmd_send_sync failed: %d\n", ret);
+ return ret;
+ }
+
+A common failure is to see a timeout error (-116) due to a Tx flow control
+failure (CTS is high). There is no timeout on the first command, the
+timeout actually occurs on the second command in bt_hci_cmd_send_sync()::
+
+ do
+ {
+ /* The timed wait could also be awakened by a signal */
+
+ ret = nxsem_timedwait(&sync_sem, &abstime);
+ }
+ while (ret == -EINTR);
+
+The above times out and generates the 116 error.
+
+In the case of the timeout, the second command is stuck in the message queue
+is never processed because the Tx thread is waiting for the BT_HCI_OP_RESET
+command to complete. It is blocked in hci_tx_thread() kernel thread.
+
+The Tx occurs on a kernel thread. The Tx send of the first command causes
+the hci_tx_kthread() to block. It waits here until what the HCI UART
+receives the command and responses with the command complete event::
+
+ /* Wait until ncmd > 0 */
+
+ do
+ {
+ ret = nxsem_wait(&g_btdev.ncmd_sem);
+ }
+ while (ret == -EINTR);
+
+bt_hci_cmd_send() will block on the first BT_HCI_OP_RESET until until it
+gets the 3-byte event (BT_EVT) that indicates that the command was
+completed and provides the command status. See the function
+hci_command_complete() where it posts g_btdev.ncmd_sem.::
+
+ g_btdev.ncmd = 1;
+ nxsem_post(&g_btdev.ncmd_sem);
+
+You can see such a hange in the wireless debug output::
+
+ bt_hci_cmd_send: opcode 0c03 len 3 <<< BT_HCI_OP_RESET command is queue
+ hci_tx_kthread: Sending command 0c03 buf 20002a40 to driver <<< Sent to driver from the Tx thread
+ hciuart_write: config 801d924 buffer 20002760 buflen 4 <<< Goes to STM32 HCI UART driver
+
+ bt_hci_cmd_send_sync: opcode 1003 len 3 <<< next command is queued.
+ hciuart_copytotxfifo: txhead 1 txtail 4 nbytes 1 <<< One byte of first command written to Tx HR
+ hciuart_enableints: CR1 000020ac CR2 00000301 <<< Tx interrupts enabled
+
+!!!! No Tx interrupts, probably because of Tx flow control (CTS is high) !!!::
+
+ hci_initialize: ERROR: bt_hci_cmd_send_sync failed: -116 <<< Times out on second message
+
+BASIC
+=====
+
+I have used the stm32f4discovery/nsh configuration to test Michael Haardt's
+BASIC interpreter that you can find at apps/interpreters/bas.::
+
+ Bas is an interpreter for the classic dialect of the programming language
+ BASIC. It is pretty compatible to typical BASIC interpreters of the 1980s,
+ unlike some other UNIX BASIC interpreters, that implement a different
+ syntax, breaking compatibility to existing programs. Bas offers many ANSI
+ BASIC statements for structured programming, such as procedures, local
+ variables and various loop types. Further there are matrix operations,
+ automatic LIST indentation and many statements and functions found in
+ specific classic dialects. Line numbers are not required.
+
+There is also a test suite for the interpreter that can be found at
+apps/examples/bastest.
+
+Configuration
+-------------
+
+Below are the recommended configuration changes to use BAS with the
+stm32f4discovery/nsh configuration:
+
+Dependencies::
+
+ CONFIG_LIBC_EXECFUNCS=y : exec*() functions are required
+ CONFIG_LIBM=y : Some floating point library is required
+ CONFIG_LIBC_FLOATINGPOINT=y : Floating point printing support is required
+ CONFIG_LIBC_TMPDIR="/tmp" : Writable temporary files needed for some commands
+ CONFIG_FS_FAT=y : With FAT you create a RAMDISK at /tmp
+ CONFIG_FAT_LFN=y : FAT is difficult to use with long file names
+
+Enable the BASIC interpreter. Other default options should be okay::
+
+ CONFIG_INTERPRETERS_BAS=y : Enables the interpreter
+ CONFIG_INTERPRETER_BAS_VT100=y
+
+The BASIC test suite can be included::
+
+ CONFIG_FS_ROMFS=y : ROMFS support is needed
+ CONFIG_EXAMPLES_BASTEST=y : Enables the BASIC test setup
+ CONFIG_EXAMPLES_BASTEST_DEVMINOR=0
+ CONFIG_EXAMPLES_BASTEST_DEVPATH="/dev/ram0"
+
+Usage
+-----
+
+This setup will initialize the BASIC test (optional): This will mount
+a ROMFS file system at /mnt/romfs that contains the BASIC test files::
+
+ nsh> bastest
+ Registering romdisk at /dev/ram0
+ Mounting ROMFS filesystem at target=/mnt/romfs with source=/dev/ram0
+ nsh>
+
+These steps will create and mount a RAMDISK at /tmp (required only for a
+few BASIC commands). This will create a RAMDISK device at /dev/ram1 with
+size = 512 * 64 = 32KiB and mount it at /tmp::
+
+ nsh> mkrd -m 1 -s 512 64
+ nsh> mkfatfs /dev/ram1
+ nsh> mount -t vfat /dev/ram1 /tmp
+ nsh>
+
+The interactive interpreter is started like::
+
+ nsh> bas
+ bas 2.4
+ Copyright 1999-2014 Michael Haardt.
+ This is free software with ABSOLUTELY NO WARRANTY.
+ >
+
+ Ctrl-D exits the interpreter.
+
+The test programs can be ran like this::
+
+ nsh> bastest
+ Registering romdisk at /dev/ram0
+ Mounting ROMFS filesystem at target=/mnt/romfs with source=/dev/ram0
+ nsh> bas /mnt/romfs/test01.bas
+ 1
+ hello
+ 0.0002
+ 0.0000020
+ 0.0000002
+
+ nsh>
+
+Or you can load a test into memory and execute it interactively::
+
+ nsh> bas
+ bas 2.4
+ Copyright 1999-2014 Michael Haardt.
+ This is free software with ABSOLUTELY NO WARRANTY.
+ > load "/mnt/romfs/test01.bas"
+ > run
+ 1
+ hello
+ 0.0002
+ 0.0000020
+ 0.0000002
+ >
+
+Testing LLVM LIBC++ with NuttX
+==============================
+
+You can use LLVM LIBC++ on NuttX to get a C++ compiler with C++11 features.
+Follow these steps to get it working:
+
+Clone the needed repositories::
+
+ $ git clone https://www.bitbucket.org/acassis/libcxx
+
+ $ git clone https://www.bitbucket.org/nuttx/apps
+
+ $ git clone https://www.bitbucket.org/nuttx/nuttx
+
+Install the libcxx files on NuttX::
+
+ $ cd libcxx
+
+ $ ./install.sh ../nuttx
+ Installing LLVM/libcxx in the NuttX source tree
+ Installation succeeded
+
+Enter inside NuttX and compile it::
+
+ $ cd ../nuttx
+
+ $ tools/configure.sh stm32f4discovery:testlibcxx
+ Copy files
+ Refreshing...
+
+ $ ls -l nuttx.bin
+ -rwxrwxr-x 1 alan alan 58112 Ago 8 11:08 nuttx.bin
+
+Plug the MiniUSB cable in the STM32F4Discovery board and flash the firmware::
+
+ $ sudo openocd -f interface/stlink-v2.cfg -f target/stm32f4x.cfg -c init \
+ -c "reset halt" -c "flash write_image erase nuttx.bin 0x08000000"
+
+ ...
+
+ Info : device id = 0x10036413
+ Info : flash size = 1024kbytes
+ target halted due to breakpoint, current mode: Thread
+ xPSR: 0x61000000 pc: 0x20000046 msp: 0x20001d60
+ wrote 65536 bytes from file nuttx.bin in 2.959432s (21.626 KiB/s)
+
+Connect the USB/Serial 3.3V dongle to PA2(board TX) and PA3(board RX) use
+minicom or other serial console configured to 115200 8n1.
+
+Press Reset pin of the board and you will see::
+
+ NuttShell (NSH)
+ nsh> ?
+ help usage: help [-v] [<cmd>]
+
+ [ cmp free mh source usleep
+ ? dirname help mv sleep xd
+ basename dd hexdump mw test
+ break echo kill pwd time
+ cat exec ls rm true
+ cd exit mb rmdir uname
+ cp false mkdir set unset
+
+ Builtin Apps:
+ helloxx
+
+ nsh>
+
+Just type helloxx::
+
+ nsh> helloxx
+ helloxx_main: Saying hello from the dynamically constructed instance
+ CHelloWorld::HelloWorld: Hello, World!!
+ helloxx_main: Saying hello from the instance constructed on the stack
+ CHelloWorld::HelloWorld: Hello, World!!
+ helloxx_main: Saying hello from the statically constructed instance
+ CHelloWorld::HelloWorld: Hello, World!!
+
+ nsh>
+
+Configurations
+==============
+
+Common Information
+------------------
+
+Each STM32F4Discovery configuration is maintained in a sub-directory and
+can be selected as follow::
+
+ tools/configure.sh STM32F4Discovery:<subdir>
+
+Where <subdir> is one of the sub-directories listed in the next paragraph
+
+NOTES (common for all configurations):
+
+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.
+
+Configuration Sub-directories
+-----------------------------
+
+audio
+-----
+
+This configuration is a variant of the NSH configuration used for
+demonstrating PCM audio using the CS43L22 stereo DAC/amplifier on board
+the STM32F4 Discovery and the STM32 I2S DMA interface. It uses the
+file player at apps/system/nxplayer. The serial console is on USART2.
+
+The original CS43L22 and STM32 I2S drivers were contribued by Taras
+Drozdovsky in May of 2017. The audio configuration was contributed by
+Alan Carvalho de Assis and derives, in part, from the work of Taras at
+https://github.com/tdrozdovskiy/CS43L22-Audio-driver.
+
+Usage instructions from the README file at the location:
+
+1. Prepare USB flash storage. This configuration depends on .WAV files
+ provided to the system via a USB flash stick. There are some sample
+ audio files at https://github.com/tdrozdovskiy/CS43L22-Audio-driver
+ and these steps will put those sample .WAV files onto the USB flash:
+
+ a. Format the USB flash storage into FAT. For example by next command::
+
+ $ mkfs.vfat /dev/sdb1
+
+ b. Create folder /music::
+
+ $ mkdir music
+
+ c. Copy files from /audio_samples/ to /music folder of USB flash storage::
+
+ $ cp <repo>/audio_samples/* /mnt/media/music/
+
+ You should be able to use either Taras' .wav files like that or, if
+ you like, your own compatible .wav files.
+
+2. Example usage CS43L22 Audio driver
+
+ a. Power On or reset the STM32F4 Discovery board. We can see the NuttX
+ command line prompt::
+
+ NuttShell (NSH)
+ nsh>
+
+ b. Mount the usb flash device into our file system::
+
+ nsh> mount -t vfat /dev/sda/ /mnt/sda
+
+ c. Start the NxPlayer program and Enter the help command to view the list
+ of commands::
+
+ nsh> nxplayer
+ NxPlayer version 1.04
+ h for commands, q to exit
+ nxplayer> h
+ NxPlayer commands
+ ================
+ balance d% : Set balance percentage (< 50% means more left)
+ device devfile : Specify a preferred audio device
+ h : Display help for commands
+ help : Display help for commands
+ mediadir path : Change the media directory
+ play filename : Play a media file
+ pause : Pause playback
+ resume : Resume playback
+ stop : Stop playback
+ tone freq secs : Produce a pure tone
+ q : Exit NxPlayer
+ quit : Exit NxPlayer
+ volume d% : Set volume to level specified
+
+ d. Play the test sample track (cu44k.wav - 44100Hz, 16bit, stereo).::
+
+ nxplayer> play cu44k.wav
+
+ e. Set the volume value to 50%.::
+
+ nxplayer> volume 50
+
+ f. Stop the current track and play another one::
+
+ nxplayer> stop
+ nxplayer> play hn.wav
+
+cxxtest
+-------
+
+The C++ standard library test at apps/testing/cxxtest configuration. This
+test is used to verify the uClibc++ port to NuttX. This configuration may
+be selected as follows::
+
+ tools/configure.sh sim:cxxtest
+
+NOTES:
+
+1. Before you can use this example, you must first install the uClibc++
+ C++ library. This is located outside of the NuttX source tree in the
+ NuttX uClibc++ GIT repository. See the README.txt file there for
+ instructions on how to install uClibc++
+
+2. Ideally, you should build with a toolchain based on GLIBC or
+ uClibc++. It you use a toolchain based on newlib, you may see
+ an error like the following::
+
+ .../lib/libsupc++.a(vterminate.o): In function `__gnu_cxx::__verbose_terminate_handler()':
+ vterminate.cc:(....): undefined reference to `_impure_ptr'
+
+ Here is a quick'n'dirty fix:
+
+ 1. Get the directory where you can find libsupc++:::
+
+ arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -print-file-name=libsupc++.a
+
+ 2. Go to that directory and save a copy of vterminate.o (in case you
+ want to restore it later::
+
+ cd <the-directory-containing-libsupc++.a>
+ arm-none-eabi-ar.exe -x libsupc++.a vterminate.o
+
+ 3. Then remove vterminate.o from the library. At build time, the
+ uClibc++ package will provide a usable replacement vterminate.o.
+
+ Steps 2 and 3 will require root privileges on most systems (not Cygwin).
+
+ Now NuttX should link with no problem. If you want to restore the
+ vterminate.o that you removed from libsupc++, you can do that with::
+
+ arm-none-eabi-ar.exe rcs libsupc++.a vterminate.o
+
+3. Exceptions are enabled and workking (CONFIG_CXX_EXCEPTION=y)
+
+elf
+---
+
+This configuration uses apps/examples/elf in order to test the ELF
+loader.
+
+NOTES:
+
+1. Default platform/toolchain::
+
+ CONFIG_HOST_WINDOWS=y : Windows
+ CONFIG_WINDOWS_CYGWIN=y : Cygwin environment on Windows
+ CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : GNU EABI toolchain for Windows
+
+2. By default, this project assumes that you are *NOT* using the DFU
+ bootloader.
+
+3. It appears that you cannot execute from CCM RAM. This is why the
+ following definition appears in the defconfig file::
+
+ CONFIG_STM32_CCMEXCLUDE=y
+
+4. This configuration requires that you have the genromfs tool installed
+ on your system and that you have the full path to the installed genromfs
+ executable in PATH variable (see apps/examples/README.txt)
+
+5. This configuration can be extended to use the hello++4 example and to
+ build uClibc with the following additions to the configuration file
+ (from Leo aloe3132)::
+
+ CONFIG_HAVE_CXXINITIALIZE=y
+
+ CONFIG_UCLIBCXX=y
+ CONFIG_CXX_EXCEPTION=y
+ CONFIG_LIBSUPCXX=y
+ CONFIG_UCLIBCXX_BUFSIZE=32
+
+ CONFIG_EXAMPLES_ELF_CXX=y
+
+6. By default, this configuration uses the ROMFS file system. It can also
+ be modified to use the compressed CROMFS::
+
+ -CONFIG_PATH_INITIAL="/mnt/romfs"
+ +CONFIG_PATH_INITIAL="/mnt/cromfs"
+
+ -CONFIG_FS_ROMFS=y
+ +CONFIG_FS_CROMFS=y
+
+ -CONFIG_EXAMPLES_ELF_ROMFS=y
+ +CONFIG_EXAMPLES_ELF_CROMFS=y
+
+7. The network initialization thread is enabled in this configuration.
+ As a result, networking initialization is performed asynchronously with
+ NSH bring-up.
+
+ The network monitor is not enabled in this configuration, however, so
+ the firmware will not know when the network is disconnected or
+ reconnected. The NSH Network Monitor cannot be used with the
+ STM32F4DIS-BB base board because the LAN8720 is configured in REF_CLK
+ OUT mode. In that mode, the PHY interrupt is not supported. The NINT
+ pin serves as REFLCK0 in that case.
+
+hciuart
+-------
+
+This configuration was used for test the HCI UART driver. The HCI UART
+is enabled on USART3 as well as the test application at
+apps/wireless/bluetoot/btsak.
+
+NOTES:
+
+1. This configuration assumes that that you are using the STM32F4DIS-BB
+ base board with serial console on USART6. If you are not using the
+ STM32F4DIS-BB, then you will want to disable support for the base
+ board.::
+
+ -CONFIG_STM32F4DISBB=y
+ +# CONFIG_STM32F4DISBB is not set
+
+ You may also want to reconfigure the serial console to USART1.
+
+2. The HCI UART is assumed to connect to the UART3 on the following pins::
+
+ USART3 TX : PB10
+ USART3 RX : PB11
+ USART3 CTS: PB13
+ USART3 RTS: PB14
+
+The HCI UART selection can be changed by re-configuring and assigning
+the different U[S]ART to the HCI. The U[S]ART pin selections can be
+changed by modifying the disambiguation definitions in
+boards/arm/stm32/stm32f4discovery/include/board.h
+
+I have been testing with the DVK_BT960_SA board via J10 as follows::
+
+ DVK_BT860-SA J10 STM32F4 Discovery P1
+ pin 1 GND P1 pin 49
+ pin 2 Module_RTS_O USART3_CTS PB13, P1 pin 37
+ pin 3 N/C
+ pin 4 Module_RX_I USART3_TXD PB10, P1 pin 34
+ pin 5 Module_TX_O USART3_RX PB11, P1 pin 35
+ pin 6 Module_CTS_I USART3_RTS PB14, P1 pin 38
+
+NOTICE that the BT860 uses BT860-centric naming, the Rx pin is for
+BT860 receive and needs to connect with the STM32 Tx pin, the Tx pin
+is for BT860 transmit an needs to be connected with the STM32 Rx pin,
+etc. Other parts may use host-centric naming so that the HCI UART Rx
+pin connects to the STM32 Rx pin, Tx to Tx pin, etc.
+
+3. Due to conflicts, USART3 many not be used if Ethernet is enabled with
+ the STM32F4DIS-BB base board::
+
+ PB-11 conflicts with Ethernet TXEN
+ PB-13 conflicts with Ethernet TXD1
+
+ If you need to use the HCI uart with Ethernet, then you will need to
+ configure a new U[S]ART and/or modify the pin selections in
+ include/board.h.
+
+4. Stack sizes are large and non-optimal. Don't judge memory usage
+ without tuning.
+
+5. I tested using the Laird DVK_BT860. The BT860 defaults to 115200
+ BAUD but is capable of transfers up to 4M. The documentation says
+ that the part supports auto baudrate detection, but I have found no
+ documentation on how to use that.
+
+ Currently the "generic" HCI UART upper half is used with the BT860
+ and that upper half driver supports only a fixed (but configurable
+ BAUD) is used and this must be set to the BT860 default (115200).
+
+ A custom BT860 upper half driver is needed that can use vendor
+ specific command: Baud rate can be set with such a vendor-specific
+ command. Ideally, the sequence would be: (1) start at default baud
+ rate, (2) get local version info, (3) send the vendor-specific baud
+ rate change command, (4) wait for response, and (5) set the local
+ UART to the matching, higher baud rate.
+
+ The custom, vendor-specific BT860 command is::
+
+ {0x18, 0xfc, 0x06, 0x00, 0x00, NN, NN, NN, NN}
+
+ where {NN, NN, NN, NN} is the requested baud in little endian byte order.
+
+ If an initialization script is used then (5) then send initialization
+ scripts script. After sending the last command from the
+ initialization script, (6) reset the local UART. Finally, (7) send
+ vendor-specific baud rate change command, (8) wait for response, and
+ (9) set local UART to high baud rate.
+
+ The command to write the initialization script into NVRAM is another
+ story for another time and another place.
+
+ If you use a different HCI UART, you will need to modify this setting::
+
+ CONFIG_BLUETOOTH_UART_GENERIC=y
+
+ and you may have to add some support in drivers/wireless/bluetooth.
+
+ipv6
+----
+
+This is another version of the NuttShell configuration for the
+STM32F4-Discovery with the STM32F4DIS-BB base board. It is very similar
+to the netnsh configuration except that it has IPv6 enabled and IPv4
+disabled. Several network utilities that are not yet available when
+IPv6 is disabled.
+
+NOTES:
+
+1. As of 2015-02-05, this configuration was identical to the netnsh
+ configuration other than using IPv6. So all of the notes above
+ regarding the netnsh configuration apply.
+
+ a. Telnet does work with IPv6 but is not enabled in this
+ configuration (but could be).
+ b. The network initialization thread was enabled in the netnsh
+ configuration on 2015-09-28, but not in the ipv6 configuration.
+
+2. This configuration can be modified to that both IPv4 and IPv6
+ are support. Here is a summary of the additional configuration
+ settings required to support both IPv4 and IPv6::
+
+ CONFIG_NET_IPv4=y
+ CONFIG_NET_ARP=y
+ CONFIG_NET_ARP_SEND=y (optional)
+ CONFIG_NET_ICMP=y
+ CONFIG_NET_ICMP_SOCKET=y
+
+ CONFIG_NETDB_DNSCLIENT=y
+ CONFIG_NETUTILS_TELNETD=y
+
+ CONFIG_NSH_IPADDR=0x0a000002
+ CONFIG_NSH_DRIPADDR=0x0a000001
+ CONFIG_NSH_NETMASK=0xffffff00
+ CONFIG_NSH_TELNET=y
+
+ Then from NSH, you have both ping and ping6 commands::
+
+ nsh> ping 10.0.0.1
+ nsh> ping6 fc00::1
+
+ And from the host you can do similar::
+
+ ping 10.0.0.2
+ ping6 fc00::2 (Linux)
+ ping -6 fc00::2 (Windows cmd)
+
+ and Telnet is now enabled and works from the host... but only using
+ IPv6 addressing::
+
+ telnet fc00::2
+
+ That is because the Telnet daemon will default to IPv6 and there is
+ no Telnet option to let you select which if both IPv4 and IPv6 are
+ enabled.
+
+3. I have used this configuration to serve up IP address prefixes
+ in a local network with these modifications to the configuration::
+
+ +CONFIG_NET_ICMPv6_ROUTER=y
+ +CONFIG_NET_ICMPv6_PREFLEN=64
+ +CONFIG_NET_ICMPv6_PREFIX_1=0xfc00
+ +CONFIG_NET_ICMPv6_PREFIX_2=0x0000
+ +CONFIG_NET_ICMPv6_PREFIX_3=0x0000
+ +CONFIG_NET_ICMPv6_PREFIX_4=0x0000
+ +CONFIG_NET_ICMPv6_PREFIX_5=0x0000
+ +CONFIG_NET_ICMPv6_PREFIX_6=0x0000
+ +CONFIG_NET_ICMPv6_PREFIX_7=0x0000
+ +CONFIG_NET_ICMPv6_PREFIX_8=0x0000
+
+ +CONFIG_NSH_IPv6NETMASK_5=0x0000
+ -CONFIG_NSH_IPv6NETMASK_5=0xffff
+
+ +CONFIG_NSH_IPv6NETMASK_6=0x0000
+ -CONFIG_NSH_IPv6NETMASK_6=0xffff
+
+ +CONFIG_NSH_IPv6NETMASK_7=0x0000
+ -CONFIG_NSH_IPv6NETMASK_7=0xffff
+
+ +CONFIG_NSH_IPv6NETMASK_8=0x0000
+ -CONFIG_NSH_IPv6NETMASK_8=0xff80
+
+kostest
+-------
+
+This is identical to the ostest 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 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.
+
+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
+
+3. 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.
+
+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
+other NSH configurations 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-02: Configuration added by Alan Carvalho de Assis.
+
+netnsh
+------
+
+This is a special version of the NuttShell (nsh) configuration that is
+tailored to work with the STM32F4DIS-BB base board. This version
+derives from nsh configuration so all of the notes apply there except as
+noted below.
+
+NOTES:
+
+1. This example uses USART6 for the serial console. The STM32F4DIS-BB
+ provides RS-232 drivers for USART6 and allows access via the DB9
+ connector on the base board. USART6 is, therefore, the more
+ convenient UART to use for the serial console.
+
+2. Networking is enabled. The STM32F4DIS-BB has an SMC LAN2870 PHY
+ and RJ5 network connector. Support is enabled for ICMP, TCP/IP,
+ UDP, and ARP.
+
+3. SD card support is enabled. The STM32F4DIS-BB has an on-board
+ microSD slot that should be automatically registered as the block
+ device /dev/mmcsd0 when an SD card is present. The SD card can
+ then be mounted by the NSH command::
+
+ nsh> mount -t /dev/mmcsd0 /mnt/sdcard
+
+4. CCM memory is not included in the heap in this configuration. That
+ is because the SD card uses DMA and if DMA memory is allocated from
+ the CCM memory, the DMA will failure. This is an STM32 hardware
+ limitation.
+
+ If you want to get the CCM memory back in the heap, then you can
+
+ a) Disable microSD support (and DMAC2 which is then no longer
+ needed). If you reduce the clocking by a huge amount, it might
+ be possible to use microSD without DMA. This, however, may
+ not be possible.
+ b) Develop a strategy to manage CCM memory and DMA memory. Look
+ at this discussion on the NuttX Wiki:
+ https://cwiki.apache.org/confluence/display/NUTTX/STM32+CCM+Allocator
+
+ To put the CCM memory back into the heap you would need to change
+ the following in the NuttX configuration::
+
+ CONFIG_STM32_CCMEXCLUDE=n : Don't exclude CCM memory from the heap
+ CONFIG_MM_REGIONS=2 : With CCM, there will be two memory regions
+
+nsh
+---
+
+Configures the NuttShell (nsh) located at apps/examples/nsh. The
+Configuration enables the serial interfaces on USART2. Support for
+builtin applications is enabled, but in the base configuration no
+builtin applications are selected (see NOTES below).
+
+NOTES:
+
+1. 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
+
+2. To use this configuration with the STM32F4DIS-BB baseboard you
+ should:
+
+ - Select the STM32F4DIS-BB baseboard in the board configuration menu
+ - Disable USART2 and select USART6 in the STM32 peripheral selection menu
+ - Select USART6 as the serial console at 115200 8N1 in the Drivers menus
+
+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
+
+4. 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.tx. Special debug options::
+
+ CONFIG_DEBUG_SENSORS
+
+5. 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.
+
+6. 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
+
+7. Using the USB console.
+
+ The STM32F4Discovery 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.
+
+8. 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
+ of the 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.
+
+9. 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::
+
+ 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_OTGFS=y : Enable the STM32 USB OTG FS block
+ CONFIG_STM32_SYSCFG=y : Needed for all USB OTF FS 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
+
+10. 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
+
+ System Type -> USB host configuration
+ To be determined
+
+ Board Selection ->
+ CONFIG_STM32F4DISCO_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.
+
+11. Using USB Device as a Mass Storage for the host computer::
+
+ System Type --->
+ STM32 Peripheral Support --->
+ [*] OTG FS
+
+ Device Drivers --->
+ [*] USB Device Driver Support --->
+ [*] USB Mass storage class device --->
+ [*] Mass storage removable
+
+ [*] RAM Disk Support
+
+ Board Selection --->
+ [*] Enable boardctl() interface
+ [*] Enable USB device controls
+
+ File Systems --->
+ [*] FAT file system
+ [*] FAT upper/lower names
+ [*] FAT long file names
+
+ [*] PROCFS File System
+
+ Application Configuration --->
+ System Libraries and NSH Add-Ons --->
+ [*] USB Mass Storage Device Commands --->
+ (/dev/ram0) LUN1 Device Path
+
+ Compile and flash the firmware in the board as usual, then in the nsh::
+
+ nsh> mkrd -m 0 -s 512 64
+
+ nsh> ls /dev
+ /dev:
+ console
+ null
+ ram0
+ ttyS0
+
+ nsh> mkfatfs /dev/ram0
+
+ Connect a USB cable to STM32F4Discovery board (connector CN5) and run::
+
+ nsh> msconn
+ mcsonn_main: Creating block drivers
+ mcsonn_main: Configuring with NLUNS=1
+ mcsonn_main: handle=1000a550
+ mcsonn_main: Bind LUN=0 to /dev/ram0
+ mcsonn_main: Connected
+
+ In this moment a 33KB disk should appear in your host computer. If you
+ saved some file on this small disk you can now run disconnect command::
+
+ nsh> msdis
+ msdis: Disconnected
+
+ Remove the USB cable from microUSB connector and run::
+
+ nsh> mount -t vfat /dev/ram0 /mnt
+
+ nsh> ls /mnt
+ /mnt:
+ TEST.TXT
+
+ nsh> cat /mnt/TEST.TXT
+ Testing
+
+nxlines
+-------
+
+An example using the NuttX graphics system (NX). This example focuses on
+placing lines on the background in various orientations.::
+
+ CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : GNU EABI toolchain for Windows
+ CONFIG_LCD_LANDSCAPE=y : 320x240 landscape orientation
+
+The STM32F4Discovery board does not have any graphics capability. This
+configuration assumes that you have connected an SD1289-based LCD as
+described above under "SSD1289". NOTE: At present, it has not been
+proven that the STM32F4Discovery can actually drive an LCD. There are
+some issues with how some of the dedicated FSMC pins are used on the
+boards. This configuration may not be useful and may only serve as
+an illustration of how to build for th SSD1289 LCD.
+
+NOTES:
+
+1. As of this writing, I have not seen the LCD work!
+
+2. This configured can be re-configured to use either the
+ UG-2864AMBAG01 or UG-2864HSWEG01 0.96 inch OLEDs by adding
+ or changing the following items in the configuration (using
+ 'make menuconfig')::
+
+ +CONFIG_SPI_CMDDATA=y
+
+ -CONFIG_LCD_MAXCONTRAST=1
+ -CONFIG_LCD_MAXPOWER=255
+ +CONFIG_LCD_MAXCONTRAST=255
+ +CONFIG_LCD_MAXPOWER=1
+
+ -CONFIG_LCD_SSD1289=y
+ -CONFIG_SSD1289_PROFILE1=y
+ +CONFIG_LCD_UG2864AMBAG01=y : For the UG-2964AMBAG01
+ +CONFIG_UG2864AMBAG01_SPIMODE=3
+ +CONFIG_UG2864AMBAG01_FREQUENCY=3500000
+ +CONFIG_UG2864AMBAG01_NINTERFACES=1
+
+ -CONFIG_NX_DISABLE_1BPP=y
+ +CONFIG_NX_DISABLE_16BPP=y
+ +CONFIG_NXSTART_EXTERNINIT=y
+
+ -CONFIG_EXAMPLES_NXLINES_BGCOLOR=0x0320
+ -CONFIG_EXAMPLES_NXLINES_LINEWIDTH=16
+ -CONFIG_EXAMPLES_NXLINES_LINECOLOR=0xffe0
+ -CONFIG_EXAMPLES_NXLINES_BORDERWIDTH=4
+ -CONFIG_EXAMPLES_NXLINES_BORDERCOLOR=0xffe0
+ -CONFIG_EXAMPLES_NXLINES_CIRCLECOLOR=0xf7bb
+ -CONFIG_EXAMPLES_NXLINES_BPP=16
+ +CONFIG_EXAMPLES_NXLINES_BGCOLOR=0x00
+ +CONFIG_EXAMPLES_NXLINES_LINEWIDTH=4
+ +CONFIG_EXAMPLES_NXLINES_LINECOLOR=0x01
+ +CONFIG_EXAMPLES_NXLINES_BORDERWIDTH=2
+ +CONFIG_EXAMPLES_NXLINES_BORDERCOLOR=0x01
+ +CONFIG_EXAMPLES_NXLINES_CIRCLECOLOR=0x00
+ +CONFIG_EXAMPLES_NXLINES_BPP=1
+ +CONFIG_EXAMPLES_NXLINES_EXTERNINIT=y
+
+ There are some issues with the presentation... some tuning of the
+ configuration could fix that. Lower resolution displays are also more
+ subject to the "fat, flat line bug" that I need to fix someday. See
+ https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629474
+ for a description of the fat, flat line bug.
+
+pm
+--
+
+This is a configuration that is used to test STM32 power management, i.e.,
+to test that the board can go into lower and lower states of power usage
+as a result of inactivity. This configuration is based on the nsh2
+configuration with modifications for testing power management. This
+configuration should provide some guidelines for power management in your
+STM32 application.
+
+NOTES:
+
+1. Default configuration is Cygwin under windows using the AM EABI GCC
+ toolchain::
+
+ CONFIG_HOST_WINDOWS=y : Windows
+ CONFIG_WINDOWS_CYGWIN=y : Cygwin
+ CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : GNU EABI toolchain for Windows
+
+2. CONFIG_ARCH_CUSTOM_PMINIT and CONFIG_ARCH_IDLE_CUSTOM are necessary
+ parts of the PM configuration::
+
+ CONFIG_ARCH_CUSTOM_PMINIT=y
+
+ CONFIG_ARCH_CUSTOM_PMINIT moves the PM initialization from
+ arch/arm/src/stm32/stm32_pminitialiaze.c to boards/arm/stm32/stm3210-eval/src/stm32_pm.c.
+ This allows us to support board-specific PM initialization.::
+
+ CONFIG_ARCH_IDLE_CUSTOM=y
+
+ The bulk of the PM activities occur in the IDLE loop. The IDLE loop
+ is special because it is what runs when there is no other task running.
+ Therefore when the IDLE executes, we can be assure that nothing else
+ is going on; this is the ideal condition for doing reduced power
+ management.
+
+ The configuration CONFIG_ARCH_IDLE_CUSTOM allows us to "steal" the
+ normal STM32 IDLE loop (of arch/arm/src/stm32/stm32_idle.c) and replace
+ this with our own custom IDLE loop (at boards/arm/stm32/stm3210-eval/src/up_idle.c).
+
+3. Here are some additional things to note in the configuration::
+
+ CONFIG_PM_BUTTONS=y
+
+ CONFIG_PM_BUTTONS enables button support for PM testing. Buttons can
+ drive EXTI interrupts and EXTI interrupts can be used to wakeup for
+ certain reduced power modes (STOP mode). The use of the buttons here
+ is for PM testing purposes only; buttons would normally be part the
+ application code and CONFIG_PM_BUTTONS would not be defined.::
+
+ CONFIG_RTC_ALARM=y
+
+ The RTC alarm is used to wake up from STOP mode and to transition to
+ STANDBY mode. This used of the RTC alarm could conflict with other
+ uses of the RTC alarm in your application.
+
+posix_spawn
+------------
+
+This configuration directory, performs a simple test os the posix_spawn
+interface using apps/examples/posix_spawn.
+
+NOTES:
+
+1. Default toolchain::
+
+ CONFIG_HOST_WINDOWS=y : Builds under windows
+ CONFIG_WINDOWS_CYGWIN=y : Using Cygwin and
+ CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : Generic ARM EABI toolchain for Windows
+
+2. By default, this project assumes that you are *NOT* using the DFU bootloader.
+
+pseudoterm
+-----------
+
+This is a configuration to test the Pseudo Terminal support for NuttX.
+
+To test it you will need two USB/Serial dongles. The first dongle as
+usual will be used to main NSH console port in USART2 (PA2 and PA3) and
+the second dongle you will connect to UART3 (PB10 and PB11).
+
+In the main NSH console (in USART2) type: "pts_test &". It will create a
+new console in UART3. Just press ENTER and start typing commands on it.
+
+sporadic
+--------
+
+This is an NSH configuration that includes apps/testing/ostest as a builtin.
+The sporadic scheduler is enabled and the purpose of this configuration is
+to investigate an error in that scheduler. See Issue 2035. The serial
+console is on USART6.
+
+testlibcxx
+----------
+
+This is a configuration for testing lib++. See the section above entitled
+"Testing LLVM LIBC++ with NuttX" for detailed information about this
+configuration.
+
+rgbled
+-------
+
+Alan Carvalho de Assis has used the STM32F4-Discovery to drive an RGB LED
+using PWM output. The external RGB connected this way::
+
+ R = TIM1 CH1 on PE9
+ G = TIM2 CH2 on PA1
+ B = TIM3 CH3 on PB0
+
+as described about in the section "RGB LED Driver".
+
+This configuration uses the example at apps/examples/rgbled to drive the
+external RGB LED>
+
+rndis
+------
+
+This is a board configuration to demonstrate how to use Ethernet-over-USB,
+in this case using the RNDIS protocol. Using it you can get access to your
+board using Telnet or you can use transfer file to it. Both steps will be
+explained below.
+
+Your board will be get IP address from a DHCP server. If you want to use a
+fixed IP instead using DHCP, you need to disable the DHCP Client and set
+up its IP. For more info watch: www.youtube.com/watch?v=8noH8v7xNgs
+
+You can access the board's NuttShell just typing in the Linux terminal::
+
+ $ telnet 10.0.0.2
+
+You should see something like this::
+
+ Trying 10.0.0.2...
+ Connected to 10.0.0.2.
+ Escape character is '^]'.
+
+ NuttShell (NSH)
+ nsh>
+
+This board configuration has support to RAMDISK because we need a writable
+filesystem to get files from the computer. Then you need to create first a
+RAMDISK and mount it using these steps::
+
+ nsh> mkrd 64
+ nsh> mkfatfs /dev/ram0
+ nsh> mount -t vfat /dev/ram0 /mnt
+
+Open a new Linux terminal and start a webserver, Python one embedded::
+
+ $ python -m SimpleHTTPServer
+
+It will create a webserver serving in the port 8000 and will share files
+in the current directory where it was executed.
+
+Then in the NuttShell you can run these commands to download a small file::
+
+ nsh> cd /mnt
+ nsh> wget http://10.0.0.1:8000/test.txt
+ nsh> ls -l
+ /mnt:
+ -rw-rw-rw- 23 test.txt
+
+This configuration also supports:
+
+1. An NFS file system client. Relevant configuration options::
+
+ CONFIG_NFS=y
+ CONFIG_NFS_STATISTICS=y
+
+2. Loadable ELF modules::
+
+ CONFIG_SYMTAB_ORDEREDBYNAME=y
+ CONFIG_ELF=y
+ CONFIG_EXAMPLES_HELLO=m
+ CONFIG_LIBC_EXECFUNCS=y
+ CONFIG_NSH_FILE_APPS=y
+ CONFIG_NSH_SYMTAB=y
+ CONFIG_NSH_SYMTAB_ARRAYNAME="g_symtab"
+ CONFIG_NSH_SYMTAB_COUNTNAME="g_nsymbols"
+
+ Further, the configuration assumes that executable files reside on the
+ remotely mounted file system:
+
+ CONFIG_LIBC_ENVPATH=y
+ CONFIG_PATH_INITIAL="/mnt/nfs/bin"
+
+3 'ping' support::
+
+ CONFIG_NET_ICMP_SOCKET=y
+ CONFIG_SYSTEM_PING=y
+
+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. 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
+
+2. This configuration does have USART2 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" : USART2 will be /dev/ttyS0
+
+ However, there is nothing to generate SYSLOG output in the default
+ configuration so nothing should appear on USART2 unless you enable
+ some debug output or enable the USB monitor.
+
+ NOTE: Using the SYSLOG to get debug output has limitations. Among
+ those are that you cannot get debug output from interrupt handlers.
+ So, in particularly, debug output is not a useful way to debug the
+ USB device controller driver. Instead, use the USB monitor with
+ USB debug off and USB trace on (see below).
+
+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 (USART2 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
+
+4. 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=n : Disable the CDC/ACM serial device class
+ CONFIG_CDCACM_CONSOLE=n : 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
+
+winbuild
+--------
+
+This is a version of the apps/example/ostest, but configure to build natively
+in the Windows CMD shell.
+
+NOTES:
+
+1. The beginnings of a Windows native build are in place but still not full
+ usable as of this writing. The windows native build logic is currently
+ separate and must be started by::
+
+ make -f Win.mk
+
+ This build:
+
+ - Uses all Windows style paths
+ - Uses primarily Windows batch commands from cmd.exe, with
+ - A few extensions from GNUWin32 (or MSYS is you prefer)
+
+ In this build, you cannot use a Cygwin or MSYS shell. Rather the build must
+ be performed in a Windows console. Here is a better shell than than the
+ standard issue, CMD.exe shell: ConEmu which can be downloaded from:
+ http://code.google.com/p/conemu-maximus5/ ::
+
+ CONFIG_HOST_WINDOWS=y : Windows
+ CONFIG_WINDOWS_NATIVE=y : Native Windows environment
+ CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : GNU EABI toolchain for Windows
+
+ Build Tools. The build still relies on some Unix-like commands. I use
+ the GNUWin32 tools that can be downloaded from http://gnuwin32.sourceforge.net/.
+ The MSYS tools are probably also a option but are likely lower performance
+ since they are based on Cygwin 1.3.
+
+ Host Compiler: I use the MingGW compiler which can be downloaded from
+ http://www.mingw.org/. If you are using GNUWin32, then it is recommended
+ the you not install the optional MSYS components as there may be conflicts.
diff --git a/Documentation/platforms/arm/stm32f4/index.rst b/Documentation/platforms/arm/stm32f4/index.rst
new file mode 100644
index 0000000000..8d11ba1506
--- /dev/null
+++ b/Documentation/platforms/arm/stm32f4/index.rst
@@ -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/*/*
diff --git a/Documentation/platforms/arm/stm32wl5/index.rst b/Documentation/platforms/arm/stm32wl5/index.rst
index ccf56ebd6b..aad8964254 100644
--- a/Documentation/platforms/arm/stm32wl5/index.rst
+++ b/Documentation/platforms/arm/stm32wl5/index.rst
@@ -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
diff --git a/boards/arm/stm32/mikroe-stm32f4/README.txt b/boards/arm/stm32/mikroe-stm32f4/README.txt
deleted file mode 100644
index 90b37e9eb8..0000000000
--- a/boards/arm/stm32/mikroe-stm32f4/README.txt
+++ /dev/null
@@ -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
diff --git a/boards/arm/stm32/nucleo-f410rb/README.txt b/boards/arm/stm32/nucleo-f410rb/README.txt
deleted file mode 100644
index d187ebf583..0000000000
--- a/boards/arm/stm32/nucleo-f410rb/README.txt
+++ /dev/null
@@ -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.
diff --git a/boards/arm/stm32/nucleo-f412zg/README.txt b/boards/arm/stm32/nucleo-f412zg/README.txt
deleted file mode 100644
index 68ee51138f..0000000000
--- a/boards/arm/stm32/nucleo-f412zg/README.txt
+++ /dev/null
@@ -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.
diff --git a/boards/arm/stm32/nucleo-f446re/README.txt b/boards/arm/stm32/nucleo-f446re/README.txt
deleted file mode 100644
index be2c5c596e..0000000000
--- a/boards/arm/stm32/nucleo-f446re/README.txt
+++ /dev/null
@@ -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.
diff --git a/boards/arm/stm32/nucleo-f4x1re/README.txt b/boards/arm/stm32/nucleo-f4x1re/README.txt
deleted file mode 100644
index da6c1bb9cb..0000000000
--- a/boards/arm/stm32/nucleo-f4x1re/README.txt
+++ /dev/null
@@ -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.
diff --git a/boards/arm/stm32/olimex-stm32-e407/README.txt b/boards/arm/stm32/olimex-stm32-e407/README.txt
deleted file mode 100644
index 8d76625e23..0000000000
--- a/boards/arm/stm32/olimex-stm32-e407/README.txt
+++ /dev/null
@@ -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.
diff --git a/boards/arm/stm32/olimex-stm32-p407/README.txt b/boards/arm/stm32/olimex-stm32-p407/README.txt
deleted file mode 100644
index db081f3dea..0000000000
--- a/boards/arm/stm32/olimex-stm32-p407/README.txt
+++ /dev/null
@@ -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.
diff --git a/boards/arm/stm32/omnibusf4/README.txt b/boards/arm/stm32/omnibusf4/README.txt
deleted file mode 100644
index 4eb4173f61..0000000000
--- a/boards/arm/stm32/omnibusf4/README.txt
+++ /dev/null
@@ -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.
diff --git a/boards/arm/stm32/stm3240g-eval/README.txt b/boards/arm/stm32/stm3240g-eval/README.txt
deleted file mode 100644
index 8b7a35aa0c..0000000000
--- a/boards/arm/stm32/stm3240g-eval/README.txt
+++ /dev/null
@@ -1,1217 +0,0 @@
-README
-======
-
-This README discusses issues unique to NuttX configurations for the
-STMicro STM32140G-EVAL development board.
-
-Contents
-========
-
- - Ethernet
- - LEDs
- - PWM
- - CAN
- - FPU
- - FSMC SRAM
- - I/O Expanders
- - STM3240G-EVAL-specific Configuration Options
- - Configurations
-
-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* 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** ON N/C N/C OFF
- LED_SIGNAL In a signal handler*** 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)
-
- * 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
- ** 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.
-*** 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
-
-Configuration Options:
-
- 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_STM32_CAN1 - Enable support for CAN1
- CONFIG_STM32_CAN1_BAUD - CAN1 BAUD rate. Required if CONFIG_STM32_CAN1
- is defined.
- CONFIG_STM32_CAN2 - Enable support for CAN2
- 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.
-
-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
-
-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
-
-STM3240G-EVAL-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_STM32F407IG=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=stm3240g_eval (for the STM3240G-EVAL development board)
-
- CONFIG_ARCH_BOARD_name - For use in C code
-
- CONFIG_ARCH_BOARD_STM3240G_EVAL=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_STM32_EXTERNAL_RAM - 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 (hex)
-
- CONFIG_HEAP2_END - The size of the SRAM in the FSMC address space (decimal)
-
- CONFIG_ARCH_FPU - The STM3240xxx supports a floating point unit (FPU)
-
- CONFIG_ARCH_FPU=y
-
- CONFIG_ARCH_LEDS - Use LEDs to show state. Unique to boards that
- have LEDs
-
- 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 JTAG-DP and SW-DP are disabled):
-
- 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
-
- STM3240xxx 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
-
- 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.
-
- 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.
-
- CONFIG_STM32_PHYADDR - The 5-bit address of the PHY on the board
- CONFIG_STM32_MII - Support Ethernet MII interface
- CONFIG_STM32_MII_MCO1 - Use MCO1 to clock the MII interface
- CONFIG_STM32_MII_MCO2 - Use MCO2 to clock the MII interface
- CONFIG_STM32_RMII - Support Ethernet RMII interface
- CONFIG_STM32_AUTONEG - Use PHY autonegotiation to determine speed and mode
- CONFIG_STM32_ETHFD - If CONFIG_STM32_AUTONEG is not defined, then this
- may be defined to select full duplex mode. Default: half-duplex
- CONFIG_STM32_ETH100MBPS - If CONFIG_STM32_AUTONEG is not defined, then this
- may be defined to select 100 MBps speed. Default: 10 Mbps
- CONFIG_STM32_PHYSR - This must be provided if CONFIG_STM32_AUTONEG is
- defined. The PHY status register address may diff from PHY to PHY. This
- configuration sets the address of the PHY status register.
- CONFIG_STM32_PHYSR_SPEED - This must be provided if CONFIG_STM32_AUTONEG is
- defined. This provides bit mask indicating 10 or 100MBps speed.
- CONFIG_STM32_PHYSR_100MBPS - This must be provided if CONFIG_STM32_AUTONEG is
- defined. This provides the value of the speed bit(s) indicating 100MBps speed.
- CONFIG_STM32_PHYSR_MODE - This must be provided if CONFIG_STM32_AUTONEG is
- defined. This provide bit mask indicating full or half duplex modes.
- CONFIG_STM32_PHYSR_FULLDUPLEX - This must be provided if CONFIG_STM32_AUTONEG is
- defined. This provides the value of the mode bits indicating full duplex mode.
- CONFIG_STM32_ETH_PTP - Precision Time Protocol (PTP). Not supported
- but some hooks are indicated with this condition.
-
- STM3240G-EVAL CAN Configuration
-
- CONFIG_CAN - Enables CAN support (one or both of CONFIG_STM32_CAN1 or
- CONFIG_STM32_CAN2 must also be defined)
- 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.
-
- STM3240G-EVAL LCD Hardware Configuration
-
- The LCD driver supports the following LCDs on the STM324xG_EVAL board:
-
- AM-240320L8TNQW00H (LCD_ILI9320 or LCD_ILI9321) OR
- AM-240320D5TOQW01H (LCD_ILI9325)
-
- Configuration options.
-
- CONFIG_LCD_LANDSCAPE - Define for 320x240 display "landscape"
- support. Default is this 320x240 "landscape" orientation
- For the STM3240G-EVAL board, the edge opposite from the row of buttons
- is used as the top of the display in this orientation.
- CONFIG_LCD_RLANDSCAPE - Define for 320x240 display "reverse
- landscape" support. Default is this 320x240 "landscape"
- orientation
- For the STM3240G-EVAL board, the edge next to the row of buttons
- is used as the top of the display in this orientation.
- CONFIG_LCD_PORTRAIT - Define for 240x320 display "portrait"
- orientation support. In this orientation, the STM3210E-EVAL's
- LCD ribbon cable is at the bottom of the display. Default is
- 320x240 "landscape" orientation.
- In this orientation, the top of the display is to the left
- of the buttons (if the board is held so that the buttons are at the
- bottom of the board).
- CONFIG_LCD_RPORTRAIT - Define for 240x320 display "reverse
- portrait" orientation support. In this orientation, the
- STM3210E-EVAL's LCD ribbon cable is at the top of the display.
- Default is 320x240 "landscape" orientation.
- In this orientation, the top of the display is to the right
- of the buttons (if the board is held so that the buttons are at the
- bottom of the board).
- CONFIG_STM3240G_LCD_RDSHIFT - When reading 16-bit gram data, there appears
- to be a shift in the returned data. This value fixes the offset.
- Default 5.
-
- The LCD driver dynamically selects the LCD based on the reported LCD
- ID value. However, code size can be reduced by suppressing support for
- individual LCDs using:
-
- CONFIG_STM3240G_ILI9320_DISABLE (includes ILI9321)
- CONFIG_STM3240G_ILI9325_DISABLE
-
- STM32 USB OTG FS Host Driver Support
-
- Pre-requisites
-
- 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 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.
diff --git a/boards/arm/stm32/stm32f429i-disco/README.txt b/boards/arm/stm32/stm32f429i-disco/README.txt
deleted file mode 100644
index 668bdf66e8..0000000000
--- a/boards/arm/stm32/stm32f429i-disco/README.txt
+++ /dev/null
@@ -1,1004 +0,0 @@
-README
-======
-
-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.
-
-Contents
-========
-
- - Development Environment
- - GNU Toolchain Options
- - Setup and Programming Flash
- - LEDs
- - UARTs
- - Ser
- - Timer Inputs/Outputs
- - FPU
- - FMC SDRAM
- - STM32F429I-DISCO-specific Configuration Options
- - Configurations
-
-Development Environment
-=======================
-
-The Development environments for the STM32F429I-DISCO board are identical
-to the environments for other STM32F boards. For full details on the
-environment options and setup, see the README.txt file in the
-boards/arm/stm32/stm32f4discovery directory.
-
-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*
- CTS PA11*
- RTS PA12*
- RX PA10, PB7
- TX PA9, PB6*
-USART2
- CK PA4*, PD7
- CTS PA0*, PD3*
- RTS PA1*, PD4
- RX PA3*, PD6*
- TX PA2*, PD5
-USART3
- CK PB12*, PC12, PD10*
- CTS PB13*, PD11*
- RTS PB14*, PD12*
- RX PB11*, PC11, PD9*
- TX PB10*, PC10*, PD8*
-UART4
- RX PA1*, PC11
- TX PA0*, PC10*
-UART5
- RX PD2
- TX PC12
-USART6
- CK PC8, PG7*
- CTS PG13*, PG15*
- RTS PG12*, PG8*
- RX PC7*, PG9
- TX PC6*, PG14*
-UART7
- RX PE7*, PF6
- TX PE8*, PF7*
-
- * 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*, 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 6 in the STM32F429I-DISCO User Guide). The rest are
- free I/O pins (This need to be updated. They are incorrect!)
-** Port I 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
-
-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
-
-STM32F429I-DISCO-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=STM32F429I-DISCO (for the STM32F429I-DISCO 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, SDRAM 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_EXTERNAL_RAM - Indicates that SDRAM is available via the
- FMC (as opposed to an LCD or FLASH).
-
- CONFIG_HEAP2_BASE - The base address of the SDRAM in the FMC address space (hex)
-
- CONFIG_HEAP2_SIZE - The size of the SDRAM in the FMC address space (decimal)
-
- CONFIG_ARCH_FPU - The STM32F429I-DISCO supports a floating point unit (FPU)
-
- CONFIG_ARCH_FPU=y
-
- CONFIG_ARCH_LEDS - Use LEDs to show state. Unique to boards that
- have LEDs
-
- 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_FMC
-
- 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
-
- STM32F429I-DISCO 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
-
- STM32F429I-DISCO 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.
-
- STM32F429I-DISCO 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.
-
- STM32F429I-DISCO 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 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
diff --git a/boards/arm/stm32/stm32f429i-disco/configs/fb/README.txt b/boards/arm/stm32/stm32f429i-disco/configs/fb/README.txt
deleted file mode 100644
index 0861763786..0000000000
--- a/boards/arm/stm32/stm32f429i-disco/configs/fb/README.txt
+++ /dev/null
@@ -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
diff --git a/boards/arm/stm32/stm32f4discovery/README.txt b/boards/arm/stm32/stm32f4discovery/README.txt
deleted file mode 100644
index 45abd6aaef..0000000000
--- a/boards/arm/stm32/stm32f4discovery/README.txt
+++ /dev/null
@@ -1,2427 +0,0 @@
-README
-======
-
-This README discusses issues unique to NuttX configurations for the
-STMicro STM32F4Discovery development board featuring the STM32F407VGT6
-MCU. The STM32F407VGT6 is a 168MHz Cortex-M4 operation with 1Mbit Flash
-memory and 128kbytes. The board features:
-
- - On-board ST-LINK/V2 for programming and debugging,
- - LIS302DL, ST MEMS motion sensor, 3-axis digital output accelerometer,
- - MP45DT02, ST MEMS audio sensor, omni-directional digital microphone,
- - CS43L22, audio DAC with integrated class D speaker driver,
- - Four user LEDs and two push-buttons,
- - USB OTG FS with micro-AB connector, and
- - Easy access to most MCU pins.
-
-Refer to http://www.st.com/internet/evalboard/product/252419.jsp for
-further information about this board.
-
-NOTE: This port was developed on the original board, order code
-STM32F4DISCOVERY. That board has been replaced with the new order code
-STM32F407VG-DISC1. The new version of the board differs in at least these
-ways:
-
- - The ST-LINK/V2 has been updated to ST-LINK/V2-A on STM32F407G-DISC1
- with a Virtual Com port and Mass storage.
- - LIS3DSH ST MEMS 3-axis accelerometer
-
-Contents
-========
-
- - LEDs
- - RGB LED Driver
- - PWM
- - UARTs
- - Timer Inputs/Outputs
- - Nintendo Wii Nunchuck
- - Quadrature Encoder
- - FPU
- - STM32F4DIS-BB
- - RTC DS1307
- - SSD1289
- - UG-2864AMBAG01 / UG-2864HSWEG01
- - NiceRF LoRa (2AD66-LoRa V2)
- - Ethernet SPI Module ENC28J60
- - HCI UART
- - STM32F4Discovery-specific Configuration Options
- - BASIC
- - Testing LLVM LIBC++ with NuttX
- - Configurations
-
-LEDs
-====
-
-The STM32F4Discovery board has four LEDs; green, orange, red and blue 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 LED3 LED4
- green orange red blue
- ------------------- ----------------------- ------- ------- ------- ------
- 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** ON N/C N/C OFF
- LED_SIGNAL In a signal handler*** 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)
-
- * 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
- ** 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.
-*** LED2 may also flicker normally if signals are processed.
-
-RGB LED Driver
-==============
-
-Alan Carvalho de Assis has used the STM32F4-Discovery to drive an RGB LED
-using PWM output. The external RGB connected this way:
-
- R = TIM1 CH1 on PE9
- G = TIM2 CH2 on PA1
- B = TIM3 CH3 on PB0
-
-The RGB LED driver that uses PWM to control the red, green, and blue color
-components can be enabled with the following configuration settings:
-
- +CONFIG_RGBLED=y
-
- +CONFIG_PWM
-
- +CONFIG_STM32_TIM1
- +CONFIG_STM32_TIM2
- +CONFIG_STM32_TIM3
- +CONFIG_STM32_TIM1_PWM=y
- +CONFIG_STM32_TIM1_MODE=0
- +CONFIG_STM32_TIM1_CHANNEL=1
- +CONFIG_STM32_TIM1_CHMODE=0
- +CONFIG_STM32_TIM2_PWM=y
- +CONFIG_STM32_TIM2_MODE=0
- +CONFIG_STM32_TIM2_CHANNEL=2
- +CONFIG_STM32_TIM2_CHMODE=0
- +CONFIG_STM32_TIM3_PWM=y
- +CONFIG_STM32_TIM3_MODE=0
- +CONFIG_STM32_TIM3_CHANNEL=3
- +CONFIG_STM32_TIM3_CHMODE=0
-
-PWM
-===
-
-The STM32F4Discovery has no real on-board PWM devices, but the board can be
-configured to output a pulse train using TIM4 CH2 on PD3. This pin is
-available next to the audio jack.
-
-UARTs
-=====
-
-UART/USART PINS
----------------
-
-USART1
- CK PA8
- CTS PA11*
- RTS PA12*
- RX PA10*, PB7
- TX PA9*, PB6*
-USART2
- CK PA4*, PD7
- CTS PA0*, PD3
- RTS PA1, PD4*
- RX PA3, PD6
- TX PA2, PD5*
-USART3
- CK PB12, PC12*, PD10
- CTS PB13, PD11
- RTS PB14, PD12*
- RX PB11, PC11, PD9
- TX PB10*, PC10*, PD8
-UART4
- RX PA1, PC11
- TX PA0*, PC10*
-UART5
- RX PD2
- TX PC12*
-USART6
- CK PC8, PG7**
- CTS PG13**, PG15**
- RTS PG12**, PG8**
- RX PC7*, PG9**
- TX PC6, PG14**
-
- * Indicates pins that have other on-board functions and should be used only
- with care (See table 5 in the STM32F4Discovery User Guide). The rest are
- free I/O pins.
-** Port G pins are not supported by the MCU
-
-Default USART/UART Configuration
---------------------------------
-
-USART2 is enabled in most configurations (see */defconfig). RX and TX are
-configured on pins PA3 and PA2, respectively (see include/board.h).
-
-These pins selections, however, conflict with Ethernet pin usage on the
-STM32F4DIS-BB base board. The STM32F4DIS-BB base board provides RS-232
-drivers and a DB9 connector for USART6. USART6 is the preferred serial
-console for use with the STM32F4DIS-BB.
-
-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 STM32F4Discovery User Guide). The rest are
- free I/O pins.
-** Port H pins are not supported by the MCU
-
-Nintendo Wii Nunchuck:
-======================
-
- There is a driver on NuttX to support Nintendo Wii Nunchuck Joystick. If you
- want to use it please select these options:
-
- - Enable the I2C1 at System Type -> STM32 Peripheral Support, it will enable:
-
- CONFIG_STM32_I2C1=y
-
- - Enable to Custom board/driver initialization at RTOS Features -> RTOS hooks
-
- CONFIG_BOARD_LATE_INITIALIZE=y
-
- - Enable the I2C Driver Support at Device Drivers, it will enable this symbol:
-
- CONFIG_I2C=y
-
- - Nintendo Wii Nunchuck Joystick at Device Drivers -> [*] Input Device Support
-
- CONFIG_INPUT=y
- CONFIG_INPUT_NUNCHUCK=y
-
- - Enable the Nunchuck joystick example at Application Configuration -> Examples
-
- CONFIG_EXAMPLES_NUNCHUCK=y
- CONFIG_EXAMPLES_NUNCHUCK_DEVNAME="/dev/nunchuck0"
-
- You need to connect GND and +3.3V pins from Nunchuck connector to GND and 3V
- of stm32f4discovery respectively (Nunchuck also can work connected to 5V, but
- I don't recommend it). Connect I2C Clock from Nunchuck to SCK (PB6) and the
- I2C Data to SDA (PB9).
-
-Quadrature Encoder:
-===================
-
- The nsh configuration has been used to test the Quadrture Encoder
- (QEncoder, QE) with the following modifications to the configuration
- file:
-
- - These setting enable support for the common QEncode upper half driver:
-
- CONFIG_BOARD_LATE_INITIALIZE=y
-
- CONFIG_SENSORS=y
- CONFIG_SENSORS_QENCODER=y
-
- - The timer 2 needs to be enabled:
-
- CONFIG_STM32_TIM2=y
-
- - This is a board setting that selected timer 2 for use with the
- quadrature encode:
-
- CONFIG_STM32F4DISCO_QETIMER=2
-
- - These settings enable the STM32 Quadrature encoder on timer 2:
-
- CONFIG_STM32_TIM2_QE=y
- CONFIG_STM32_TIM4_QECLKOUT=2800000
- CONFIG_STM32_QENCODER_FILTER=y
- CONFIG_STM32_QENCODER_SAMPLE_EVENT_6=y
- CONFIG_STM32_QENCODER_SAMPLE_FDTS_4=y
-
- - These settings enable the test case at apps/examples/qencoder:
-
- CONFIG_EXAMPLES_QENCODER=y
- CONFIG_EXAMPLES_QENCODER_DELAY=100
- CONFIG_EXAMPLES_QENCODER_DEVPATH="/dev/qe0"
-
- In this configuration, the QEncoder inputs will be on the TIM2 inputs of
- PA15 and PA1 (CH1 and CH2 respectively).
-
- You can also use QEncoder with other timers, but keep in mind that only TIM2
- and TIM5 are 32bits timers, all other timers are 16-bit then the QE counter
- will overflow after 65535.
-
- If TIM4 is selected, then PB6 and PB7 will be used for CH1 and CH2.
- If TIM8 is selected, then PC6 and PI5 will be used for CH1 and CH2.
-
-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
-
-STM32F4DIS-BB
-=============
-
-On-board PIO usage:
-
- ---------- ------------- ------------------------------
- PIO SIGNAL FUNCTION
- ---------- ------------- ------------------------------
- PB11 TXEN LAN8720
- PB12 TXD0
- PB13 TXD1
- PC4 RXD0/MODE0
- PC5 RXD1/MODE1
- PA7 RXDR/PHYAD0
- PA2 MDIO
- PC1 MDC
- PA1 NINT/REFCLK0
- PE2 NRST
- ---------- ------------- ------------------------------
- PC6 D2 DCMI
- PC7 D3
- PE0 D4
- PE1 D5
- PE4 D6
- PB6 D7
- PE5 D8
- PE6 D9
- PA6 PCLK
- PA4 HS
- PB7 VS
- PD6 PWR_EN
- PD12 RST
- PB9 SDA
- PB8 SCL
- ---------- ------------- ------------------------------
- USART6_TX T1IN SP3232EEY-L
- USART6_RX T2OUT
- ---------- ------------- ------------------------------
- PB15 NCD MicroSD
- PC9 DAT1
- PC8 DAT0
- PC12 CLK
- PD2 CMD
- PC11 CD/DAT3
- PC10 DAT2
- ---------- ------------- ------------------------------
-
-RTC DS1307
-==========
-
-It is possible to use a low cost extern DS1307 RTC to keep date and time
-always updated. These DS1307 RTC modules come with a 3V button battery, then
-even when the board is turned OFF the Date/Time registers keep running.
-
-You can connect the module this way (STM32F4Discovery to DS1307 board): GND
-to GND; 5V to VCC; PB9 to SDA; PB6 to SCL. In the NuttX menuconfig you need
-to enable these options:
-
-System Type --->
- STM32 Peripheral Support --->
- [*] I2C1
-
-Device Drivers --->
- Timer Driver Support --->
- [*] RTC Driver Support --->
- -*- Date/Time RTC Support
- [*] External RTC Support
- [*] DS130x/DS323x RTC Driver
- Maxim Integrated RTC (DS1307) --->
- (100000) DS1307/DS323x I2C frequency
-
-Application Configuration --->
- NSH Library --->
- Disable Individual commands --->
- [ ] Disable date ( <-- Deselect )
-
-It is also a good idea to enable the DEBUG to RTC initially, you will see:
-
-ABCDF
-stm32_ds1307_init: Initialize I2C1
-stm32_ds1307_init: Bind the DS1307 RTC driver to I2C1
-rtc_dumptime: Returning:
-rtc_dumptime: tm_sec: 00000039
-rtc_dumptime: tm_min: 00000001
-rtc_dumptime: tm_hour: 00000009
-rtc_dumptime: tm_mday: 00000016
-rtc_dumptime: tm_mon: 00000008
-rtc_dumptime: tm_year: 00000077
-
-NuttShell (NSH)
-nsh> date
-Sep 22 09:01:58 2019
-
-SSD1289
-=======
-
-I purchased an LCD display on eBay from China. The LCD is 320x240 RGB565 and
-is based on an SSD1289 LCD controller and an XPT2046 touch IC. The pin out
-from the 2x16 connect on the LCD is labelled as follows:
-
-LCD CONNECTOR: SSD1289 MPU INTERFACE PINS:
-
- +------+------+ DEN I Display enable pin
-1 | GND | 3V3 | 2 VSYNC I Frame synchronization signal
- +------+------+ HSYNC I Line synchronization signal
-3 | D1 | D0 | 4 DOTCLK I Dot clock and OSC source
- +------+------+ DC I Data or command
-5 | D3 | D2 | 6 E (~RD) I Enable/Read strobe
- +------+------+ R (~WR) I Read/Write strobe
-7 | D5 | D4 | 8 D0-D17 IO For parallel mode, 8/9/16/18 bit interface
- +------+------+ WSYNC O RAM write synchronizatin output
-9 | D7 | D6 | 10 ~RES I System reset
- +------+------+ ~CS I Chip select of serial interface
-11 | D9 | D8 | 12 SCK I Clock of serial interface
- +------+------+ SDI I Data input in serial mode
-13 | D11 | D10 | 14 SDO O Data output in serial moce
- +------+------+
-15 | D13 | D12 | 16
- +------+------+
-17 | D15 | D14 | 18
- +------+------+
-19 | RS | CS | 20
- +------+------+
-21 | RD | WR | 22 NOTES:
- +------+------+
-23 |BL_CNT|RESET | 24 BL_CNT is the PWM backlight level control.
- +------+------+
-25 |TP_RQ |TP_S0 | 26 These pins are for the touch panel: TP_REQ
- +------+------+ TP_S0, TP_SI, TP_SCX, and TP_CS
-27 | NC |TP_SI | 28
- +------+------+
-29 | NC |TP_SCX| 30
- +------+------+
-31 | NC |TP_CS | 32
- +------+------+
-
-MAPPING TO STM32 F4:
-
- ---------------- -------------- ----------------------------------
- STM32 FUNCTION LCD PIN STM32F4Discovery PIN
- ---------------- -------------- ----------------------------------
- FSMC_D0 D0 pin 4 PD14 P1 pin 46 Conflict (Note 1)
- FSMC_D1 D1 pin 3 PD15 P1 pin 47 Conflict (Note 2)
- FSMC_D2 D2 pin 6 PD0 P2 pin 36 Free I/O
- FSMC_D3 D3 pin 5 PD1 P2 pin 33 Free I/O
- FSMC_D4 D4 pin 8 PE7 P1 pin 25 Free I/O
- FSMC_D5 D5 pin 7 PE8 P1 pin 26 Free I/O
- FSMC_D6 D6 pin 10 PE9 P1 pin 27 Free I/O
- FSMC_D7 D7 pin 9 PE10 P1 pin 28 Free I/O
- FSMC_D8 D8 pin 12 PE11 P1 pin 29 Free I/O
- FSMC_D9 D9 pin 11 PE12 P1 pin 30 Free I/O
- FSMC_D10 D10 pin 14 PE13 P1 pin 31 Free I/O
- FSMC_D11 D11 pin 13 PE14 P1 pin 32 Free I/O
- FSMC_D12 D12 pin 16 PE15 P1 pin 33 Free I/O
- FSMC_D13 D13 pin 15 PD8 P1 pin 40 Free I/O
- FSMC_D14 D14 pin 18 PD9 P1 pin 41 Free I/O
- FSMC_D15 D15 pin 17 PD10 P1 pin 42 Free I/O
- FSMC_A16 RS pin 19 PD11 P1 pin 27 Free I/O
- FSMC_NE1 ~CS pin 10 PD7 P2 pin 27 Free I/O
- FSMC_NWE ~WR pin 22 PD5 P2 pin 29 Conflict (Note 3)
- FSMC_NOE ~RD pin 21 PD4 P2 pin 32 Conflict (Note 4)
- PC6 RESET pin 24 PC6 P2 pin 47 Free I/O
- Timer output BL_CNT pin 23 (to be determined)
- ---------------- -------------- ----------------------------------
-
- 1 Used for the RED LED
- 2 Used for the BLUE LED
- 3 Used for the RED LED and for OTG FS Overcurrent. It may be okay to use
- for the parallel interface if PC0 is held high (or floating). PC0 enables
- the STMPS2141STR IC power switch that drives the OTG FS host VBUS.
- 4 Also the reset pin for the CS43L22 audio Codec.
-
-NOTE: The configuration to test this LCD configuration is available at
-boards/arm/stm32/stm32f4discovery/nxlines. As of this writing, I have not seen the
-LCD working so I probably have some things wrong.
-
-I might need to use a bit-banging interface. Below is the pin configuration
-of a similar LCD to support a (write-only), bit banging interface:
-
- LCD PIN BOARD CONNECTION
- LEDA 5V
- VCC 5V
- RD 3.3V
- GND GND
- DB0-7 Port C pins configured as outputs
- DB8-15 Port A pins configured as outputs
- RS Pin configured as output
- WR Pin configured as output
- CS Pin configured as output
- RSET Pin configured as output
-
-The following summarize the bit banging operations:
-
- /* Rese the LCD */
- void Reset(void)
- {
- Set RSET output
- delay
- Clear RSET output
- delay
- Set RSET output
- }
-
- /* Write 16-bits of whatever */
- void Write16(uint8_t ms, uint8_t ls)
- {
- Set port A to ms
- Set port B to ls
-
- Clear WR pin
- Set WR pin
- }
-
- /* Set the index register to an LCD register address */
- void Index(uint8_t address)
- {
- Clear RS
- Write16(0, address);
- }
-
- /* Write data to the LCD register or GRAM memory */
- void WriteData(uin16_t data)
- {
- Set RS
- Write16(data >> 8, data & 0xff);
- }
-
- /* Write to a register */
- void WriteRegister(uint8_t address, uint16_t data)
- {
- Index(address);
- WriteData(data);
- }
-
-UG-2864AMBAG01 / UG-2864HSWEG01
-===============================
-
-I purchased an OLED display on eBay. The OLED is 128x64 monochrome and
-is based on an UG-2864AMBAG01 OLED controller. The OLED can run in either
-parallel or SPI mode. I am using SPI mode. In SPI mode, the OLED is
-write only so the driver keeps a 128*64/8 = 1KB framebuffer to remember
-the display contents:
-
-Here is how I have the OLED connected. But you can change this with the
-settings in include/board.h and src/stm324fdiscovery.h. Connector
-pinout for the UG-2864AMBAG01 is specific to the theO.net display board
-that I am using:
-
- --------------------------+----------------------------------------------
- Connector CON10 J1: | STM32F4Discovery
- --------------+-----------+----------------------------------------------
- CON10 J1: | CON20 J2: | P1/P2:
- --------------+-----------+----------------------------------------------
- 1 3v3 | 3,4 3v3 | P2 3V
- 3 /RESET | 8 /RESET | P2 PB6 (Arbitrary selection)
- 5 /CS | 7 /CS | P2 PB7 (Arbitrary selection)
- 7 A0 | 9 A0 | P2 PB8 (Arbitrary selection)
- 9 LED+ (N/C) | ----- | -----
- 2 5V Vcc | 1,2 Vcc | P2 5V
- 4 DI | 18 D1/SI | P1 PA7 (GPIO_SPI1_MOSI == GPIO_SPI1_MOSI_1 (1))
- 6 SCLK | 19 D0/SCL | P1 PA5 (GPIO_SPI1_SCK == GPIO_SPI1_SCK_1 (1))
- 8 LED- (N/C) | ----- | ------
- 10 GND | 20 GND | P2 GND
- --------------+-----------+----------------------------------------------
- (1) Required because of on-board MEMS
- -------------------------------------------------------------------------
-
-Darcy Gong recently added support for the UG-2864HSWEG01 OLED which is also
-an option with this configuration. I have little technical information about
-the UG-2864HSWEG01 interface (see boards/arm/stm32/stm32f4discovery/src/up_ug2864hsweg01.c).
-
-NiceRF LoRa (2AD66-LoRa V2)
-===========================
-
-It is possible to wire an external LoRa module to STM32F4Discovery board.
-
-First connect the GND and VCC (to 3.3V) and then connect the SCK label to PA5,
-connect the MISO to PA6, connect the MOSI to PA7, connect the NSS to PD8,
-connect DIO0 to PD0 and finally connect NRESET to PD4.
-
-Ethernet SPI Module ENC28J60
-============================
-
-You can use an external Ethernet SPI Module ENC28J60 with STM32F4Discovery board.
-
-First connect the GND and VCC (to 3.3V). Note: according with ENC28J60 datasheet
-the Operating Voltage should be between 3.1V to 3.6V, but STM32F4Discover only
-supply 3.0V. You can modify your board to supply 3.3V: just remove the D3 diode
-and short-circuit the board pads where it was soldered).
-
-Connect the SCK label to PA5, connect the SO to PA6, connect the SI to PA7,
-connect the CS to PA4, connect RST to PE1 and finally connect INT to PE4.
-
-The next step is to enable the ENC28J60 in the menuconfig ("make menuconfig")
-and the necessary Network configuration, you can use the
-boards/arm/stm32/fire-stm32v2/configs/nsh/defconfig as reference.
-
-HCI UART
-========
-
-BT860
------
-
- I have been testing with the DVK_BT960_SA board via J10 as follows:
-
- DVK_BT860-SA J10 STM32F4 Discovery P1
- pin 1 GND P1 pin 49
- pin 2 Module_RTS_O USART3_CTS PB13, P1 pin 37
- pin 3 N/C
- pin 4 Module_RX_I USART3_TXD PB10, P1 pin 34
- pin 5 Module_TX_O USART3_RX PB11, P1 pin 35
- pin 6 Module_CTS_I USART3_RTS PB14, P1 pin 38
-
- Due to conflicts, USART3 many not be used if Ethernet is enabled with
- the STM32F4DIS-BB base board:
-
- PB-11 conflicts with Ethernet TXEN
- PB-13 conflicts with Ethernet TXD1
-
- If you need to use the HCI uart with Ethernet, then you will need to
- configure a new U[S]ART and/or modify the pin selections in
- include/board.h.
-
-CC2564
-------
-
- [To be provided]
-
- One confusing thing compared with the BT860 is in the naming of the pins
- at the 4-pin RS232 TTL interface: The BT860 uses BT860-centric naming,
- the Rx pin is for BT860 receive and needs to connect with the STM32 Tx
- pin, the Tx pin is for BT860 transmit an needs to be connected with the
- STM32 Rx pin, etc. The CC2564, on the hand, uses host-centric naming so
- that the CC2564 Rx pin connects to the STM32 Rx pin, Tx to Tx pin, etc.
-
-Troubleshooting
----------------
-
- First you should enable CONFIG_DEBUG_WIRELESS_ERR, WARN, and INFO options
- so that you can see what the driver is doing.
-
- The bring-up problems that I encountered mostly involved setting up the
- 4-wire UART interface: Remember to cross Rx/Tx and RTS/CTS. The active
- state for RTS and CTS is low. For bringup of the BT860, I used a Seleae
- logic analyzer connected to the Tx, Rx, RTS, and CTS pins. When the
- BT860 is working correctly you would see this:
-
- 1. All signals high initially,
- 2. When NuttX starts, RTS goes low
- 3. The BT860 sees RTS go low and responds by setting CTS low after a
- delay. This is when it selects between USB and UART.
- 4. After another delay, the STM32 sends the 4 Tx bytes.
- 5. The BT860 responds with 3 bytes.
- 6. If successful, additional commands and responses follow.
-
- Some of these steps may be different for other HCI UARTs. Steps 4-5 are
- the reset sequence. the 4 Tx bytes comes from the code in the function
- hci_initialize() in the file wireless/bluetooth/bt_hcicore.c:
-
- /* Send HCI_RESET */
-
- bt_hci_cmd_send(BT_HCI_OP_RESET, NULL);
-
- The code is actually working one command ahead. It has already queued up
- the reset command and is requesting the HCI UART device features while the
- reset command is being sent:
-
- ret = bt_hci_cmd_send_sync(BT_HCI_OP_READ_LOCAL_FEATURES, NULL, &rsp);
- if (ret < 0)
- {
- wlerr("ERROR: bt_hci_cmd_send_sync failed: %d\n", ret);
- return ret;
- }
-
- A common failure is to see a timeout error (-116) due to a Tx flow control
- failure (CTS is high). There is no timeout on the first command, the
- timeout actually occurs on the second command in bt_hci_cmd_send_sync():
-
- do
- {
- /* The timed wait could also be awakened by a signal */
-
- ret = nxsem_timedwait(&sync_sem, &abstime);
- }
- while (ret == -EINTR);
-
- The above times out and generates the 116 error.
-
- In the case of the timeout, the second command is stuck in the message queue
- is never processed because the Tx thread is waiting for the BT_HCI_OP_RESET
- command to complete. It is blocked in hci_tx_thread() kernel thread.
-
- The Tx occurs on a kernel thread. The Tx send of the first command causes
- the hci_tx_kthread() to block. It waits here until what the HCI UART
- receives the command and responses with the command complete event:
-
- /* Wait until ncmd > 0 */
-
- do
- {
- ret = nxsem_wait(&g_btdev.ncmd_sem);
- }
- while (ret == -EINTR);
-
- bt_hci_cmd_send() will block on the first BT_HCI_OP_RESET until until it
- gets the 3-byte event (BT_EVT) that indicates that the command was
- completed and provides the command status. See the function
- hci_command_complete() where it posts g_btdev.ncmd_sem.
-
- g_btdev.ncmd = 1;
- nxsem_post(&g_btdev.ncmd_sem);
-
- You can see such a hange in the wireless debug output
-
- bt_hci_cmd_send: opcode 0c03 len 3 <<< BT_HCI_OP_RESET command is queue
- hci_tx_kthread: Sending command 0c03 buf 20002a40 to driver <<< Sent to driver from the Tx thread
- hciuart_write: config 801d924 buffer 20002760 buflen 4 <<< Goes to STM32 HCI UART driver
-
- bt_hci_cmd_send_sync: opcode 1003 len 3 <<< next command is queued.
- hciuart_copytotxfifo: txhead 1 txtail 4 nbytes 1 <<< One byte of first command written to Tx HR
- hciuart_enableints: CR1 000020ac CR2 00000301 <<< Tx interrupts enabled
-
-!!!! No Tx interrupts, probably because of Tx flow control (CTS is high) !!!
-
- hci_initialize: ERROR: bt_hci_cmd_send_sync failed: -116 <<< Times out on second message
-
-STM32F4Discovery-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=STM32F4Discovery (for the STM32F4Discovery 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 RAM
-
- CONFIG_RAM_SIZE=0x00010000 (64Kb)
-
- CONFIG_RAM_START - The start address of installed RAM
-
- CONFIG_RAM_START=0x20000000
-
- CONFIG_STM32_CCMEXCLUDE - Exclude CCM SRAM from the HEAP
-
- CONFIG_ARCH_FPU - The STM32F4Discovery supports a floating point unit (FPU)
-
- CONFIG_ARCH_FPU=y
-
- CONFIG_ARCH_LEDS - Use LEDs to show state. Unique to boards that
- have LEDs
-
- 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
-
- STM32F4Discovery 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
-
- STM32F4Discovery 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.
-
- STM32F4Discovery 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.
-
- STM32F4Discovery 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.
-
-BASIC
-=====
- I have used the stm32f4discovery/nsh configuration to test Michael Haardt's
- BASIC interpreter that you can find at apps/interpreters/bas.
-
- Bas is an interpreter for the classic dialect of the programming language
- BASIC. It is pretty compatible to typical BASIC interpreters of the 1980s,
- unlike some other UNIX BASIC interpreters, that implement a different
- syntax, breaking compatibility to existing programs. Bas offers many ANSI
- BASIC statements for structured programming, such as procedures, local
- variables and various loop types. Further there are matrix operations,
- automatic LIST indentation and many statements and functions found in
- specific classic dialects. Line numbers are not required.
-
- There is also a test suite for the interpreter that can be found at
- apps/examples/bastest.
-
- Configuration
- -------------
- Below are the recommended configuration changes to use BAS with the
- stm32f4discovery/nsh configuration:
-
- Dependencies:
- CONFIG_LIBC_EXECFUNCS=y : exec*() functions are required
- CONFIG_LIBM=y : Some floating point library is required
- CONFIG_LIBC_FLOATINGPOINT=y : Floating point printing support is required
- CONFIG_LIBC_TMPDIR="/tmp" : Writable temporary files needed for some commands
- CONFIG_FS_FAT=y : With FAT you create a RAMDISK at /tmp
- CONFIG_FAT_LFN=y : FAT is difficult to use with long file names
-
- Enable the BASIC interpreter. Other default options should be okay:
- CONFIG_INTERPRETERS_BAS=y : Enables the interpreter
- CONFIG_INTERPRETER_BAS_VT100=y
-
- The BASIC test suite can be included:
- CONFIG_FS_ROMFS=y : ROMFS support is needed
- CONFIG_EXAMPLES_BASTEST=y : Enables the BASIC test setup
- CONFIG_EXAMPLES_BASTEST_DEVMINOR=0
- CONFIG_EXAMPLES_BASTEST_DEVPATH="/dev/ram0"
-
- Usage
- -----
- This setup will initialize the BASIC test (optional): This will mount
- a ROMFS file system at /mnt/romfs that contains the BASIC test files:
-
- nsh> bastest
- Registering romdisk at /dev/ram0
- Mounting ROMFS filesystem at target=/mnt/romfs with source=/dev/ram0
- nsh>
-
- These steps will create and mount a RAMDISK at /tmp (required only for a
- few BASIC commands). This will create a RAMDISK device at /dev/ram1 with
- size = 512 * 64 = 32KiB and mount it at /tmp:
-
- nsh> mkrd -m 1 -s 512 64
- nsh> mkfatfs /dev/ram1
- nsh> mount -t vfat /dev/ram1 /tmp
- nsh>
-
- The interactive interpreter is started like:
-
- nsh> bas
- bas 2.4
- Copyright 1999-2014 Michael Haardt.
- This is free software with ABSOLUTELY NO WARRANTY.
- >
-
- Ctrl-D exits the interpreter.
-
- The test programs can be ran like this:
-
- nsh> bastest
- Registering romdisk at /dev/ram0
- Mounting ROMFS filesystem at target=/mnt/romfs with source=/dev/ram0
- nsh> bas /mnt/romfs/test01.bas
- 1
- hello
- 0.0002
- 0.0000020
- 0.0000002
-
- nsh>
-
- Or you can load a test into memory and execute it interactively:
-
- nsh> bas
- bas 2.4
- Copyright 1999-2014 Michael Haardt.
- This is free software with ABSOLUTELY NO WARRANTY.
- > load "/mnt/romfs/test01.bas"
- > run
- 1
- hello
- 0.0002
- 0.0000020
- 0.0000002
- >
-
-Testing LLVM LIBC++ with NuttX
-==============================
-
-You can use LLVM LIBC++ on NuttX to get a C++ compiler with C++11 features.
-Follow these steps to get it working:
-
-Clone the needed repositories:
-
- $ git clone https://www.bitbucket.org/acassis/libcxx
-
- $ git clone https://www.bitbucket.org/nuttx/apps
-
- $ git clone https://www.bitbucket.org/nuttx/nuttx
-
-Install the libcxx files on NuttX:
-
- $ cd libcxx
-
- $ ./install.sh ../nuttx
- Installing LLVM/libcxx in the NuttX source tree
- Installation succeeded
-
-Enter inside NuttX and compile it:
-
- $ cd ../nuttx
-
- $ tools/configure.sh stm32f4discovery:testlibcxx
- Copy files
- Refreshing...
-
- $ ls -l nuttx.bin
- -rwxrwxr-x 1 alan alan 58112 Ago 8 11:08 nuttx.bin
-
-Plug the MiniUSB cable in the STM32F4Discovery board and flash the firmware:
-
- $ sudo openocd -f interface/stlink-v2.cfg -f target/stm32f4x.cfg -c init \
- -c "reset halt" -c "flash write_image erase nuttx.bin 0x08000000"
-
- ...
-
- Info : device id = 0x10036413
- Info : flash size = 1024kbytes
- target halted due to breakpoint, current mode: Thread
- xPSR: 0x61000000 pc: 0x20000046 msp: 0x20001d60
- wrote 65536 bytes from file nuttx.bin in 2.959432s (21.626 KiB/s)
-
-Connect the USB/Serial 3.3V dongle to PA2(board TX) and PA3(board RX) use
-minicom or other serial console configured to 115200 8n1.
-
-Press Reset pin of the board and you will see:
-
- NuttShell (NSH)
- nsh> ?
- help usage: help [-v] [<cmd>]
-
- [ cmp free mh source usleep
- ? dirname help mv sleep xd
- basename dd hexdump mw test
- break echo kill pwd time
- cat exec ls rm true
- cd exit mb rmdir uname
- cp false mkdir set unset
-
- Builtin Apps:
- helloxx
-
- nsh>
-
-Just type helloxx:
-
- nsh> helloxx
- helloxx_main: Saying hello from the dynamically constructed instance
- CHelloWorld::HelloWorld: Hello, World!!
- helloxx_main: Saying hello from the instance constructed on the stack
- CHelloWorld::HelloWorld: Hello, World!!
- helloxx_main: Saying hello from the statically constructed instance
- CHelloWorld::HelloWorld: Hello, World!!
-
- nsh>
-
-Configurations
-==============
-
-Common Information
-------------------
-
-Each STM32F4Discovery configuration is maintained in a sub-directory and
-can be selected as follow:
-
- tools/configure.sh STM32F4Discovery:<subdir>
-
-Where <subdir> is one of the sub-directories listed in the next paragraph
-
- NOTES (common for all configurations):
-
- 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.
-
-Configuration Sub-directories
--------------------------
-
- audio:
- -----
-
- This configuration is a variant of the NSH configuration used for
- demonstrating PCM audio using the CS43L22 stereo DAC/amplifier on board
- the STM32F4 Discovery and the STM32 I2S DMA interface. It uses the
- file player at apps/system/nxplayer. The serial console is on USART2.
-
- The original CS43L22 and STM32 I2S drivers were contribued by Taras
- Drozdovsky in May of 2017. The audio configuration was contributed by
- Alan Carvalho de Assis and derives, in part, from the work of Taras at
- https://github.com/tdrozdovskiy/CS43L22-Audio-driver.
-
- Usage instructions from the README file at the location:
-
- 1. Prepare USB flash storage. This configuration depends on .WAV files
- provided to the system via a USB flash stick. There are some sample
- audio files at https://github.com/tdrozdovskiy/CS43L22-Audio-driver
- and these steps will put those sample .WAV files onto the USB flash:
-
- a. Format the USB flash storage into FAT. For example by next command
-
- $ mkfs.vfat /dev/sdb1
-
- b. Create folder /music
-
- $ mkdir music
-
- c. Copy files from /audio_samples/ to /music folder of USB flash storage
-
- $ cp <repo>/audio_samples/* /mnt/media/music/
-
- You should be able to use either Taras' .wav files like that or, if
- you like, your own compatible .wav files.
-
- 2. Example usage CS43L22 Audio driver
-
- a. Power On or reset the STM32F4 Discovery board. We can see the NuttX
- command line prompt:
-
- NuttShell (NSH)
- nsh>
-
- b. Mount the usb flash device into our file system
-
- nsh> mount -t vfat /dev/sda/ /mnt/sda
-
- c. Start the NxPlayer program and Enter the help command to view the list
- of commands
-
- nsh> nxplayer
- NxPlayer version 1.04
- h for commands, q to exit
- nxplayer> h
- NxPlayer commands
- ================
- balance d% : Set balance percentage (< 50% means more left)
- device devfile : Specify a preferred audio device
- h : Display help for commands
- help : Display help for commands
- mediadir path : Change the media directory
- play filename : Play a media file
- pause : Pause playback
- resume : Resume playback
- stop : Stop playback
- tone freq secs : Produce a pure tone
- q : Exit NxPlayer
- quit : Exit NxPlayer
- volume d% : Set volume to level specified
-
- d. Play the test sample track (cu44k.wav - 44100Hz, 16bit, stereo).
-
- nxplayer> play cu44k.wav
-
- e. Set the volume value to 50%.
-
- nxplayer> volume 50
-
- f. Stop the current track and play another one
-
- nxplayer> stop
- nxplayer> play hn.wav
-
- cxxtest:
- -------
-
- The C++ standard library test at apps/testing/cxxtest configuration. This
- test is used to verify the uClibc++ port to NuttX. This configuration may
- be selected as follows:
-
- tools/configure.sh sim:cxxtest
-
- NOTES:
-
- 1. Before you can use this example, you must first install the uClibc++
- C++ library. This is located outside of the NuttX source tree in the
- NuttX uClibc++ GIT repository. See the README.txt file there for
- instructions on how to install uClibc++
-
- 2. Ideally, you should build with a toolchain based on GLIBC or
- uClibc++. It you use a toolchain based on newlib, you may see
- an error like the following:
-
- .../lib/libsupc++.a(vterminate.o): In function `__gnu_cxx::__verbose_terminate_handler()':
- vterminate.cc:(....): undefined reference to `_impure_ptr'
-
- Here is a quick'n'dirty fix:
-
- 1. Get the directory where you can find libsupc++:
-
- arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -print-file-name=libsupc++.a
-
- 2. Go to that directory and save a copy of vterminate.o (in case you
- want to restore it later:
-
- cd <the-directory-containing-libsupc++.a>
- arm-none-eabi-ar.exe -x libsupc++.a vterminate.o
-
- 3. Then remove vterminate.o from the library. At build time, the
- uClibc++ package will provide a usable replacement vterminate.o.
-
- Steps 2 and 3 will require root privileges on most systems (not Cygwin).
-
- Now NuttX should link with no problem. If you want to restore the
- vterminate.o that you removed from libsupc++, you can do that with:
-
- arm-none-eabi-ar.exe rcs libsupc++.a vterminate.o
-
- 3. Exceptions are enabled and workking (CONFIG_CXX_EXCEPTION=y)
-
- elf:
- ---
-
- This configuration uses apps/examples/elf in order to test the ELF
- loader.
-
- NOTES:
-
- 1. Default platform/toolchain:
-
- CONFIG_HOST_WINDOWS=y : Windows
- CONFIG_WINDOWS_CYGWIN=y : Cygwin environment on Windows
- CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : GNU EABI toolchain for Windows
-
- 2. By default, this project assumes that you are *NOT* using the DFU
- bootloader.
-
- 3. It appears that you cannot execute from CCM RAM. This is why the
- following definition appears in the defconfig file:
-
- CONFIG_STM32_CCMEXCLUDE=y
-
- 4. This configuration requires that you have the genromfs tool installed
- on your system and that you have the full path to the installed genromfs
- executable in PATH variable (see apps/examples/README.txt)
-
- 5. This configuration can be extended to use the hello++4 example and to
- build uClibc with the following additions to the configuration file
- (from Leo aloe3132):
-
- CONFIG_HAVE_CXXINITIALIZE=y
-
- CONFIG_UCLIBCXX=y
- CONFIG_CXX_EXCEPTION=y
- CONFIG_LIBSUPCXX=y
- CONFIG_UCLIBCXX_BUFSIZE=32
-
- CONFIG_EXAMPLES_ELF_CXX=y
-
- 6. By default, this configuration uses the ROMFS file system. It can also
- be modified to use the compressed CROMFS:
-
- -CONFIG_PATH_INITIAL="/mnt/romfs"
- +CONFIG_PATH_INITIAL="/mnt/cromfs"
-
- -CONFIG_FS_ROMFS=y
- +CONFIG_FS_CROMFS=y
-
- -CONFIG_EXAMPLES_ELF_ROMFS=y
- +CONFIG_EXAMPLES_ELF_CROMFS=y
-
- 7. The network initialization thread is enabled in this configuration.
- As a result, networking initialization is performed asynchronously with
- NSH bring-up.
-
- The network monitor is not enabled in this configuration, however, so
- the firmware will not know when the network is disconnected or
- reconnected. The NSH Network Monitor cannot be used with the
- STM32F4DIS-BB base board because the LAN8720 is configured in REF_CLK
- OUT mode. In that mode, the PHY interrupt is not supported. The NINT
- pin serves as REFLCK0 in that case.
-
- hciuart:
- -------
-
- This configuration was used for test the HCI UART driver. The HCI UART
- is enabled on USART3 as well as the test application at
- apps/wireless/bluetoot/btsak.
-
- NOTES:
-
- 1. This configuration assumes that that you are using the STM32F4DIS-BB
- base board with serial console on USART6. If you are not using the
- STM32F4DIS-BB, then you will want to disable support for the base
- board.
-
- -CONFIG_STM32F4DISBB=y
- +# CONFIG_STM32F4DISBB is not set
-
- You may also want to reconfigure the serial console to USART1.
-
- 2. The HCI UART is assumed to connect to the UART3 on the following pins:
-
- USART3 TX : PB10
- USART3 RX : PB11
- USART3 CTS: PB13
- USART3 RTS: PB14
-
- The HCI UART selection can be changed by re-configuring and assigning
- the different U[S]ART to the HCI. The U[S]ART pin selections can be
- changed by modifying the disambiguation definitions in
- boards/arm/stm32/stm32f4discovery/include/board.h
-
- I have been testing with the DVK_BT960_SA board via J10 as follows:
-
- DVK_BT860-SA J10 STM32F4 Discovery P1
- pin 1 GND P1 pin 49
- pin 2 Module_RTS_O USART3_CTS PB13, P1 pin 37
- pin 3 N/C
- pin 4 Module_RX_I USART3_TXD PB10, P1 pin 34
- pin 5 Module_TX_O USART3_RX PB11, P1 pin 35
- pin 6 Module_CTS_I USART3_RTS PB14, P1 pin 38
-
- NOTICE that the BT860 uses BT860-centric naming, the Rx pin is for
- BT860 receive and needs to connect with the STM32 Tx pin, the Tx pin
- is for BT860 transmit an needs to be connected with the STM32 Rx pin,
- etc. Other parts may use host-centric naming so that the HCI UART Rx
- pin connects to the STM32 Rx pin, Tx to Tx pin, etc.
-
- 3. Due to conflicts, USART3 many not be used if Ethernet is enabled with
- the STM32F4DIS-BB base board:
-
- PB-11 conflicts with Ethernet TXEN
- PB-13 conflicts with Ethernet TXD1
-
- If you need to use the HCI uart with Ethernet, then you will need to
- configure a new U[S]ART and/or modify the pin selections in
- include/board.h.
-
- 4. Stack sizes are large and non-optimal. Don't judge memory usage
- without tuning.
-
- 5. I tested using the Laird DVK_BT860. The BT860 defaults to 115200
- BAUD but is capable of transfers up to 4M. The documentation says
- that the part supports auto baudrate detection, but I have found no
- documentation on how to use that.
-
- Currently the "generic" HCI UART upper half is used with the BT860
- and that upper half driver supports only a fixed (but configurable
- BAUD) is used and this must be set to the BT860 default (115200).
-
- A custom BT860 upper half driver is needed that can use vendor
- specific command: Baud rate can be set with such a vendor-specific
- command. Ideally, the sequence would be: (1) start at default baud
- rate, (2) get local version info, (3) send the vendor-specific baud
- rate change command, (4) wait for response, and (5) set the local
- UART to the matching, higher baud rate.
-
- The custom, vendor-specific BT860 command is:
-
- {0x18, 0xfc, 0x06, 0x00, 0x00, NN, NN, NN, NN}
-
- where {NN, NN, NN, NN} is the requested baud in little endian byte order.
-
- If an initialization script is used then (5) then send initialization
- scripts script. After sending the last command from the
- initialization script, (6) reset the local UART. Finally, (7) send
- vendor-specific baud rate change command, (8) wait for response, and
- (9) set local UART to high baud rate.
-
- The command to write the initialization script into NVRAM is another
- story for another time and another place.
-
- If you use a different HCI UART, you will need to modify this setting:
-
- CONFIG_BLUETOOTH_UART_GENERIC=y
-
- and you may have to add some support in drivers/wireless/bluetooth.
-
- ipv6:
- ----
- This is another version of the NuttShell configuration for the
- STM32F4-Discovery with the STM32F4DIS-BB base board. It is very similar
- to the netnsh configuration except that it has IPv6 enabled and IPv4
- disabled. Several network utilities that are not yet available when
- IPv6 is disabled.
-
- NOTES:
-
- 1. As of 2015-02-05, this configuration was identical to the netnsh
- configuration other than using IPv6. So all of the notes above
- regarding the netnsh configuration apply.
-
- a. Telnet does work with IPv6 but is not enabled in this
- configuration (but could be).
- b. The network initialization thread was enabled in the netnsh
- configuration on 2015-09-28, but not in the ipv6 configuration.
-
- 2. This configuration can be modified to that both IPv4 and IPv6
- are support. Here is a summary of the additional configuration
- settings required to support both IPv4 and IPv6:
-
- CONFIG_NET_IPv4=y
- CONFIG_NET_ARP=y
- CONFIG_NET_ARP_SEND=y (optional)
- CONFIG_NET_ICMP=y
- CONFIG_NET_ICMP_SOCKET=y
-
- CONFIG_NETDB_DNSCLIENT=y
- CONFIG_NETUTILS_TELNETD=y
-
- CONFIG_NSH_IPADDR=0x0a000002
- CONFIG_NSH_DRIPADDR=0x0a000001
- CONFIG_NSH_NETMASK=0xffffff00
- CONFIG_NSH_TELNET=y
-
- Then from NSH, you have both ping and ping6 commands:
-
- nsh> ping 10.0.0.1
- nsh> ping6 fc00::1
-
- And from the host you can do similar:
-
- ping 10.0.0.2
- ping6 fc00::2 (Linux)
- ping -6 fc00::2 (Windows cmd)
-
- and Telnet is now enabled and works from the host... but only using
- IPv6 addressing:
-
- telnet fc00::2
-
- That is because the Telnet daemon will default to IPv6 and there is
- no Telnet option to let you select which if both IPv4 and IPv6 are
- enabled.
-
- 3. I have used this configuration to serve up IP address prefixes
- in a local network with these modifications to the configuration:
-
- +CONFIG_NET_ICMPv6_ROUTER=y
- +CONFIG_NET_ICMPv6_PREFLEN=64
- +CONFIG_NET_ICMPv6_PREFIX_1=0xfc00
- +CONFIG_NET_ICMPv6_PREFIX_2=0x0000
- +CONFIG_NET_ICMPv6_PREFIX_3=0x0000
- +CONFIG_NET_ICMPv6_PREFIX_4=0x0000
- +CONFIG_NET_ICMPv6_PREFIX_5=0x0000
- +CONFIG_NET_ICMPv6_PREFIX_6=0x0000
- +CONFIG_NET_ICMPv6_PREFIX_7=0x0000
- +CONFIG_NET_ICMPv6_PREFIX_8=0x0000
-
- +CONFIG_NSH_IPv6NETMASK_5=0x0000
- -CONFIG_NSH_IPv6NETMASK_5=0xffff
-
- +CONFIG_NSH_IPv6NETMASK_6=0x0000
- -CONFIG_NSH_IPv6NETMASK_6=0xffff
-
- +CONFIG_NSH_IPv6NETMASK_7=0x0000
- -CONFIG_NSH_IPv6NETMASK_7=0xffff
-
- +CONFIG_NSH_IPv6NETMASK_8=0x0000
- -CONFIG_NSH_IPv6NETMASK_8=0xff80
-
- kostest:
- -------
- This is identical to the ostest 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 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.
-
- 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
-
- 3. 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.
-
- 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
- other NSH configurations 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-02: Configuration added by Alan Carvalho de Assis.
-
- netnsh:
- ------
- This is a special version of the NuttShell (nsh) configuration that is
- tailored to work with the STM32F4DIS-BB base board. This version
- derives from nsh configuration so all of the notes apply there except as
- noted below.
-
- NOTES:
-
- 1. This example uses USART6 for the serial console. The STM32F4DIS-BB
- provides RS-232 drivers for USART6 and allows access via the DB9
- connector on the base board. USART6 is, therefore, the more
- convenient UART to use for the serial console.
-
- 2. Networking is enabled. The STM32F4DIS-BB has an SMC LAN2870 PHY
- and RJ5 network connector. Support is enabled for ICMP, TCP/IP,
- UDP, and ARP.
-
- 3. SD card support is enabled. The STM32F4DIS-BB has an on-board
- microSD slot that should be automatically registered as the block
- device /dev/mmcsd0 when an SD card is present. The SD card can
- then be mounted by the NSH command:
-
- nsh> mount -t /dev/mmcsd0 /mnt/sdcard
-
- 4. CCM memory is not included in the heap in this configuration. That
- is because the SD card uses DMA and if DMA memory is allocated from
- the CCM memory, the DMA will failure. This is an STM32 hardware
- limitation.
-
- If you want to get the CCM memory back in the heap, then you can
-
- a) Disable microSD support (and DMAC2 which is then no longer
- needed). If you reduce the clocking by a huge amount, it might
- be possible to use microSD without DMA. This, however, may
- not be possible.
- b) Develop a strategy to manage CCM memory and DMA memory. Look
- at this discussion on the NuttX Wiki:
- https://cwiki.apache.org/confluence/display/NUTTX/STM32+CCM+Allocator
-
- To put the CCM memory back into the heap you would need to change
- the following in the NuttX configuration:
-
- CONFIG_STM32_CCMEXCLUDE=n : Don't exclude CCM memory from the heap
- CONFIG_MM_REGIONS=2 : With CCM, there will be two memory regions
-
- nsh:
- ---
- Configures the NuttShell (nsh) located at apps/examples/nsh. The
- Configuration enables the serial interfaces on USART2. Support for
- builtin applications is enabled, but in the base configuration no
- builtin applications are selected (see NOTES below).
-
- NOTES:
-
- 1. 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
-
- 2. To use this configuration with the STM32F4DIS-BB baseboard you
- should:
-
- - Select the STM32F4DIS-BB baseboard in the board configuration
- menu
- - Disable USART2 and select USART6 in the STM32 peripheral selection
- menu
- - Select USART6 as the serial console at 115200 8N1 in the
- Drivers menus
-
- 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
-
- 4. 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.tx. Special debug options:
-
- CONFIG_DEBUG_SENSORS
-
- 5. 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.
-
- 6. 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
-
- 7. Using the USB console.
-
- The STM32F4Discovery 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.
-
- 8. 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
- of the 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.
-
- 9. 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:
-
- 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_OTGFS=y : Enable the STM32 USB OTG FS block
- CONFIG_STM32_SYSCFG=y : Needed for all USB OTF FS 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
-
- 10. 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
-
- System Type -> USB host configuration
- To be determined
-
- Board Selection ->
- CONFIG_STM32F4DISCO_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.
-
- 11. Using USB Device as a Mass Storage for the host computer:
-
- System Type --->
- STM32 Peripheral Support --->
- [*] OTG FS
-
- Device Drivers --->
- [*] USB Device Driver Support --->
- [*] USB Mass storage class device --->
- [*] Mass storage removable
-
- [*] RAM Disk Support
-
- Board Selection --->
- [*] Enable boardctl() interface
- [*] Enable USB device controls
-
- File Systems --->
- [*] FAT file system
- [*] FAT upper/lower names
- [*] FAT long file names
-
- [*] PROCFS File System
-
- Application Configuration --->
- System Libraries and NSH Add-Ons --->
- [*] USB Mass Storage Device Commands --->
- (/dev/ram0) LUN1 Device Path
-
- Compile and flash the firmware in the board as usual, then in the nsh:
-
- nsh> mkrd -m 0 -s 512 64
-
- nsh> ls /dev
- /dev:
- console
- null
- ram0
- ttyS0
-
- nsh> mkfatfs /dev/ram0
-
- Connect a USB cable to STM32F4Discovery board (connector CN5) and run:
-
- nsh> msconn
- mcsonn_main: Creating block drivers
- mcsonn_main: Configuring with NLUNS=1
- mcsonn_main: handle=1000a550
- mcsonn_main: Bind LUN=0 to /dev/ram0
- mcsonn_main: Connected
-
- In this moment a 33KB disk should appear in your host computer. If you
- saved some file on this small disk you can now run disconnect command:
-
- nsh> msdis
- msdis: Disconnected
-
- Remove the USB cable from microUSB connector and run:
-
- nsh> mount -t vfat /dev/ram0 /mnt
-
- nsh> ls /mnt
- /mnt:
- TEST.TXT
-
- nsh> cat /mnt/TEST.TXT
- Testing
-
- nxlines:
- ------
- An example using the NuttX graphics system (NX). This example focuses on
- placing lines on the background in various orientations.
-
- CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : GNU EABI toolchain for Windows
- CONFIG_LCD_LANDSCAPE=y : 320x240 landscape orientation
-
- The STM32F4Discovery board does not have any graphics capability. This
- configuration assumes that you have connected an SD1289-based LCD as
- described above under "SSD1289". NOTE: At present, it has not been
- proven that the STM32F4Discovery can actually drive an LCD. There are
- some issues with how some of the dedicated FSMC pins are used on the
- boards. This configuration may not be useful and may only serve as
- an illustration of how to build for th SSD1289 LCD.
-
- NOTES:
-
- 1. As of this writing, I have not seen the LCD work!
-
- 2. This configured can be re-configured to use either the
- UG-2864AMBAG01 or UG-2864HSWEG01 0.96 inch OLEDs by adding
- or changing the following items in the configuration (using
- 'make menuconfig'):
-
- +CONFIG_SPI_CMDDATA=y
-
- -CONFIG_LCD_MAXCONTRAST=1
- -CONFIG_LCD_MAXPOWER=255
- +CONFIG_LCD_MAXCONTRAST=255
- +CONFIG_LCD_MAXPOWER=1
-
- -CONFIG_LCD_SSD1289=y
- -CONFIG_SSD1289_PROFILE1=y
- +CONFIG_LCD_UG2864AMBAG01=y : For the UG-2964AMBAG01
- +CONFIG_UG2864AMBAG01_SPIMODE=3
- +CONFIG_UG2864AMBAG01_FREQUENCY=3500000
- +CONFIG_UG2864AMBAG01_NINTERFACES=1
-
- -CONFIG_NX_DISABLE_1BPP=y
- +CONFIG_NX_DISABLE_16BPP=y
- +CONFIG_NXSTART_EXTERNINIT=y
-
- -CONFIG_EXAMPLES_NXLINES_BGCOLOR=0x0320
- -CONFIG_EXAMPLES_NXLINES_LINEWIDTH=16
- -CONFIG_EXAMPLES_NXLINES_LINECOLOR=0xffe0
- -CONFIG_EXAMPLES_NXLINES_BORDERWIDTH=4
- -CONFIG_EXAMPLES_NXLINES_BORDERCOLOR=0xffe0
- -CONFIG_EXAMPLES_NXLINES_CIRCLECOLOR=0xf7bb
- -CONFIG_EXAMPLES_NXLINES_BPP=16
- +CONFIG_EXAMPLES_NXLINES_BGCOLOR=0x00
- +CONFIG_EXAMPLES_NXLINES_LINEWIDTH=4
- +CONFIG_EXAMPLES_NXLINES_LINECOLOR=0x01
- +CONFIG_EXAMPLES_NXLINES_BORDERWIDTH=2
- +CONFIG_EXAMPLES_NXLINES_BORDERCOLOR=0x01
- +CONFIG_EXAMPLES_NXLINES_CIRCLECOLOR=0x00
- +CONFIG_EXAMPLES_NXLINES_BPP=1
- +CONFIG_EXAMPLES_NXLINES_EXTERNINIT=y
-
- There are some issues with the presentation... some tuning of the
- configuration could fix that. Lower resolution displays are also more
- subject to the "fat, flat line bug" that I need to fix someday. See
- https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629474
- for a description of the fat, flat line bug.
-
- pm:
- --
- This is a configuration that is used to test STM32 power management, i.e.,
- to test that the board can go into lower and lower states of power usage
- as a result of inactivity. This configuration is based on the nsh2
- configuration with modifications for testing power management. This
- configuration should provide some guidelines for power management in your
- STM32 application.
-
- NOTES:
-
- 1. Default configuration is Cygwin under windows using the AM EABI GCC
- toolchain:
-
- CONFIG_HOST_WINDOWS=y : Windows
- CONFIG_WINDOWS_CYGWIN=y : Cygwin
- CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : GNU EABI toolchain for Windows
-
- 2. CONFIG_ARCH_CUSTOM_PMINIT and CONFIG_ARCH_IDLE_CUSTOM are necessary
- parts of the PM configuration:
-
- CONFIG_ARCH_CUSTOM_PMINIT=y
-
- CONFIG_ARCH_CUSTOM_PMINIT moves the PM initialization from
- arch/arm/src/stm32/stm32_pminitialiaze.c to boards/arm/stm32/stm3210-eval/src/stm32_pm.c.
- This allows us to support board-specific PM initialization.
-
- CONFIG_ARCH_IDLE_CUSTOM=y
-
- The bulk of the PM activities occur in the IDLE loop. The IDLE loop
- is special because it is what runs when there is no other task running.
- Therefore when the IDLE executes, we can be assure that nothing else
- is going on; this is the ideal condition for doing reduced power
- management.
-
- The configuration CONFIG_ARCH_IDLE_CUSTOM allows us to "steal" the
- normal STM32 IDLE loop (of arch/arm/src/stm32/stm32_idle.c) and replace
- this with our own custom IDLE loop (at boards/arm/stm32/stm3210-eval/src/up_idle.c).
-
- 3. Here are some additional things to note in the configuration:
-
- CONFIG_PM_BUTTONS=y
-
- CONFIG_PM_BUTTONS enables button support for PM testing. Buttons can
- drive EXTI interrupts and EXTI interrupts can be used to wakeup for
- certain reduced power modes (STOP mode). The use of the buttons here
- is for PM testing purposes only; buttons would normally be part the
- application code and CONFIG_PM_BUTTONS would not be defined.
-
- CONFIG_RTC_ALARM=y
-
- The RTC alarm is used to wake up from STOP mode and to transition to
- STANDBY mode. This used of the RTC alarm could conflict with other
- uses of the RTC alarm in your application.
-
- posix_spawn:
- ------------
- This configuration directory, performs a simple test os the posix_spawn
- interface using apps/examples/posix_spawn.
-
- NOTES:
-
- 1. Default toolchain:
-
- CONFIG_HOST_WINDOWS=y : Builds under windows
- CONFIG_WINDOWS_CYGWIN=y : Using Cygwin and
- CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : Generic ARM EABI toolchain for Windows
-
- 2. By default, this project assumes that you are *NOT* using the DFU
- bootloader.
-
- pseudoterm:
- -----------
-
- This is a configuration to test the Pseudo Terminal support for NuttX.
-
- To test it you will need two USB/Serial dongles. The first dongle as
- usual will be used to main NSH console port in USART2 (PA2 and PA3) and
- the second dongle you will connect to UART3 (PB10 and PB11).
-
- In the main NSH console (in USART2) type: "pts_test &". It will create a
- new console in UART3. Just press ENTER and start typing commands on it.
-
- sporadic
- --------
-
- This is an NSH configuration that includes apps/testing/ostest as a builtin.
- The sporadic scheduler is enabled and the purpose of this configuration is
- to investigate an error in that scheduler. See Issue 2035. The serial
- console is on USART6.
-
- testlibcxx
- ----------
-
- This is a configuration for testing lib++. See the section above entitled
- "Testing LLVM LIBC++ with NuttX" for detailed information about this
- configuration.
-
- rgbled:
- -------
-
- Alan Carvalho de Assis has used the STM32F4-Discovery to drive an RGB LED
- using PWM output. The external RGB connected this way:
-
- R = TIM1 CH1 on PE9
- G = TIM2 CH2 on PA1
- B = TIM3 CH3 on PB0
-
- as described about in the section "RGB LED Driver".
-
- This configuration uses the example at apps/examples/rgbled to drive the
- external RGB LED>
-
- rndis:
- ------
-
- This is a board configuration to demonstrate how to use Ethernet-over-USB,
- in this case using the RNDIS protocol. Using it you can get access to your
- board using Telnet or you can use transfer file to it. Both steps will be
- explained below.
-
- Your board will be get IP address from a DHCP server. If you want to use a
- fixed IP instead using DHCP, you need to disable the DHCP Client and set
- up its IP. For more info watch: www.youtube.com/watch?v=8noH8v7xNgs
-
- You can access the board's NuttShell just typing in the Linux terminal:
-
- $ telnet 10.0.0.2
-
- You should see something like this:
-
- Trying 10.0.0.2...
- Connected to 10.0.0.2.
- Escape character is '^]'.
-
- NuttShell (NSH)
- nsh>
-
- This board configuration has support to RAMDISK because we need a writable
- filesystem to get files from the computer. Then you need to create first a
- RAMDISK and mount it using these steps:
-
- nsh> mkrd 64
- nsh> mkfatfs /dev/ram0
- nsh> mount -t vfat /dev/ram0 /mnt
-
- Open a new Linux terminal and start a webserver, Python one embedded:
-
- $ python -m SimpleHTTPServer
-
- It will create a webserver serving in the port 8000 and will share files
- in the current directory where it was executed.
-
- Then in the NuttShell you can run these commands to download a small file:
-
- nsh> cd /mnt
- nsh> wget http://10.0.0.1:8000/test.txt
- nsh> ls -l
- /mnt:
- -rw-rw-rw- 23 test.txt
-
- This configuration also supports:
-
- 1. An NFS file system client. Relevant configuration options:
-
- CONFIG_NFS=y
- CONFIG_NFS_STATISTICS=y
-
- 2. Loadable ELF modules
-
- CONFIG_SYMTAB_ORDEREDBYNAME=y
- CONFIG_ELF=y
- CONFIG_EXAMPLES_HELLO=m
- CONFIG_LIBC_EXECFUNCS=y
- CONFIG_NSH_FILE_APPS=y
- CONFIG_NSH_SYMTAB=y
- CONFIG_NSH_SYMTAB_ARRAYNAME="g_symtab"
- CONFIG_NSH_SYMTAB_COUNTNAME="g_nsymbols"
-
- Further, the configuration assumes that executable files reside on the
- remotely mounted file system:
-
- CONFIG_LIBC_ENVPATH=y
- CONFIG_PATH_INITIAL="/mnt/nfs/bin"
-
- 3 'ping' support
-
- CONFIG_NET_ICMP_SOCKET=y
- CONFIG_SYSTEM_PING=y
-
- 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. 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
-
- 2. This configuration does have USART2 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" : USART2 will be /dev/ttyS0
-
- However, there is nothing to generate SYSLOG output in the default
- configuration so nothing should appear on USART2 unless you enable
- some debug output or enable the USB monitor.
-
- NOTE: Using the SYSLOG to get debug output has limitations. Among
- those are that you cannot get debug output from interrupt handlers.
- So, in particularly, debug output is not a useful way to debug the
- USB device controller driver. Instead, use the USB monitor with
- USB debug off and USB trace on (see below).
-
- 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 (USART2 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
-
- 4. 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=n : Disable the CDC/ACM serial device class
- CONFIG_CDCACM_CONSOLE=n : 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
-
- winbuild:
- --------
-
- This is a version of the apps/example/ostest, but configure to build natively
- in the Windows CMD shell.
-
- NOTES:
-
- 1. The beginnings of a Windows native build are in place but still not full
- usable as of this writing. The windows native build logic is currently
- separate and must be started by:
-
- make -f Win.mk
-
- This build:
-
- - Uses all Windows style paths
- - Uses primarily Windows batch commands from cmd.exe, with
- - A few extensions from GNUWin32 (or MSYS is you prefer)
-
- In this build, you cannot use a Cygwin or MSYS shell. Rather the build must
- be performed in a Windows console. Here is a better shell than than the
- standard issue, CMD.exe shell: ConEmu which can be downloaded from:
- http://code.google.com/p/conemu-maximus5/
-
- CONFIG_HOST_WINDOWS=y : Windows
- CONFIG_WINDOWS_NATIVE=y : Native Windows environment
- CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : GNU EABI toolchain for Windows
-
- Build Tools. The build still relies on some Unix-like commands. I use
- the GNUWin32 tools that can be downloaded from http://gnuwin32.sourceforge.net/.
- The MSYS tools are probably also a option but are likely lower performance
- since they are based on Cygwin 1.3.
-
- Host Compiler: I use the MingGW compiler which can be downloaded from
- http://www.mingw.org/. If you are using GNUWin32, then it is recommended
- the you not install the optional MSYS components as there may be conflicts.
diff --git a/boards/arm/stm32wl5/nucleo-wl55jc/README.txt b/boards/arm/stm32wl5/nucleo-wl55jc/README.txt
deleted file mode 100644
index 01d5aba4b3..0000000000
--- a/boards/arm/stm32wl5/nucleo-wl55jc/README.txt
+++ /dev/null
@@ -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"