546 lines
21 KiB
Plaintext
546 lines
21 KiB
Plaintext
README
|
|
======
|
|
|
|
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
|
|
|
|
Contents
|
|
========
|
|
|
|
o Serial Console
|
|
o LEDs
|
|
o Buttons
|
|
o Using JTAG
|
|
o 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:
|
|
|
|
USART2: mikroBUS1 PD6/RX and PD5/TX
|
|
USART3: mikroBUS2 PD9/RX and PD8TX
|
|
|
|
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.
|
|
|
|
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:
|
|
|
|
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
|
|
|
|
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 interupts. 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:
|
|
|
|
T2/E0, Low sensed when pressed
|
|
T3/PA10, Low sensed when pressed
|
|
|
|
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 configs/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:
|
|
|
|
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:
|
|
|
|
$ ./ST-LINK_CLI.exe -c SN=53FF6F064966545035320387 SWD LPM
|
|
STM32 ST-LINK CLI v2.3.0
|
|
STM32 ST-LINK Command Line Interface
|
|
|
|
ST-LINK SN : 53FF6F064966545035320387
|
|
ST-LINK Firmware version : V2J24S4
|
|
Connected via SWD.
|
|
SWD Frequency = 4000K.
|
|
Target voltage = 3.2 V.
|
|
Connection mode : Normal.
|
|
Debug in Low Power mode enabled.
|
|
Device ID:0x413
|
|
Device family :STM32F40xx/F41xx
|
|
|
|
$ ./ST-LINK_CLI.exe -OB RDP=0
|
|
STM32 ST-LINK CLI v2.3.0
|
|
STM32 ST-LINK Command Line Interface
|
|
|
|
ST-LINK SN : 53FF6F064966545035320387
|
|
ST-LINK Firmware version : V2J24S4
|
|
Connected via SWD.
|
|
SWD Frequency = 4000K.
|
|
Target voltage = 3.2 V.
|
|
Connection mode : Normal.
|
|
Device ID:0x413
|
|
Device family :STM32F40xx/F41xx
|
|
Updating option bytes...
|
|
Option bytes updated successfully.
|
|
|
|
NOTE:
|
|
1. You can get the ST-Link Utilies 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
|
|
11:04:28 : Connected via SWD.
|
|
11:04:28 : SWD Frequency = 100 KHz.
|
|
11:04:28 : Connection mode : Normal.
|
|
11:04:28 : Debug in Low Power mode enabled.
|
|
11:04:30 : Device ID:0x413
|
|
11:04:30 : Device family :STM32F40xx/F41xx
|
|
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:
|
|
|
|
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.
|
|
|
|
Configurations
|
|
==============
|
|
|
|
Information Common to All Configurations
|
|
----------------------------------------
|
|
Each Clicker2 configuration is maintained in a sub-directory and can be
|
|
selected as follow:
|
|
|
|
cd tools
|
|
./configure.sh clicker2-stm32/<subdir>
|
|
cd -
|
|
|
|
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
|
|
|
|
The <subdir> that is provided above as an argument to the tools/configure.sh
|
|
must be is one of the following.
|
|
|
|
NOTES:
|
|
|
|
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.
|
|
|
|
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:
|
|
|
|
CONFIG_STM32_USART3=y
|
|
CONFIG_STM32_USART3_SERIALDRIVER=y
|
|
CONFIG_STM32_USART=y
|
|
|
|
CONFIG_USART3_SERIALDRIVER=y
|
|
CONFIG_USART3_SERIAL_CONSOLE=y
|
|
|
|
CONFIG_USART3_RXBUFSIZE=256
|
|
CONFIG_USART3_TXBUFSIZE=256
|
|
CONFIG_USART3_BAUD=115200
|
|
CONFIG_USART3_BITS=8
|
|
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).
|
|
|
|
https://launchpad.net/gcc-arm-embedded
|
|
|
|
That toolchain selection can easily be reconfigured using
|
|
'make menuconfig'. Here are the relevant current settings:
|
|
|
|
Build Setup:
|
|
CONFIG_HOST_LINUX =y : Linux environment
|
|
|
|
System Type -> Toolchain:
|
|
CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIL=y : GNU ARM EABI toolchain
|
|
|
|
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.
|
|
|
|
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)
|
|
|
|
NOTES:
|
|
|
|
1. 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 accept files in .hex, .mot, .srec, and .bin
|
|
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.
|
|
|
|
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.
|
|
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
|
|
|
|
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:
|
|
|
|
CONFIG_CLICKER2_STM32_MB1_BEE=y
|
|
CONFIG_CLICKER2_STM32_MB1_SPI=y
|
|
|
|
2. SPI support and STM32 SPI3, in particular, are enabled:
|
|
|
|
CONFIG_SPI=y
|
|
CONFIG_SPI_EXCHANGE=y
|
|
|
|
CONFIG_STM32_SPI=y
|
|
CONFIG_STM32_SPI3=y
|
|
|
|
4. Support for the IEEE802.15.4 "upper half" character driver is enabled:
|
|
|
|
CONFIG_WIRELESS=y
|
|
CONFIG_WIRELESS_IEEE802154=y
|
|
CONFIG_IEEE802154_MAC_DEV=y
|
|
CONFIG_IEEE802154_NTXDESC=3
|
|
CONFIG_IEEE802154_IND_PREALLOC=20
|
|
CONFIG_IEEE802154_IND_IRQRESERVE=10
|
|
CONFIG_IEEE802154_DEFAULT_EADDR=0x00fade00deadbeef
|
|
|
|
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:
|
|
|
|
CONFIG_IEEE802154_LIBMAC=y
|
|
CONFIG_IEEE802154_LIBUTILS=y
|
|
CONFIG_IEEE802154_I8SAK=y
|
|
CONFIG_IEEE802154_I8SAK_PRIORITY=100
|
|
CONFIG_IEEE802154_I8SAK_STACKSIZE=2048
|
|
|
|
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
|
|
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.
|
|
|
|
Here is a quick "cheat sheet" for associated to setting up a
|
|
coordinator and associating wth the WPAN:
|
|
|
|
1. Configure the Coordinator. On coordinator device do:
|
|
|
|
nsh> i8 /dev/ieee0 startpan
|
|
nsh> i8 acceptassoc
|
|
|
|
2. Assocate an endpoint device with the WPAN. On the endpoint
|
|
device:
|
|
|
|
nsh> i8 /dev/ieee0 assoc
|
|
|
|
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:
|
|
|
|
NOTES:
|
|
|
|
1. 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
|
|
tangle of cables and jumpers needed to debug multi-board setups.
|
|
|
|
Most other NOTES for the usbnsh configuration should apply. Specific
|
|
differences between the usbnsh or mrf24j40-mac configurations and this
|
|
configuration are listed in these NOTES.
|
|
|
|
2. 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.
|
|
|
|
3. 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:
|
|
http://nuttx.org/doku.php?id=wiki:howtos:syslog . Relevant
|
|
configuration settings are summarized below:
|
|
|
|
Device Drivers:
|
|
CONFIG_RAMLOG=y : Enable the RAM-based logging feature.
|
|
CONFIG_RAMLOG_CONSOLE=n : (We don't use the RAMLOG console)
|
|
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
|
|
configuration. Therefore, there is no logic that will add anything
|
|
to the RAM buffer. This feature is configured and in place only
|
|
to support any future debugging needs that you may have.
|
|
|
|
If you don't plan on using the debug features, then by all means
|
|
disable this feature and save 8KiB of RAM!
|
|
|
|
NOTE: There is an issue with capturing data in the RAMLOG: If
|
|
the system crashes, all of the crash dump information will go into
|
|
the RAMLOG and you will be unable to access it! You can tell that
|
|
the system has crashed because (a) it will be unresponsive and (b)
|
|
the LD2 will be blinking at about 2Hz.
|
|
|
|
4. IPv6 networking is enabled with TCP/IP, UDP, 6LoWPAN, and NSH
|
|
Telnet support.
|
|
|
|
5. Configuration instructions: Basic PAN configuration is the same as
|
|
for the ieee802154-mac configuration with the exception that after
|
|
the PAN has been configured with the i8sak utility, you must
|
|
explicity bring the network up on each node:
|
|
|
|
nsh> ifup wpan0
|
|
|
|
6. examples/udp is enabled. This will allow two MRF24J40 nodes to
|
|
exchange UDP packets. Basic instructions:
|
|
|
|
On the server node:
|
|
|
|
nsh> ifconfig wpan0
|
|
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:
|
|
|
|
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.
|
|
|
|
STATUS:
|
|
2017-06-19: The Telnet Daemon does not start. This is simply because
|
|
the daemon is started too early in the sequence... before the network
|
|
has been brought up:
|
|
|
|
telnetd_daemon: ERROR: socket failure: 106
|
|
|
|
2017-06-20: Debug underway.. not yet functional.
|
|
|
|
nsh:
|
|
|
|
Configures the NuttShell (nsh) located at examples/nsh. This
|
|
configuration is focused on low level, command-line driver testing. It
|
|
has no network.
|
|
|
|
NOTES:
|
|
|
|
1. Support for NSH built-in applications is provided:
|
|
|
|
Binary Formats:
|
|
CONFIG_BUILTIN=y : Enable support for built-in programs
|
|
|
|
Application Configuration:
|
|
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
|
|
CONFIG_EXAMPLES_NSH_CXXINITIALIZE=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 Clicker2 STM32 which has no
|
|
builtin RS-232 drivers.
|
|
|
|
NOTES:
|
|
|
|
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:
|
|
|
|
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 SYLOG 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
|
|
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):
|
|
|
|
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
|
|
|
|
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
|
|
|