diff --git a/Documentation/platforms/arm/stm32l4/boards/b-l475e-iot01a/index.rst b/Documentation/platforms/arm/stm32l4/boards/b-l475e-iot01a/index.rst new file mode 100644 index 00000000000..57af8097cec --- /dev/null +++ b/Documentation/platforms/arm/stm32l4/boards/b-l475e-iot01a/index.rst @@ -0,0 +1,620 @@ +================= +ST B-L475E-IOT01A +================= + +This page discusses the port of NuttX to the STMicro B-L475E-IOT01A +Discovery kit powered by STM32L475VG Cortex-M4. This board targets IoT +nodes with a choice of connectivity options including WiFi, Bluetooth LE, +NFC, and sub-GHZ RF at 868 or 915 MHz, as well as a long list of various +environmental sensors. + +Board Features +============== + +B-L475E-IOT01A Discovery kit key features and specifications: + +- MCU: STM32L475 Series MCU based on ARM Cortex-M4 core with 1 MB Flash memory, 128 KB SRAM +- Storage: 64 Mbit (8MB)  Quad-SPI Flash memory (Macronix) +- Connectivity: + - Bluetooth 4.1 LE module (SPBTLE-RF) + - Sub-GHz (868 or 915 MHz) low-power-programmable RF module (SPSGRF-868 or SPSGRF-915) + - Wi-Fi module based on Inventek ISM43362-M3G-L44 (802.11 b/g/n compliant) + - Dynamic NFC tag based on M24SR with its printed NFC antenna +- Sensors: + - 2x digital omni-directional microphones (MP34DT01) + - Capacitive digital sensor for relative humidity and temperature (HTS221) + - 3-axis magnetometer (LIS3MDL) + - 3D accelerometer and 3D gyroscope (LSM6DSL) + - 260-1260 hPa absolute digital output barometer (LPS22HB) + - Time-of-Flight and gesture-detection sensor (VL53L0X +- USB – 1x micro USB OTG port (Full speed) +- Expansion – Arduino UNO V3 headers, PMOD header +- Debugging – On-board ST-LINK/V2-1 debugger/programmer with USB + re-enumeration capability: mass storage, virtual COM port and debug + port +- Misc – 2 push-buttons (user and reset) +- Power Supply – 5V via ST LINK USB VBUS or external sources + +The board supports ARM mbed online compiler, but can also be programmed +using IDEs such as IAR, Keil, and GCC-based IDEs. STMicro also provides +HAL libraries and code samples as part of the STM32Cube Package, as well +as X-CUBE-AWS expansion software to connect to the Amazon Web Services +(AWS) IoT platform. + +NOTES: + +1. The board usese Wi-Fi® module Inventek ISM43362-M3G-L44 (802.11 b/g/n + compliant), which consists of BCM43362 and STM32F205 host processor + that has a standard SPI or UART interface capability. It means you + will only use AT command to talk with Wi-Fi® module by SPI. All the + tcp/ip stack is built-in STM32F205 in Wi-Fi® module. + + This cannot integrate cleanly with the NuttX network stack. A + USERSOCK option was recently added that would permit implementation + of the Inventek support in an applications. But that would then + preclude the 6LoWPAN integration into IPv6. + +2. The board uses Bluetooth® V4.1 module (SPBTLE-RF), which has built-in + BLE stack. Similar with wifi, you only use simple AT command to talk + with this BLE module. + +3. STMicro provides contiki 6lowpan for mesh. + http://www.st.com/en/embedded-software/osxcontiki6lp.html but mesh + network is not popular in the market, star network is the mainstream + for its simplicity and robustness. + +LEDs and Buttons +================ + +The black button B1 located on top side is the reset of the STM32L475VGT6. + +The blue button B1 located top side is available to be used as a digital +input or as alternate function Wake-up. When the button is depressed the +logic state is "0", otherwise the logic state is "1". + +Two green LEDs (LD1 and LD2), located on the top side are available for +the user. To light a LED a high logic state "1" should be written in the +corresponding GPIO.:: + + Reference Color Name Comment + B2 blue Wake-up Alternate function Wake-up + LD1 green LED1 PA5 (alternate with ARD.D13) + LD2 green LED2 PB14 + +These LEDs are not used by the board port unless CONFIG_ARCH_LEDS is +selected. In that case, the usage by the board port is defined in +include/board.h and src/lpc31_leds.c. The LEDs are used to encode +OS-related events as follows: + + SYMBOL Meaning LED2 LED1 + ------------------- ----------------------- -------- -------- + 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 N/C + 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 N/C Blinking + LED_IDLE MCU is is sleep mode Not used + +Thus if LED2 is statically on, NuttX has successfully booted and is, +apparently, running normmally. If LED1 is flashing at approximately +2Hz, then a fatal error has been detected and the system has halted. + +NOTE: That LED2 is not used after completion of booting and may +be used by other board-specific logic. + +Of course, if CONFIG_ARCH_LEDS is not selected, then both LEDs are +available for use by other logic. + +Serial Console +============== + +Arduino Serial Shield +--------------------- + +An TLL-to-RS232 Converter shield may be used with UART4: + + UART4: + + -------------- ---------------- ------------------ + STM32L475VGTx Board Signal Arduino Connector + -------------- ---------------- ------------------ + UART4_RX PA1 ARD.D0-UART4_RX CN3 pin1 RX/D0 + UART4_TX PA0 ARD.D1-UART4_TX CN3 pin2 TX/D1 + -------------- ---------------- ------------------ + +Virtual COM Port +---------------- + +The serial interface USART1 is directly available as a virtual COM port +of the PC connected to the ST-LINK/V2-1 USB connector CN7. + + USART1: + + -------------- ---------------- -------------- + STM32L475VGTx Board Signal STM32F103CBT6 + -------------- ---------------- -------------- + USART1_TX PB6 ST-LINK-UART1_TX USART2_RX PA3 + UAART1_RX PB7 ST-LINK-UART1_RX USART2_TX PA2 + -------------- ---------------- -------------- + +The virtual COM port settings are configured as: 115200 b/s, 8 bits data, +no parity, 1 stop bit, no flow control. + +Other Options +------------- + +USART2 - Available on CN10 if solder bridges closed. + + -------------- ---------------- --------------------------- + STM32L475VGTx Board Signal PMOD / Solder Bridges + -------------- ---------------- --------------------------- + USART2_RX PD4 PMOD-UART2_RX CN10 pin1 or 2 (SB12, SB14) + USART2_TX PD5 PMOD-UART2_TX CN10 pin2 TX/D1 (SB20) + -------------- ---------------- --------------------------- + +USART3 - Dedicated to ISM43362-M3G-L44 Serial-to-Wifi Module. + + -------------- ---------------- ------------------ + STM32L475VGTx Board Signal Arduino Connector + -------------- ---------------- ------------------ + USART3_RX PD9 INTERNAL-UART3_RX CN3 pin1 RX/D0 + USART3_TX PD8 INTERNAL-UART3_TX CN3 pin2 TX/D1 + -------------- ---------------- ------------------ + +Configurations +============== + +Information Common to All Configurations +---------------------------------------- + +Each B-L475E-IOT01A configuration is maintained in a sub-directory and +can be selected as follow:: + + tools/configure.sh [-l|c|n] /b-l475e-iot01a: + + Where: + -l selects the Linux (l) host environment. The [-c|u|n] options + select one of the Windows environments. Default: Use host setup + in the defconfig file + [-c|n] selects the Windows host and a Windows environment: + Cygwin (c), or Windows native (n). Default Cygwin + +Before building, make sure that: + +1. The PATH environment variable include the correct path to the + directory than holds your toolchain binaries. +2. Check the .config file. Make sure that the configuration is set for + your build platform (e.g., Linux vs. Windows) and that the toolchain + is set for the toolchain type you are using. + +The that is provided above as an argument to the +tools/configure.sh must be is one of those listed below. + +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 + +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 USART1 (i.e., for ST-Link Virtual COM port). The + relevant configuration settings are listed below:: + + CONFIG_STM32_USART1=y + CONFIG_STM32_USART1_SERIALDRIVER=y + CONFIG_STM32_USART=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 + +3. All of these configurations are set up to build under Windows 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: + + Build Setup:: + + CONFIG_HOST_WINDOWS=y : Window environment + CONFIG_WINDOWS_CYGWIN=y : Cywin under Windows + + System Type -> Toolchain:: + + CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : GNU ARM EABI toolchain + +Configuration sub-directories +----------------------------- + +nsh: +---- + +Configures the NuttShell (nsh) located at examples/nsh. This +configuration is focused on low level, command-line driver testing. + +spirit-6lowpan +-------------- + +This is another version of nsh that is similar to the above 'nsh' +configuration but is focused on testing the Spirit1 integration with +the 6LoWPAN network stack. It supports point-to-point, 6LoWPAN +communications between two b-l47e-iot01a boards. Additional differences +from the 'nsh" configuration are summarized below: + +NOTES: + +1. You must must have two b-l475e-iot01a boards. + +2. IPv6 networking is enabled with TCP/IP, UDP, 6LoWPAN, and NSH Telnet support. + +3. Configuration instructions: NSH does not configuration or + bring up the network. Currently that must be done manually. + The configurations steps are: + + a) Assign a unique 8-bit node address to the Spirit1 board in the + WPAN:: + + nsh> ifconfig wpan0 hw 37 + + Where 37 the address is an example. It should be different for + each radio, but in the the range 1..ed and ef..fe (ee and ff are + the reserved for multicast and broadcast addresses, respectively. + Zero is a valid address but not recommended). + + b) Bring each the network up on each board in the WPAN:: + + nsh> ifup wpan0 + + You can entry nsh> ifconfig to see if the node address and + derived IPv4 are set correctly (the IPv6 address will not be + determined until the network is UP). + +4. examples/udp is enabled. This will allow two Spirit1 nodes to + exchange UDP packets. Basic instructions: + + 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:: + + nsh> udpclient & + + Where 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. + +5. examples/nettest is enabled. This will allow two Spirit1 nodes to + exchange TCP packets. Basic instructions: + + 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:: + + nsh> tcpclient & + + Where 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. + +6. 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 address derives from the 8-bit node address that was assigned + when the node was configured. + +7. 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 + + Where 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 + + STATUS: + + 2017-08-01: Testing began. The Spirit1 no configurations with no + errors, but there are no tests yet in place to exercise it. + + 2017-08-02: The nettest, udp, telnet test programs were added. + + 2017-08-03: Successfully exchanging packets, but there there are + issues with address filtering, CRC calculation, and data integrity + (like bad UDP checksums). Lot's more to be done! + + 2017-08-04: Fixed some of the address filtering issues: In Basic + packets, need to force the Spirit to send the destination address. + This fixes address filtering. But... + + Converted to STack vs Basic packets. We need to do this because + the Basic packets do not provide the source node address. Now + correctly gets the source node address and uncompresses the source + IP address. + + In addition, to avoid packet loss due to data overrun, I enabled + the AutoAck, TX retries, the RX timeout options. + + With these changes (along with other, significant bugfixes), both + the UDP test is now fully functional. CRC filtering still must be + disabled. + + 2017-08-05: Add the Telnet client problem. Verified HC06 tests with + no debug output; verified Telnet seessions between two spirit nodes. + + At this point everything seems functional, but somewhat reliable. + Sometimes things seem to initialize in a bad state. + + 2017-08-06: Reducing the FIFO to 94 bytes fixed the problem with the + 2 byte CRC. + + Test Matrix: + The following configurations have been tested successfully (with + CRC disabled): + + =========== ===== ===== ====== + COMPRESSION UDP TCP Telnet + =========== ===== ===== ====== + hc06 08/04 08/04 08/05 + hc1 + ipv6 + =========== ===== ===== ====== + + Other configuration options have not been specifically addressed + (such non-compressable ports, non-MAC based IPv6 addresses, etc.) + +spirit-starhub and spirit-starpoint + +These two configurations implement hub and and star endpoint in a +star topology. Both configurations derive from the spirit-6lowpan +configuration and most of the notes there apply here as well. + +1. You must must have three b-l475e-iot01a boards 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 + spirit-6lowpan in following is also set:: + + CONFIG_NET_STAR=y + CONFIG_NET_STARPOINT=y + + The CONFIG_NET_STARPOINT selection informs the endpoint that it + must send all frames to the hub of the star, rather than directly + to the recipient. + + The star hub configuration, on the other hand, differs from the + spirit-6lowpan in these fundamental ways:: + + CONFIG_NET_STAR=y + CONFIG_NET_STARHUB=y + CONFIG_NET_IPFORWARD=y + + The CONFIG_NET_IPFORWARD selection informs the hub that if it + receives any packets that are not destined for the hub, it should + forward those packets appropriately. + +3. TCP and UDP Tests: The same TCP and UDP tests as described for + the spirit-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. + + Each node in the configuration must be manually initialized. + Ideally, this would be automatically initialized with software logic + and configuration data in non-volatilbe memory. The the procedure + is manual in this example. These are the basic initialization + steps with E1 and E2 representing the two star endpoints and C + representing the star hub:: + + C: nsh> ifup wpan0 <-- Brings up the network on the hub + C: nsh> telnetd <-- Starts the Telnet daemon on the hub + C: nsh> ifconfig <-- To get the IP address of the hub + + E1: nsh> ifconfig wpan0 hw 37 <-- Sets E1 endpoint node address + E1: nsh> ifup wpan0 <-- Brings up the network on the E1 node + E1: nsh> telnetd <-- Starts the Telnet daemon on the E1 node + E1: nsh> ifconfig <-- To get the IP address of E1 endpoint + + E2: nsh> ifconfig wpan0 hw 38 <-- Sets E2 endpoint node address + E2: nsh> ifup wpan0 <-- Brings up the network on the E2 node + E2: nsh> telnetd <-- Starts the Telnet daemon on the E2 node + E2: nsh> ifconfig <-- To get the IP address of E2 endpoint + + It is not necessary to set the hub node address, that will automatically + be set to CONFIG_SPIRIT_HUBNODE when the hub boots. CONFIG_SPIRIT_HUBNODE + is the "well-known" address of the star hub. + + The modified usage of the TCP test is then show below:: + + E1: nsh> tcpserver & + E2: nsh> tcpclient & + + Where is the IP address of the E1 endpoint. + + Similarly for the UDP test: + + E1: nsh> udpserver & + E2: nsh> udpclient & + + Telenet sessions may be initiated from the any node to any other node: + + XX: nsh> telnet <-- Runs the Telnet client on any node XX + + Where is the IP address of either the E1 or E2 endpoints + or of the star hub. + +4. Hub UDP Test. The hub of the star does not support the same level of + test as for the endpoint-to-endpoint tests described above. The primary + role of the hub is packet forwarding. The hub does support to test + applications, however: (1) A Telnet client that will permit the hub to + establish remote NSH sesstions with any endpoint, and (2) A special + version of the udpclient program to support testing of Spirit broadcast. + + IPv6 does not support "broadcast" in the same since as IPv4. IPv6 + supports only multicast. The special multicast address, ff02::1 is + the "all-nodes address" and is functionally equivalent to broadcast. + + The spirit radios do support both multicast and broadcast with the + special addresses 0xee and 0xff, respectively. So the Spirit driver + will map the all-nodes IPv6 to the Spirit destination address 0xff and + the packet will be broadcast to all Spirit nodes. + + Here are the procedures for using the test + + C: nsh> ifup wpan0 <-- Brings up the network on the hub + + E1: nsh> ifconfig wpan0 hw 37 <-- Sets E1 endpoint node address + E1: nsh> ifup wpan0 <-- Brings up the network on the E1 node + E1: udpserver & <-- Start the UDP server + + E2: nsh> ifconfig wpan0 hw 38 <-- Sets E2 endpoint node address + E2: nsh> ifup wpan0 <-- Brings up the network on the E2 node + E2: udpserver & <-- Start the UDP server + + C: udpclient & <-- Starts the UDP client side of the test + + The client will broadcast the UDP packets and, as each UDP packet is + sent, it will be received by BOTH endpoints. + + STATUS: + 2017-08-05: Configurations added. Early testing suggests that there is + a problem when packets are received from multiple sources at high rates: + New incoming packets appear to cause RX FIFO errors and the driver does + not recover well. + + 2017-08-06: The RX FIFO errors are worse when debug is enabled. This led + me to believe that the cause of the RX FIFO errors was due to too many + interactions by the LP and HP work queue. I restructured the tasking to + reduce the amount of interlocking, but this did not eliminate the RX FIFO + errors. + + Hmmm.. this statement appears in the STMicro driver: "Sometimes Spirit1 + seems to NOT deliver (correctly) the 'IRQ_RX_DATA_READY' event for + packets which have a length which is close to a multiple of RX FIFO size. + Furthermore, in these cases also the content delivery seems to be + compromised as well as the generation of RX/TX FIFO errors. This can be + avoided by reducing the maximum packet length to a value which is lower + than the RX FIFO size." + + I tried implementing the RX FIFO almost full water mark thinking this + might be a work around... it is not. Still RX FIFO errors. From my + reading, the only known work-around is to reduce the maximum packet + size so that it is smaller than 96. I tried setting the maximum packet + length to 84 and that did NOT eliminate the RX FIFO error. + + At the end of the TCP test, the "nsh> ifconfig" command shows that + there were two TX timeouts. Perhaps this is related? I found that + the TX timeout was not being cancelled. It must be canceled on each + TX completed or TX error. This DID eliminate the RX FIFO error, but + now the test hangs and does not complete. + + Another Errata: "Using the STack packet format and no CRC field, the + reading from RX FIFO to the last received byte, is not possible. ..." + Workaround: "By configuring the packet handler with at least one byte + of CRC, the problem is solved. If the CRC is not required in the + application, configure one byte of CRC in the receiver only, to read + the payload correctly from RX FIFO." + + Reducing the FIFO to 94 bytes fixed the problem with the 2 byte CRC + but did not resolve that occasional RX FIFO error. + + 2017-08-07: The hang noted yesterday was due to logic that did not + restart the poll timer in the event that Spirit was not ready when the + time expired. Just unconditionally performing the poll fixed this. + + Then I noticed several assertions. In a busy radio environment, there + are many race conditions. Most typically, just when the driver is + setting up to perform a transmission, the hardware commits to a + reception. The symptom is that the driver times out out waiting to go + into the TX state (because it is in the RX state). The logic needed to + be beefed up to handle this routinely without asserting and without + leaving the Spirit in a bad state. + + The TCP test beats the radio very hard and it is actually heartening + that there are no failures that lead to data loss in this environment. + I would say it is functional but fragile in this usage, but probably + robust in a less busy environment. + + 2017-08-08: Added broadcast packet transfers using the hub-based + broadcast UDP client. This appears to be a problem the HC06 + compression and/or decompression. The decompression logic comes up + with the destination address of ff02::ff00:00fe:3500 (which derives + from the receiving node address of 37) instead of the all-nodes + multicast address of ff02::0001. It is then out of sync with the + IPHC headers and is unable to uncompress the rest of the packet + correctly. + + Trying again with HC1 compression, I see other isses. The first + frame is received correctly, but the following frames have an incorrect + packet length and generate RX FIFO errors. Forcing the send size to + 12 bytes of payload in apps/examples/udp (vs 96), eliminates this + problem and the broadcast works well. + + There is probably another issue related to broadcast TX setup: If + we are sending to the multicast or broadcast address, should we + not also disable ACKs, retries, and RX timeouts? What will happen + if multiple radios ACK? At a minimum it could keep the driver + unnecessarily busy. There is some prototype code to do just this + in the driver, but does not seem to work. + + 2017-08-26: There was only a single buffer for reassemblying larger + packets. This could be a problem issue for the hub configuration + which really needs the capability concurrently reassemble multiple + incoming streams. The design was extended to support multiple + reassembly buffers. + + Initial testing shows the same basic behavior as noted before: + The UDP test works and TCP test (usually) works. There are, + however, are errors in reported by the hub in the TCP test. + Occasionally the test will hang when the server echoes the data + back to the client. These errors are presumably the result of ACKs + from the receiver colliding with frames from the sender. + + Needs more investigation. + + 2017-09-08: The HC06 all nodes address decode problem mentioned on + 2017-08-08 has been corrected. The behavior in the test case has + not yet been reverified. I suspect that there made to some radio + configuration problems that are causing the RX FIFO errors and the + strange broadcast behavior. I recently got an STEVAL-IDS001V5M + sniffer that should tell me what is going on. But I have not yet + had sufficient free time to continue this testing. diff --git a/Documentation/platforms/arm/stm32l4/boards/nucleo-l432kc/index.rst b/Documentation/platforms/arm/stm32l4/boards/nucleo-l432kc/index.rst new file mode 100644 index 00000000000..2604358e214 --- /dev/null +++ b/Documentation/platforms/arm/stm32l4/boards/nucleo-l432kc/index.rst @@ -0,0 +1,449 @@ +================ +ST Nucleo L432KC +================ + +This page discusses issues unique to NuttX configurations for the ST +Nucleo-l432kc board from ST Micro. See + + http://www.st.com/nucleo-l432kc + +NucleoL432KC: + +- Microprocessor: 32-bit ARM Cortex M4 at 80MHz STM32L432KCU6 +- Memory: 256 KB Flash and 64 KB SRAM +- ADC: 1×12-bit, 5 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 five 16-bit, one 32-bit, two low-power + 16 bit timers, two watchdog timers, and a SysTick timer +- GPIO: Up to 26 I/O ports with interrupt capability, most 5v tolerant +- I2C: Up to 2 × I2C interfaces +- USARTs: Up to 3 USARTs, 2 UARTs, 1 LPUART +- SPIs: Up to 2 SPIs +- SAIs: 1 dual-channel audio interface +- CAN interface +- QSPI interface +- USB: USB 2.0 full-speed device/host/OTG controller with on-chip PHY +- CRC calculation unit +- RTC + +Board features: + +- Peripherals: 1 led +- Debug: Serial wire debug and JTAG interfaces via on-board micro-usb stlink v2.1 +- Expansion I/F Arduino Nano 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-L432KC for more +information about these boards. + +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 /nuttx.:: + + $ tools/configure.sh nucleo-l432kc:nsh + $ make qconfig + $ V=1 make context all 2>&1 | tee mout + +2. Download the latest buildroot package into + +3. unpack the buildroot tarball. The resulting directory may + have versioning information on it like buildroot-x.y.z. If so, + rename /buildroot-x.y.z to /buildroot. + +4. cd /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 /nuttx.:: + + tools/configure.sh lpcxpresso-lpc1768: + +2. Download the latest buildroot package into + +3. unpack the buildroot tarball. The resulting directory may + have versioning information on it like buildroot-x.y.z. If so, + rename /buildroot-x.y.z to /buildroot. + +4. cd /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-L432KC includes boot loader from mbed: + + https://mbed.org/handbook/Homepage + +Using the mbed loader: + +1. Connect the Nucleo-L432kc 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-L432kc. The NUCLEO window will + close then re-open and the Nucleo-L432KC will be running the new code. + +Hardware +======== + +LEDs +---- + +The Nucleo L432KC provides a single user LED, LD3. LD3 +is the green LED connected to Arduino signal D13 corresponding to MCU I/O +PB3 (pin 26). + +- 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 LED is available: + + =================== ======================= =========== + SYMBOL Meaning LD3 + =================== ======================= =========== + 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 LD3, NuttX has successfully booted and is, apparently, running +normally. If LD3 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 STM32L432KC + ----------- ------------ + 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 STM32L432KC + ----------- ------------ + 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 + +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. + +SPI Flash support: +================== + +We can use an external SPI Serial Flash with nucleo-l432kc board. In this +case we tested with AT45DB081D (8Mbit = 1MiB). + +You can connect the AT45DB081D memory in the nucleo-l432kc board this way: + + ======== =============== + Memory nucleo-l432kc + ======== =============== + SI D11 (PB5) + SCK D13 (PB3) + RESET 3V3 + CS D10 (PA11) + WP 3V3 + VCC 3V3 + GND GND + SO D12 (PB4) + ======== =============== + +You can start with default "nucleo-l432kc/nsh" configuration option and +enable/disable these options using "make menuconfig" :: + + System Type ---> + STM32L4 Peripheral Support ---> + [*] SPI1 + + Device Drivers ---> + -*- Memory Technology Device (MTD) Support ---> + -*- SPI-based AT45DB flash + (1000000) AT45DB Frequency + + File Systems ---> + [*] NXFFS file system + + Then after compiling and flashing the file nuttx.bin you can test the flash + this way: + + nsh> ls /mnt + /mnt: + at45db/ + + nsh> echo "Testing" > /mnt/at45db/file.txt + + nsh> ls /mnt/at45db + /mnt/at45db: + file.txt + + nsh> cat /mnt/at45db/file.txt + Testing + + nsh> + +Configurations +============== + +nsh: +---- + +Configures the NuttShell (nsh) located at apps/examples/nsh for the +Nucleo-L432KC 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 STM32L432KC + ----------- ------------ + 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 + +spwm +---- + +Configures the sinusoidal PWM (SPWM) example which presents a simple use case +of the STM32L4 PWM lower-half driver without generic upper-half PWM logic. + +It uses TIM1 to generate PWM and TIM6 to change waveform samples + +At the moment, the waveform parameters are hardcoded, but it should be easy to +modify this example and make it more functional. diff --git a/Documentation/platforms/arm/stm32l4/boards/nucleo-l452re/index.rst b/Documentation/platforms/arm/stm32l4/boards/nucleo-l452re/index.rst new file mode 100644 index 00000000000..fed70259920 --- /dev/null +++ b/Documentation/platforms/arm/stm32l4/boards/nucleo-l452re/index.rst @@ -0,0 +1,238 @@ +================ +ST Nucleo L452RE +================ + +This page file discusses the port of NuttX to the STMicro Nucleo-L452RE +board. That board features the STM32L452RET6 MCU with 512KiB of FLASH +and 160KiB of SRAM. + +LEDs +==== + +The Nucleo-64 board has one user controllable LED, User LD2. This green +LED is a user LED connected to Arduino signal D13 corresponding to STM32 +I/O PA5 (PB13 on other some other Nucleo-64 boards). + +- 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/stm32_autoleds.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. + +Buttons +======= + +B1 USER: the user button is connected to the I/O PC13 (pin 2) of the STM32 +microcontroller. + +Serial Console +============== + +USART1 +------ + +Pins and Connectors:: + + RXD: PA10 D3 CN9 pin 3, CN10 pin 33 + PB7 CN7 pin 21 + TXD: PA9 D8 CN5 pin 1, CN10 pin 21 + PB6 D10 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 STM32F072RB + ----------- ------------ + Pin 21 PA9 USART1_TX *Warning you make need to reverse RX/TX on + Pin 33 PA10 USART1_RX 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 To be provided + PA15 + PD6 + TXD: PA2 + PA14 + PD5 + +See "Virtual COM Port" and "RS-232 Shield" below. + +USART3 +------ + +Pins and Connectors:: + + RXD: PB11 To be provided + PC5 + PC11 + D9 + TXD: PB10 + PC4 + PC10 + D8 + +USART4 +------ + +Pins and Connectors:: + + RXD: PA1 To be provided + PC11 + TXD: PA0 + PC10 + +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. + +115200 8N1 BAUD should be configure to interface with the Virtual COM +port. + +Default +------- + +As shipped, SB62 and SB63 are open and SB13 and SB14 closed, so the +virtual COM port is enabled. + +RS-232 Shield +------------- + +Supports a single RS-232 connected via:: + + Nucleo STM32F4x1RE Shield + --------- --------------- -------- + CN9 Pin 1 PA3 USART2_RXD RXD + CN9 Pin 2 PA2 USART2_TXD TXD + +Support for this shield is enabled by selecting USART2 and configuring +SB13, 14, 62, and 63 as described above under "Virtual COM Port" + +Configurations +============== + +Information Common to All Configurations +---------------------------------------- + +Each configuration is maintained in a sub-directory and can be +selected as follow:: + + tools/configure.sh nucleo-l452re: + +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 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 USART2, as described above under "Serial Console". The + elevant configuration settings are listed below:: + + CONFIG_STM32_USART2=y + CONFIG_STM32_USART2_SERIALDRIVER=y + CONFIG_STM32_USART=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 + +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: + + Build Setup:: + + CONFIG_HOST_LINUX=y : Linux environment + + System Type -> Toolchain:: + + CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : GNU ARM EABI toolchain + +Configuration sub-directories +----------------------------- + +nsh: +---- + +Configures the NuttShell (nsh) located at examples/nsh. This +configuration is focused on low level, command-line driver testing. diff --git a/Documentation/platforms/arm/stm32l4/boards/nucleo-l476rg/index.rst b/Documentation/platforms/arm/stm32l4/boards/nucleo-l476rg/index.rst new file mode 100644 index 00000000000..8ca187c36ad --- /dev/null +++ b/Documentation/platforms/arm/stm32l4/boards/nucleo-l476rg/index.rst @@ -0,0 +1,567 @@ +================ +ST Nucleo L476RG +================ + +This page discusses issues unique to NuttX configurations for the ST +NucleoL476RG board from ST Micro. See + + http://www.st.com/nucleo-l476rg + +NucleoL476RG: + +- Microprocessor: 32-bit ARM Cortex M4 at 80MHz STM32L476RGT6 +- Memory: 1024 KB Flash and 96+32 KB SRAM +- ADC: 2×12-bit, 2.4 MSPS A/D converter: up to 24 channels +- DMA: 16-stream DMA controllers with FIFOs and burst support +- Timers: Up to 11 timers: up to eight 16-bit, two 32-bit timers, two + watchdog timers, and a SysTick timer +- GPIO: Up to 51 I/O ports with interrupt capability +- I2C: Up to 3 × I2C interfaces +- USARTs: Up to 3 USARTs, 2 UARTs, 1 LPUART +- SPIs: Up to 3 SPIs +- SAIs: Up to 2 dual-channel audio interfaces +- CAN interface +- SDIO interface +- QSPI interface +- USB: USB 2.0 full-speed device/host/OTG controller with on-chip PHY +- CRC calculation unit +- RTC + +Board features: + +- 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-L476RG for more +information about these boards. + +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 /nuttx.:: + + $ tools/configure.sh nucleo-l476rg:nsh + $ make qconfig + $ V=1 make context all 2>&1 | tee mout + +2. Download the latest buildroot package into + +3. unpack the buildroot tarball. The resulting directory may + have versioning information on it like buildroot-x.y.z. If so, + rename /buildroot-x.y.z to /buildroot. + +4. cd /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 /nuttx. + + tools/configure.sh lpcxpresso-lpc1768: + +2. Download the latest buildroot package into + +3. unpack the buildroot tarball. The resulting directory may + have versioning information on it like buildroot-x.y.z. If so, + rename /buildroot-x.y.z to /buildroot. + +4. cd /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-L476RG includes boot loader from mbed: + + https://mbed.org/platforms/ST-Nucleo-L476RG/ + 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-L476RG/ + +Buttons +------- + +B1 USER: the user button is connected to the I/O PC13 (pin 2) of the STM32 +microcontroller. + +LEDs +---- + +The Nucleo L476RG 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_L476RG_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_L476RG_AJOY_MINBUTTONS to eliminate the + conflict. +- Current showstopper: I appear to be getting infinite interrupts as + soon as joystick button interrupts are enabled. + +Other External Hardware/Devices +=============================== + +Using external SPI SDCard +------------------------- + +It is possible to use external SDCard over SPI with the +nucleo-stm32l476rg Cortex-M4. This option will or can broaden the +functionality in your project, solution or application. + +In this NuttX project we attach an MH-SD Card Module (SPI). +[http://www.geeetech.com/wiki/index.php/Arduino_SD_card_Module] + +Other solutions should also work. + + ============ ============ + Nucleo CN10 STM32L4x6RG + ============ ============ + Pin 31 PB3 SLCK + Pin 27 PB4 MISO + Pin 29 PB5 MOSI + Pin 25 PB10 CS + ============ ============ + + =========== ============ + Nucleo CN7 STM32L4x6RG + =========== ============ + Pin 18 +5V 5V + Pin 22 GND GND + =========== ============ + +On the board the pins are labeled and are corresponding with the functions +as written before. +Configuring can be done by using ./tools/configure.sh nucleo-l476rg/spimmcsd + +Configurations +============== + +nsh +--- + +Configures the NuttShell (nsh) located at apps/examples/nsh for the +Nucleo-L476RG 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 + +nxdemo +------ + +This is an NSH configuration that enables the NX graphics demo at +apps/examples/nxdemo. It uses the PCD8544 display on SPI1. diff --git a/Documentation/platforms/arm/stm32l4/boards/nucleo-l496zg/index.rst b/Documentation/platforms/arm/stm32l4/boards/nucleo-l496zg/index.rst new file mode 100644 index 00000000000..df3a2b41a84 --- /dev/null +++ b/Documentation/platforms/arm/stm32l4/boards/nucleo-l496zg/index.rst @@ -0,0 +1,256 @@ +================ +ST Nucleo L496ZG +================ + +This page discusses issues unique to NuttX configurations for the STMicro +Nucleo-144 board for STM32L4 chips. + +Nucleo L496ZG +============= + +ST Nucleo L496ZG board from ST Micro is supported. See + +http://www.st.com/content/st_com/en/products/evaluation-tools/product-evaluation-tools/mcu-eval-tools/stm32-mcu-eval-tools/stm32-mcu-nucleo/nucleo-l496zg.html + +The Nucleo L496ZG order part number is NUCLEO-L496ZG. It is one member of +the STM32 Nucleo-144 board family. + +NUCLEO-L496ZG Features +---------------------- + +- Microprocessor: STM32L496ZGT6 Core: ARM 32-bit Cortex®-M4 CPU with FPU, + 80 MHz, MPU, and DSP instructions. +- Memory: 1024 KB Flash 320KB of SRAM (including 64KB of SRAM2) +- ADC: 3×12-bit: up to 24 channels +- DMA: 2 X 7-stream DMA controllers with FIFOs and burst support +- Timers: Up to 13 timers: (2x 16-bit lowpower), two 32-bit timers, + 2x watchdogs, SysTick +- GPIO: 114 I/O ports with interrupt capability +- LCD: LCD-TFT Controller, Parallel interface +- I2C: 4 × I2C interfaces (SMBus/PMBus) +- U[S]ARTs: 3 USARTs, 2 UARTs (27 Mbit/s, ISO7816 interface, LIN, IrDA, + modem control) +- SPI/12Ss: 6/3 (simplex) (up to 50 Mbit/s), 3 with muxed simplex I2S + for audio class accuracy via internal audio PLL or external + clock +- QSPI: Dual mode Quad-SPI +- SAIs: 2 Serial Audio Interfaces +- CAN: 2 X CAN interface +- SDMMC interface +- USB: USB 2.0 full-speed device/host/OTG controller with on-chip PHY +- Camera Interface: 8/14 Bit +- CRC calculation unit +- TRG: True random number generator +- RTC + +See https://developer.mbed.org/platforms/ST-Nucleo-L496ZG for additional +information about this board. + +Hardware +======== +Section needs updating + +GPIO - there are 144 I/O lines on the STM32L4xxZx with various pins pined out +on the Nucleo 144. + +Keep in mind that: + +- The I/O is 3.3 Volt not 5 Volt like on the Arduino products. +- The Nucleo-144 board family has 3 pages of Solder Bridges AKA Solder + Blobs (SB) that can alter the factory configuration. We will note SB + in effect but will assume the factory default settings. + +Our main concern is establishing a console and LED utilization for +debugging. + +Buttons +------- + +B1 USER: the user button is connected to the I/O PC13 (Tamper support, SB173 +ON and SB180 OFF) + +LEDs +---- + +The Board provides a 3 user LEDs, LD1-LD3 +LED1 (Green) PB_0 (SB120 ON and SB119 OFF) +LED2 (Blue) PB_7 (SB139 ON) +LED3 (Red) PB_14 (SP118 ON) + +- When the I/O is HIGH value, the LEDs are on. +- When the I/O is LOW, the LEDs are 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/stm32_autoleds.c. The LEDs are used to encode OS +related events as follows when the LEDs are available: + + =================== ======================= === ===== ==== + SYMBOL Meaning RED GREEN BLUE + =================== ======================= === ===== ==== + LED_STARTED NuttX has been started OFF OFF OFF + LED_HEAPALLOCATE Heap has been allocated OFF OFF ON + LED_IRQSENABLED Interrupts enabled OFF ON OFF + LED_STACKCREATED Idle stack created OFF ON ON + LED_INIRQ In an interrupt NC NC ON (momentary) + LED_SIGNAL In a signal handler NC ON OFF (momentary) + LED_ASSERTION An assertion failed ON NC ON (momentary) + LED_PANIC The system has crashed ON OFF OFF (flashing 2Hz) + LED_IDLE MCU is is sleep mode ON OFF OFF + =================== ======================= === ===== ==== + +OFF - means that the OS is still initializing. Initialization is very fast + so if you see this at all, it probably means that the system is + hanging up somewhere in the initialization phases. + +GREEN - This means that the OS completed initialization. + +BLUE - Whenever and interrupt or signal handler is entered, the BLUE LED is + illuminated and extinguished when the interrupt or signal handler + exits. + +VIOLET - If a recovered assertion occurs, the RED and blue LED will be + illuminated briefly while the assertion is handled. You will + probably never see this. + +Flashing RED - In the event of a fatal crash, all other LEDs will be + extinguished and RED LED will FLASH at a 2Hz rate. + +Thus if the GREEN LED is lit, NuttX has successfully booted and is, +apparently, running normally. If the RED LED is flashing at +approximately 2Hz, then a fatal error has been detected and the system has +halted. + +Serial Consoles +=============== + +USART3 +------ + +Default board is configured to use USART3 as console. + +Pins and Connectors:: + + FUNC GPIO Connector + Pin NAME + ---- --- ------- ---- + TXD: PC4 CN8-9, A4 + RXD: PC5 CN8-11, A5 + ---- --- ------- ---- + +You must use a 3.3 TTL to RS-232 converter or a USB to 3.3V TTL:: + + Nucleo 144 FTDI TTL-232R-3V3 + ------------- ------------------- + TXD - CN8-9 - RXD - Pin 5 (Yellow) + RXD - CN8-11 - TXD - Pin 4 (Orange) + GND - GND Pin 1 (Black) + ------------- ------------------- + + *Note you will be reverse RX/TX + +Use make menuconfig to configure USART3 as the console:: + + CONFIG_STM32L4_USART3=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 + +USART2 +------ + +USART 2 could be used as console as well. + +Virtual COM Port +---------------- + +Yet another option is to use LPUART1 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. However the LPUART peripheral has not yet +been tested for this board. + +Solder Bridges. This configuration requires:: + + PG7 LPUART1 TX SB131 ON and SB195 OFF (Default) + PG8 LPUART1 RX SB130 ON and SB193 OFF (Default) + +Default +------- + +As shipped, the virtual COM port is enabled. + +SPI +--- + +Since this board is so generic, having a quick way to vet the SPI +configuration seams in order. So the board provides a quick test +that can be selected vi CONFIG_NUCLEO_SPI_TEST that will initialize +the selected buses (SPI1-SPI3) and send some text on the bus at +application initialization time board_app_initialize. + +SDIO +---- + +To test the SD performance one can use a SparkFun microSD Sniffer +from https://www.sparkfun.com/products/9419 or similar board +and connect it as follows:: + + VCC V3.3 CN11 16 + GND GND CN11-8 + CMD PD2 CN11-4 + CLK PC12 CN11-3 + DAT0 - PC8 CN12-2 + DAT1 - PC9 CN12-1 + DAT2 PC10 CN11-1 + CD PC11 CN11-2 + +Configurations +============== + +nsh +--- + +Configures the NuttShell (nsh) located at apps/examples/nsh for the +Nucleo-144 boards. The Configuration enables the serial interfaces +on USART6. 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. If this is the initial configuration then execute:: + + ./tools/configure.sh nucleo-l496zg:nsh + + in nuttx/ in order to start configuration process. + Caution: Doing this step more than once will overwrite .config with + the contents of the nucleo-l496zg/nsh/defconfig file. + + c. Execute 'make oldconfig' in nuttx/ in order to refresh the + configuration. + + d. Execute 'make menuconfig' in nuttx/ in order to start the + reconfiguration process. + + e. Save the .config file to reuse it in the future starting at step d. + +2. By default, this configuration uses the ARM GNU toolchain + for Linux. That can easily be reconfigured, of course.:: + + CONFIG_HOST_LINUX=y : Builds under Linux + CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : ARM GNU for Linux + +3. Although the default console is LPUART1 (which would correspond to + the Virtual COM port) I have done all testing with the console + device configured for USART3 (see instruction above under "Serial + Consoles). diff --git a/boards/arm/stm32l4/steval-stlcs01v1/README.txt b/Documentation/platforms/arm/stm32l4/boards/steval-stlcs01v1/index.rst similarity index 50% rename from boards/arm/stm32l4/steval-stlcs01v1/README.txt rename to Documentation/platforms/arm/stm32l4/boards/steval-stlcs01v1/index.rst index c4c89b3a0b9..d0b22925a2b 100644 --- a/boards/arm/stm32l4/steval-stlcs01v1/README.txt +++ b/Documentation/platforms/arm/stm32l4/boards/steval-stlcs01v1/index.rst @@ -1,17 +1,16 @@ -README -====== +=================== +ST STEVAL-STLCS01V1 +=================== This README discusses issues unique to NuttX configurations for the ST STEVAL-STLCS01V1 board (SensorTile module) from ST Micro based on STM32L476JG MCU. The board features: - - LSM6DSM, 6DoF inertial measurement unit (IMU), - - LSM303AGR, 3D accelerometer and 3D magnetometer, - - LPS22HB, pressure sensor, - - MP34DT05-A, omni-directional digital microphone - - BlueNRG-MS, SPI based BLE Network Processor +- LSM6DSM, 6DoF inertial measurement unit (IMU), +- LSM303AGR, 3D accelerometer and 3D magnetometer, +- LPS22HB, pressure sensor, +- MP34DT05-A, omni-directional digital microphone +- BlueNRG-MS, SPI based BLE Network Processor Refer to https://www.st.com/en/evaluation-tools/steval-stlkt01v1.html for further information about this board. - - diff --git a/boards/arm/stm32l4/stm32l476-mdk/README.txt b/Documentation/platforms/arm/stm32l4/boards/stm32l476-mdk/index.rst similarity index 62% rename from boards/arm/stm32l4/stm32l476-mdk/README.txt rename to Documentation/platforms/arm/stm32l4/boards/stm32l476-mdk/index.rst index 68d1b803580..75edf151c0b 100644 --- a/boards/arm/stm32l4/stm32l476-mdk/README.txt +++ b/Documentation/platforms/arm/stm32l4/boards/stm32l476-mdk/index.rst @@ -1,53 +1,53 @@ -README -====== +============= +STM32L476-mdk +============= -This README discusses issues unique to NuttX configurations for STM32L476ME +This page discusses issues unique to NuttX configurations for STM32L476ME part in the Motorola MDK. This is referred to as the MuC in Motorola technical documentation. STM32L476ME: - Microprocessor: 32-bit ARM Cortex M4 at 80MHz STM32L476ME - Memory: 1024 KB Flash and 96+32 KB SRAM - ADC: 3x12-bit, 2.4 MSPS A/D converter: up to 24 channels - DMA: 16-stream DMA controllers with FIFOs and burst support - Timers: Up to 11 timers: up to eight 16-bit, two 32-bit timers, two - watchdog timers, and a SysTick timer - GPIO: Up to 51 I/O ports with interrupt capability - I2C: Up to 3 x I2C interfaces - USARTs: Up to 3 USARTs, 2 UARTs, 1 LPUART - SPIs: Up to 3 SPIs - SAIs: Up to 2 dual-channel audio interfaces - CAN interface - SDIO interface (not connected) - QSPI interface (not connected) - USB: USB 2.0 full-speed device/host/OTG controller with on-chip PHY - CRC calculation unit - RTC +- Microprocessor: 32-bit ARM Cortex M4 at 80MHz STM32L476ME +- Memory: 1024 KB Flash and 96+32 KB SRAM +- ADC: 3x12-bit, 2.4 MSPS A/D converter: up to 24 channels +- DMA: 16-stream DMA controllers with FIFOs and burst support +- Timers:Up to 11 timers: up to eight 16-bit, two 32-bit timers, two + watchdog timers, and a SysTick timer +- GPIO: Up to 51 I/O ports with interrupt capability +- I2C: Up to 3 x I2C interfaces +- USARTs: Up to 3 USARTs, 2 UARTs, 1 LPUART +- SPIs: Up to 3 SPIs +- SAIs: Up to 2 dual-channel audio interfaces +- CAN interface +- SDIO interface (not connected) +- QSPI interface (not connected) +- USB: USB 2.0 full-speed device/host/OTG controller with on-chip PHY +- CRC calculation unit +- RTC Acronyms ======== - MDK is, of course, the Motorola Development Kit. - MuC is the acronym that is used to refer to the STM32L476ME on the MDK - board. - MHB is the acronym given to Toshiba Interface Bridge, part number T6WV7XBG. - See https://toshiba.semicon-storage.com/us/product/assp/interface-bridge.html - NuttX runs the MuC. +MDK is, of course, the Motorola Development Kit. +MuC is the acronym that is used to refer to the STM32L476ME on the MDK board. +MHB is the acronym given to Toshiba Interface Bridge, part number T6WV7XBG. +See https://toshiba.semicon-storage.com/us/product/assp/interface-bridge.html +NuttX runs the MuC. Flashing ======== The MDK has a built-in FTDI to support flashing from openocd. There are a few extensions to openocd that haven't been integrated upstream yet. To -flash (or debug) the MDK, you will need the code from: +flash (or debug) the MDK, you will need the code from:: $ git clone https://github.com/MotorolaMobilityLLC/openocd Refer to detailed OpenOCD build instructions at developer.motorola.com After building, you can flash the STM32L476 (MuC) with the following -command: +command:: $ openocd -f board/moto_mdk_muc.cfg -c "program nuttx.bin 0x08000000 reset exit" @@ -58,17 +58,17 @@ Switch B4 must be in the ON position. See the MDK User Guide at developer.motorola.com for more information on the hardware including the DIP switches. -Or you can use the GDB server. To start the GDB server: +Or you can use the GDB server. To start the GDB server:: $ openocd -f board/moto_mdk_mu_reset.cfg & -Then start GDB: +Then start GDB:: $ arm-none-linux-gdb (gdb) target extended-remote localhost:3333 (gdb) set can-use-hw-watchpoints 1 -You can load code into FLASH like: +You can load code into FLASH like:: (gdb) mon halt (gdb) load nuttx @@ -93,7 +93,7 @@ device at 11500 baud, no parity, 8 bits of data, 1 stop bit (115200 8N1 in minicom-speak) and with no flow control. Minicom works well. You will probably need to be super-user in order access the /dev/ttyUSB2 -device: +device:: $ sudo minicom mdk @@ -101,7 +101,7 @@ When mdk is the name of my saved configuration using the above serial configuration. The Motorola documentation also mentions picocom. NSH also works well with -picocom: +picocom:: $ sudo apt install picocom $ sudo picocom -b 115200 /dev/ttyUSB2 diff --git a/Documentation/platforms/arm/stm32l4/boards/stm32l476vg-disco/index.rst b/Documentation/platforms/arm/stm32l4/boards/stm32l476vg-disco/index.rst new file mode 100644 index 00000000000..ebd169aa1eb --- /dev/null +++ b/Documentation/platforms/arm/stm32l4/boards/stm32l476vg-disco/index.rst @@ -0,0 +1,527 @@ +==================== +ST STM32L476VG-DISCO +==================== + +XXX all this needs review and update + +This page discusses issues unique to NuttX configurations for the ST +STM32L476VG Discovery board from ST Micro. See + + http://www.st.com/stm32l476g-disco + +STM32L476VG: + +- Microprocessor: 32-bit ARM Cortex M4 at 80MHz STM32L476VGT6 +- Memory: 1024 KB Flash and 96+32 KB SRAM +- ADC: 3x12-bit, 2.4 MSPS A/D converter: up to 24 channels +- DMA: 16-stream DMA controllers with FIFOs and burst support +- Timers: Up to 11 timers: up to eight 16-bit, two 32-bit timers, two + watchdog timers, and a SysTick timer +- GPIO: Up to 51 I/O ports with interrupt capability +- I2C: Up to 3 x I2C interfaces +- USARTs: Up to 3 USARTs, 2 UARTs, 1 LPUART +- SPIs: Up to 3 SPIs +- SAIs: Up to 2 dual-channel audio interfaces +- CAN interface +- SDIO interface +- QSPI interface +- USB: USB 2.0 full-speed device/host/OTG controller with on-chip PHY +- CRC calculation unit +- RTC + +Board features: + +- Peripherals: 2 led, 1 d-pad joystick, 2 x LED, LCD, USC OTG FS, SAI stereo + Digital Microphone, MEMS Accelerometer, Magnetometer, + Gyroscope, 128 Mbit QSPI Flash, current ammeter +- Debug: Serial wire debug and JTAG interfaces + +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-L476RG 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 + Pin 33 PA10 USART1_TX + Pin 20 GND + Pin 8 U5V + =========== ============ + + Warning you make need to reverse RX/TX on some RS-232 converters + +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 + Pin 2 PA2 USART2_TX + =========== ============ + + Warning you make need to reverse RX/TX on 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 +============== + +knsh +---- + +This is identical to the nsh configuration below except that (1) NuttX +is built as a PROTECTED mode, monolithic module and the user applications +are built separately and, as a consequence, (2) some features that are +only available in the FLAT build are disabled. + +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) + +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 except files in .hex, .mot, .srec, 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. + +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 Generic 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 : Generic 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. + +4. This example has been used to verify the OTGFS functionality. USB is + not enabled in the default configuration but can be enabled with the + following settings:: + + CONFIG_STM32L4_OTGFS=y + + CONFIG_USBDEV=y + CONFIG_USBDEV_SELFPOWERED=y + + These will enable the USB CDC/ACM serial device:: + + CONFIG_CDCACM=y + CONFIG_CDCACM_EP0MAXPACKET=64 + CONFIG_CDCACM_EPINTIN=1 + CONFIG_CDCACM_EPINTIN_FSSIZE=64 + CONFIG_CDCACM_EPINTIN_HSSIZE=64 + CONFIG_CDCACM_EPBULKOUT=3 + CONFIG_CDCACM_EPBULKOUT_FSSIZE=64 + CONFIG_CDCACM_EPBULKOUT_HSSIZE=512 + CONFIG_CDCACM_EPBULKIN=2 + CONFIG_CDCACM_EPBULKIN_FSSIZE=64 + CONFIG_CDCACM_EPBULKIN_HSSIZE=512 + CONFIG_CDCACM_NRDREQS=4 + CONFIG_CDCACM_NWRREQS=4 + CONFIG_CDCACM_BULKIN_REQLEN=96 + CONFIG_CDCACM_RXBUFSIZE=257 + CONFIG_CDCACM_TXBUFSIZE=193 + CONFIG_CDCACM_VENDORID=0x0525 + CONFIG_CDCACM_PRODUCTID=0xa4a7 + CONFIG_CDCACM_VENDORSTR="NuttX" + CONFIG_CDCACM_PRODUCTSTR="CDC/ACM Serial" + + CONFIG_SERIAL_REMOVABLE=y + + These will enable the USB serial example at apps/examples/usbserial:: + + CONFIG_BOARDCTL_USBDEVCTRL=y + + CONFIG_EXAMPLES_USBSERIAL=y + CONFIG_EXAMPLES_USBSERIAL_BUFSIZE=512 + CONFIG_EXAMPLES_USBSERIAL_TRACEINIT=y + CONFIG_EXAMPLES_USBSERIAL_TRACECLASS=y + CONFIG_EXAMPLES_USBSERIAL_TRACETRANSFERS=y + CONFIG_EXAMPLES_USBSERIAL_TRACECONTROLLER=y + CONFIG_EXAMPLES_USBSERIAL_TRACEINTERRUPTS=y + + Optional USB debug features:: + + CONFIG_DEBUG_FEATURES=y + CONFIG_DEBUG_USB=y + CONFIG_ARCH_USBDUMP=y + CONFIG_USBDEV_TRACE=y + CONFIG_USBDEV_TRACE_NRECORDS=128 + CONFIG_USBDEV_TRACE_STRINGS=y + CONFIG_USBDEV_TRACE_INITIALIDSET=y + + CONFIG_NSH_USBDEV_TRACE=y + CONFIG_NSH_USBDEV_TRACEINIT=y + CONFIG_NSH_USBDEV_TRACECLASS=y + CONFIG_NSH_USBDEV_TRACETRANSFERS=y + CONFIG_NSH_USBDEV_TRACECONTROLLER=y + CONFIG_NSH_USBDEV_TRACEINTERRUPTS=y diff --git a/Documentation/platforms/arm/stm32l4/boards/stm32l4r9ai-disco/index.rst b/Documentation/platforms/arm/stm32l4/boards/stm32l4r9ai-disco/index.rst new file mode 100644 index 00000000000..dc2cda4d3a9 --- /dev/null +++ b/Documentation/platforms/arm/stm32l4/boards/stm32l4r9ai-disco/index.rst @@ -0,0 +1,421 @@ +==================== +ST STM32L4R9AI-DISCO +==================== + +This page discusses issues unique to NuttX configurations for the ST +STM32L4R9AI Discovery board from ST Micro. See + + https://www.st.com/content/st_com/en/products/evaluation-tools/product-evaluation-tools/mcu-eval-tools/stm32-mcu-eval-tools/stm32-mcu-discovery-kits/32l4r9idiscovery.html + +STM32L4R9AI: + +- Microprocessor: 32-bit ARM Cortex M4 at 120MHz STM32L4R9AI +- Memory: 2048 KB Flash and 192+64+384 KB SRAM +- ADC: 1x12-bit, 5 MSPS A/D converter: up to 14 external channels +- DAC: 2 channels +- DFSDM: 4 filters, 8 channels +- DMA: 16-stream DMA controllers with FIFOs and burst support +- Timers: Up to 11 timers: up to eight 16-bit, two 32-bit timers, two + watchdog timers, and a SysTick timer +- GPIO: Up to 131 I/O ports with interrupt capability +- I2C: Up to 4 x I2C interfaces +- USARTs:Up to 3 USARTs, 2 UARTs, 1 LPUART +- SPIs: Up to 3 SPIs +- SAIs: Up to 2 dual-channel audio interfaces +- CAN interface +- SDIO interface +- OCTOSPI interface +- Camera interface +- USB: USB 2.0 full-speed device/host/OTG controller with on-chip PHY +- CRC calculation unit +- RTC + +Board features: + +- Peripherals: 1 d-pad joystick, 2 x LED, AMOLED display, USC OTG FS, + 2 x MEMS Digital Microphones, SAI codec, 16 Mbit PSRAM, + 512 Mbit OCTOSPI Flash, current ammeter +- Debug: Serial wire debug and JTAG interfaces + +Uses a STM32F103 to provide a ST-Link for programming, debug similar to the +OpenOcd FTDI function - USB to JTAG front-end. + +mbed +==== + +The STM32L4R9AI-DISCO includes boot loader from mbed: + + https://mbed.org/handbook/Homepage + +Using the mbed loader: + +1. Connect the board to the host PC using the USB connector. +2. A new file system will appear called DIS_L4R9AI; 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 board. The DIS_L49RAIO window will + close then re-open and the board will be running the new code. + +Hardware +======== + +Buttons +------- + +B1 USER: the user button is connected to the I/O PC13 (pin 2) of the STM32 +microcontroller. + +LEDs +---- + +The STM32L4R9AI-DISCO board provides two user LEDs, LD1 (orange) and LD2 (green). +PB0 is LD1 (orange) +PH4 is LD2 (green) +- 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/stm32_autoleds.c. The LEDs are used to encode OS-related +events as follows when the green LED (PH4) 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 is on, 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. + +U[S]ARTs and 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 + Pin 33 PA10 USART1_TX + Pin 20 GND + Pin 8 U5V + =========== ============ + + Warning you make need to reverse RX/TX on some RS-232 converters + + To configure USART1 as the console:: + + CONFIG_STM32L4_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 + + TTL to RS-232 converter connection: + + =========== ============ + Nucleo CN9 STM32F4x1RE + =========== ============ + Pin 1 PA3 USART2_RX + Pin 2 PA2 USART2_TX + =========== ============ + + Warning you make need to reverse RX/TX on 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_STM32L4_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 + +UART4 +----- + +Pins and Connectors:: + + RXD: PA1 -> CN11 D5 + TXD: PA0 -> CN17 A4 + +To configure USART4 as the console:: + + CONFIG_STM32L4_UART4=y + CONFIG_USART4_SERIALDRIVER=y + CONFIG_USART4_SERIAL_CONSOLE=y + CONFIG_USART4_RXBUFSIZE=512 + CONFIG_USART4_TXBUFSIZE=256 + CONFIG_USART4_BAUD=2000000 + CONFIG_USART4_BITS=8 + CONFIG_USART4_PARITY=0 + CONFIG_USART4_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. + +Segger J-Link +============= + +Reference: https://www.segger.com/downloads/application-notes/AN00021 + +1. Connect J-Link VTref (1) to pin VDD +2. Connect J-Link SWDIO (7) to pin PA13 +3. Connect J-Link SWCLK (9) to pin PA14 +4. Connect J-Link SWO (13) to pin PB3 +5. Connect J-Link RESET (15) to pin NRST +6. Connect J-Link 5V-Supply (19) to pin 5V +7. Connect J-Link GND (4) to pin GND + +Jumpers on CN4 (ST-Link) must be removed for external debug. + +Configurations +============== + +knsh +---- + +This is identical to the nsh configuration below except that (1) NuttX +is built as a PROTECTED mode, monolithic module and the user applications +are built separately and, as a consequence, (2) some features that are +only available in the FLAT build are disabled. + +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) + +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 except files in .hex, .mot, .srec, 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. + +nsh +--- + +Configures the NuttShell (nsh) located at apps/examples/nsh for the +STM32L4R9AI-DISCO board. The Configuration enables the serial interfaces +on UART4. 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: + + Execute 'make menuconfig' in nuttx/ in order to start the + reconfiguration process. + +2. By default, this configuration uses the Generic 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 : Generic EABI toolchain for Linux + +3. The default console is UART4 + +4. This example can be used to verify the OTGFS functionality. USB is + not enabled in the default configuration but can be enabled with the + following settings: (TODO: need to test!):: + + CONFIG_STM32L4_OTGFS=y + + CONFIG_USBDEV=y + CONFIG_USBDEV_SELFPOWERED=y + + These will enable the USB CDC/ACM serial device:: + + CONFIG_CDCACM=y + CONFIG_CDCACM_EP0MAXPACKET=64 + CONFIG_CDCACM_EPINTIN=1 + CONFIG_CDCACM_EPINTIN_FSSIZE=64 + CONFIG_CDCACM_EPINTIN_HSSIZE=64 + CONFIG_CDCACM_EPBULKOUT=3 + CONFIG_CDCACM_EPBULKOUT_FSSIZE=64 + CONFIG_CDCACM_EPBULKOUT_HSSIZE=512 + CONFIG_CDCACM_EPBULKIN=2 + CONFIG_CDCACM_EPBULKIN_FSSIZE=64 + CONFIG_CDCACM_EPBULKIN_HSSIZE=512 + CONFIG_CDCACM_NRDREQS=4 + CONFIG_CDCACM_NWRREQS=4 + CONFIG_CDCACM_BULKIN_REQLEN=96 + CONFIG_CDCACM_RXBUFSIZE=257 + CONFIG_CDCACM_TXBUFSIZE=193 + CONFIG_CDCACM_VENDORID=0x0525 + CONFIG_CDCACM_PRODUCTID=0xa4a7 + CONFIG_CDCACM_VENDORSTR="NuttX" + CONFIG_CDCACM_PRODUCTSTR="CDC/ACM Serial" + + CONFIG_SERIAL_REMOVABLE=y + + These will enable the USB serial example at apps/examples/usbserial:: + + CONFIG_BOARDCTL_USBDEVCTRL=y + + CONFIG_EXAMPLES_USBSERIAL=y + CONFIG_EXAMPLES_USBSERIAL_BUFSIZE=512 + CONFIG_EXAMPLES_USBSERIAL_TRACEINIT=y + CONFIG_EXAMPLES_USBSERIAL_TRACECLASS=y + CONFIG_EXAMPLES_USBSERIAL_TRACETRANSFERS=y + CONFIG_EXAMPLES_USBSERIAL_TRACECONTROLLER=y + CONFIG_EXAMPLES_USBSERIAL_TRACEINTERRUPTS=y + + Optional USB debug features::: + + CONFIG_DEBUG_FEATURES=y + CONFIG_DEBUG_USB=y + CONFIG_ARCH_USBDUMP=y + CONFIG_USBDEV_TRACE=y + CONFIG_USBDEV_TRACE_NRECORDS=128 + CONFIG_USBDEV_TRACE_STRINGS=y + CONFIG_USBDEV_TRACE_INITIALIDSET=y + + CONFIG_NSH_USBDEV_TRACE=y + CONFIG_NSH_USBDEV_TRACEINIT=y + CONFIG_NSH_USBDEV_TRACECLASS=y + CONFIG_NSH_USBDEV_TRACETRANSFERS=y + CONFIG_NSH_USBDEV_TRACECONTROLLER=y + CONFIG_NSH_USBDEV_TRACEINTERRUPTS=y + +nxhello +------- + +A simple NSH example using apps/examples/nxhello, a very simply test of +basic NX functionality. diff --git a/Documentation/platforms/arm/stm32l4/index.rst b/Documentation/platforms/arm/stm32l4/index.rst new file mode 100644 index 00000000000..4d094ae271c --- /dev/null +++ b/Documentation/platforms/arm/stm32l4/index.rst @@ -0,0 +1,114 @@ +========== +ST STM32L4 +========== + +Supported MCUs +============== + +This is a port of NuttX to the STM32L4 Family + +Used development boards are the Nucleo L476RG, Nucleo L496ZG, +Nucleo L452RE, Nucleo L432KC, STM32L4VG Discovery and +Motorola MDK. + +Most code is copied and adapted from the STM32 and STM32F7 ports. + +The various supported STM32L4 families are: + + +============ ======= ====== ================================ +MCU Support Manual Note +============ ======= ====== ================================ +STM32L471xx No RM0392 +STM32L4X1 Yes RM0394 Subset of STM32L4_STM32L4X3 [1] +STM32L4X2 Yes RM0394 Subset of STM32L4_STM32L4X3 [1] +STM32L4X3 Yes RM0394 +STM32L4X5 Yes RM0351 (was RM0395 in past) +STM32L4X6 Yes RM0351 +STM32L4XR Yes RM0432 (STM32L4+) +============ ======= ====== ================================ + +[1]: Please avoid depending on CONFIG_STM32L4_STM32L4X1 and +CONFIG_STM32L4_STM32L4X2 as the MCUs are of the same subfamily +as CONFIG_STM32L4_STM32L4X3. + +Peripheral Support +================== + +The following list indicates peripherals supported in NuttX: + +========== ======= ============================== +Peripheral Support Notes +========== ======= ============================== +IRQs Yes +GPIO Yes +EXTI Yes +HSI Yes +HSE Yes +PLL Yes Works @ 80 MHz +MSI Yes +LSE Yes +RCC Yes +SYSCTL Yes +USART Yes +DMA Yes +SRAM2 Yes +SPI Yes +I2C Yes +RTC Yes +QSPI Yes +CAN Yes +OTGFS Yes +Timers Yes +PM Yes +FSMC No +AES No +RNG Yes +CRC No configurable polynomial +WWDG No +IWDG Yes +SDMMC Yes +ADC Yes +DAC Yes +DMA2D No +========== ======= ============================== + +========== ======= ============================== +Peripheral Support Notes +========== ======= ============================== +FIREWALL Yes requires support from ldscript +TSC No +SWP No +LPUART Yes +LPTIM Yes +OPAMP No +COMP Yes +DFSDM Yes +LCD No +SAIPLL Yes +SAI Yes +HASH No +DCMI No +========== ======= ============================== + +New peripherals only in STM32L4+: + +========== ======= ============================== +Peripheral Support Notes +========== ======= ============================== +DMAMUX1 Yes +DSI No +GFXMMU No +LTDC No +OCTOSPI No +OCTOSPIIOM No +========== ======= ============================== + +Supported Boards +================ + +.. toctree:: + :glob: + :maxdepth: 1 + + boards/*/* diff --git a/arch/arm/src/stm32l4/README.txt b/arch/arm/src/stm32l4/README.txt deleted file mode 100644 index 4cb87056267..00000000000 --- a/arch/arm/src/stm32l4/README.txt +++ /dev/null @@ -1,103 +0,0 @@ -This is a port of NuttX to the STM32L4 Family - -Used development boards are the Nucleo L476RG, Nucleo L496ZG, -Nucleo L452RE, Nucleo L432KC, STM32L4VG Discovery and -Motorola MDK. - -Most code is copied and adapted from the STM32 and STM32F7 ports. - -The various supported STM32L4 families are: - ------------------------------------------------------------------ -| NuttX config | Manual | Chips -| -| Not supported | RM0392 | STM32L471xx -| -| STM32L4_STM32L4X1 | RM0394 | Subset of STM32L4_STM32L4X3 [*] -| -| STM32L4_STM32L4X2 | RM0394 | Subset of STM32L4_STM32L4X3 [*] -| -| STM32L4_STM32L4X3 | RM0394 | STM32L43xxx/44xxx/45xxx/46xxx -| -| STM32L4_STM32L4X5 | RM0351 | STM32L475xx (was RM0395 in past) -| -| STM32L4_STM32L4X6 | RM0351 | STM32L476xx, STM32L486xx, -| STM32L496xx, STM32L4A6xx -| -| STM32L4_STM32L4XR | RM0432 | STM32L4Rxxx, STM32L4Sxxx (STM32L4+) ------------------------------------------------------------------- - -[*]: Please avoid depending on CONFIG_STM32L4_STM32L4X1 and - CONFIG_STM32L4_STM32L4X2 as the MCUs are of the same subfamily - as CONFIG_STM32L4_STM32L4X3. - -TODO list ---------- - -Peripherals with implementation in STM32 port: - -IRQs : OK -GPIO : OK -EXTI : OK -HSI : OK -HSE : OK -PLL : Works @ 80 MHz -MSI : OK -LSE : OK -RCC : All registers defined, peripherals enabled, basic clock working -SYSCTL : All registers defined -USART : OK -DMA : OK -SRAM2 : OK; can be included in MM region or left separate for special app - : purposes -SPI : OK, tested (including DMA) -I2C : works -RTC : works -QSPI : works in polling, interrupt, DMA, and also memory-mapped modes -CAN : OK, tested -OTGFS : dev implemented, tested, outstanding issue with CDCACM - : (ACM_SET_LINE_CODING, but otherwise works); host implemented, - : only build smoke-tested (i.e. builds, but no functional testing - : yet) -Timers : Implemented, with PWM oneshot and freerun, tickless OS support. - : Limited testing (focused on tickless OS so far), PWM and QE tested OK. -PM : TODO, PWR registers defined -FSMC : TODO -AES : TODO -RNG : works -CRC : TODO (configurable polynomial) -WWDG : TODO -IWDG : works -SDMMC : works -ADC : works -DAC : works -DMA2D : TODO (Chrom-Art Accelerator for image manipulation) - -New peripherals with implementation to be written from scratch. -These are Low Priority TODO items, unless someone requests or contributes -it. - -FIREWALL : Code written, to be tested, requires support from ldscript -TSC : TODO (Touch Screen Controller) -SWP : TODO (Single wire protocol master, to connect with NFC enabled - : SIM cards) -LPUART : Experimental support (Low power UART working with LSE at low - : baud rates) -LPTIM : Code written, to be tested (Low power TIMER) -OPAMP : TODO (Analog operational amplifier) -COMP : There is some code (Analog comparators) -DFSDM : There is some code (Digital Filter for Sigma-Delta Modulators) -LCD : TODO (Segment LCD controller) -SAIPLL : works (PLL For Digital Audio interfaces, and other things) -SAI : There is some code (Digital Audio interfaces, I2S, SPDIF, etc) -HASH : TODO (SHA-1, SHA-224, SHA-256, HMAC) -DCMI : TODO (Digital Camera interfaces) - -New peripherals only in STM32L4+: - -DMAMUX1 : OK -DSI : TODO -GFXMMU : TODO -LTDC : TODO -OCTOSPI : TODO -OCTOSPIIOM : TODO diff --git a/boards/arm/stm32l4/b-l475e-iot01a/README.txt b/boards/arm/stm32l4/b-l475e-iot01a/README.txt deleted file mode 100644 index f9ebace8454..00000000000 --- a/boards/arm/stm32l4/b-l475e-iot01a/README.txt +++ /dev/null @@ -1,634 +0,0 @@ -README -====== - - This README discusses the port of NuttX to the STMicro B-L475E-IOT01A - Discovery kit powered by STM32L475VG Cortex-M4. This board targets IoT - nodes with a choice of connectivity options including WiFi, Bluetooth LE, - NFC, and sub-GHZ RF at 868 or 915 MHz, as well as a long list of various - environmental sensors. - -Contents -======== - - o STATUS - o Board Features - o LEDs and Buttons - o Serial Console - o Configurations - -STATUS -====== - - o 2017-06-10: I have no hardware in hand and I am not sure that I will - even pursue this port. This README is really no more than a thought - experiment at the present time. - - A few days ago, I did add support for the STM32L4x5 MCU family to - NuttX. But no work has yet been done for this board port other - than writing this README file. - - o 2017-06-13: I just learned that development boards will not be - available for another month. - -Board Features -============== - - B-L475E-IOT01A Discovery kit key features and specifications: - - o MCU: STM32L475 Series MCU based on ARM Cortex-M4 core with 1 MB - Flash memory, 128 KB SRAM - o Storage: 64 Mbit (8MB)  Quad-SPI Flash memory (Macronix) - o Connectivity: - - Bluetooth 4.1 LE module (SPBTLE-RF) - - Sub-GHz (868 or 915 MHz) low-power-programmable RF module (SPSGRF-868 - or SPSGRF-915) - - Wi-Fi module based on Inventek ISM43362-M3G-L44 (802.11 b/g/n - compliant) - - Dynamic NFC tag based on M24SR with its printed NFC antenna - o Sensors: - - 2x digital omni-directional microphones (MP34DT01) - - Capacitive digital sensor for relative humidity and temperature - (HTS221) - - 3-axis magnetometer (LIS3MDL) - - 3D accelerometer and 3D gyroscope (LSM6DSL) - - 260-1260 hPa absolute digital output barometer (LPS22HB) - - Time-of-Flight and gesture-detection sensor (VL53L0X - o USB – 1x micro USB OTG port (Full speed) - o Expansion – Arduino UNO V3 headers, PMOD header - o Debugging – On-board ST-LINK/V2-1 debugger/programmer with USB - re-enumeration capability: mass storage, virtual COM port and debug - port - o Misc – 2 push-buttons (user and reset) - o Power Supply – 5V via ST LINK USB VBUS or external sources - - The board supports ARM mbed online compiler, but can also be programmed - using IDEs such as IAR, Keil, and GCC-based IDEs. STMicro also provides - HAL libraries and code samples as part of the STM32Cube Package, as well - as X-CUBE-AWS expansion software to connect to the Amazon Web Services - (AWS) IoT platform. - - NOTES: - - 1. The board usese Wi-Fi® module Inventek ISM43362-M3G-L44 (802.11 b/g/n - compliant), which consists of BCM43362 and STM32F205 host processor - that has a standard SPI or UART interface capability. It means you - will only use AT command to talk with Wi-Fi® module by SPI. All the - tcp/ip stack is built-in STM32F205 in Wi-Fi® module. - - This cannot integrate cleanly with the NuttX network stack. A - USERSOCK option was recently added that would permit implementation - of the Inventek support in an applications. But that would then - preclude the 6LoWPAN integration into IPv6. - - 2. The board uses Bluetooth® V4.1 module (SPBTLE-RF), which has built-in - BLE stack. Similar with wifi, you only use simple AT command to talk - with this BLE module. - - 3. STMicro provides contiki 6lowpan for mesh. - http://www.st.com/en/embedded-software/osxcontiki6lp.html but mesh - network is not popular in the market, star network is the mainstream - for its simplicity and robustness. - -LEDs and Buttons -================ - - The black button B1 located on top side is the reset of the STM32L475VGT6. - - The blue button B1 located top side is available to be used as a digital - input or as alternate function Wake-up. When the button is depressed the logic state is "0", otherwise the logic state is "1". - - Two green LEDs (LD1 and LD2), located on the top side are available for the user. To light a LED a high logic state "1" should be written in the corresponding GPIO. - - Reference Color Name Comment - B2 blue Wake-up Alternate function Wake-up - LD1 green LED1 PA5 (alternate with ARD.D13) - LD2 green LED2 PB14 - - These LEDs are not used by the board port unless CONFIG_ARCH_LEDS is - selected. In that case, the usage by the board port is defined in - include/board.h and src/lpc31_leds.c. The LEDs are used to encode - OS-related events as follows: - - SYMBOL Meaning LED state - LED2 LED1 - ------------------- ----------------------- -------- -------- - 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 N/C - 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 N/C Blinking - LED_IDLE MCU is is sleep mode Not used - - Thus if LED2 is statically on, NuttX has successfully booted and is, - apparently, running normmally. If LED1 is flashing at approximately - 2Hz, then a fatal error has been detected and the system has halted. - - NOTE: That LED2 is not used after completion of booting and may - be used by other board-specific logic. - - Of course, if CONFIG_ARCH_LEDS is not selected, then both LEDs are - available for use by other logic. - -Serial Console -============== - - Arduino Serial Shield - --------------------- - An TLL-to-RS232 Converter shield may be used with UART4: - - UART4: - -------------- ---------------- ------------------ - STM32L475VGTx Board Signal Arduino Connector - -------------- ---------------- ------------------ - UART4_RX PA1 ARD.D0-UART4_RX CN3 pin1 RX/D0 - UART4_TX PA0 ARD.D1-UART4_TX CN3 pin2 TX/D1 - -------------- ---------------- ------------------ - - Virtual COM Port - ---------------- - The serial interface USART1 is directly available as a virtual COM port - of the PC connected to the ST-LINK/V2-1 USB connector CN7. - - USART1: - -------------- ---------------- -------------- - STM32L475VGTx Board Signal STM32F103CBT6 - -------------- ---------------- -------------- - USART1_TX PB6 ST-LINK-UART1_TX USART2_RX PA3 - UAART1_RX PB7 ST-LINK-UART1_RX USART2_TX PA2 - -------------- ---------------- -------------- - - The virtual COM port settings are configured as: 115200 b/s, 8 bits data, - no parity, 1 stop bit, no flow control. - - Other Options - ------------- - - USART2 - Available on CN10 if solder bridges closed. - -------------- ---------------- --------------------------- - STM32L475VGTx Board Signal PMOD / Solder Bridges - -------------- ---------------- --------------------------- - USART2_RX PD4 PMOD-UART2_RX CN10 pin1 or 2 (SB12, SB14) - USART2_TX PD5 PMOD-UART2_TX CN10 pin2 TX/D1 (SB20) - -------------- ---------------- --------------------------- - - USART3 - Dedicated to ISM43362-M3G-L44 Serial-to-Wifi Module. - -------------- ---------------- ------------------ - STM32L475VGTx Board Signal Arduino Connector - -------------- ---------------- ------------------ - USART3_RX PD9 INTERNAL-UART3_RX CN3 pin1 RX/D0 - USART3_TX PD8 INTERNAL-UART3_TX CN3 pin2 TX/D1 - -------------- ---------------- ------------------ - -Configurations -============== - - Information Common to All Configurations - ---------------------------------------- - Each B-L475E-IOT01A configuration is maintained in a sub-directory and - can be selected as follow: - - tools/configure.sh [-l|c|n] /b-l475e-iot01a: - - Where: - -l selects the Linux (l) host environment. The [-c|u|n] options - select one of the Windows environments. Default: Use host setup - in the defconfig file - [-c|n] selects the Windows host and a Windows environment: - Cygwin (c), or Windows native (n). Default Cygwin - - Before building, make sure that: - - 1. The PATH environment variable include the correct path to the - directory than holds your toolchain binaries. - 2. Check the .config file. Make sure that the configuration is set for - your build platform (e.g., Linux vs. Windows) and that the toolchain - is set for the toolchain type you are using. - - The that is provided above as an argument to the - tools/configure.sh must be is one of those listed below. - - 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 - - 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 USART1 (i.e., for ST-Link Virtual COM port). The - relevant configuration settings are listed below: - - CONFIG_STM32_USART1=y - CONFIG_STM32_USART1_SERIALDRIVER=y - CONFIG_STM32_USART=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 - - 3. All of these configurations are set up to build under Windows 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: - - Build Setup: - CONFIG_HOST_WINDOWS=y : Window environment - CONFIG_WINDOWS_CYGWIN=y : Cywin under Windows - - System Type -> Toolchain: - CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : GNU ARM EABI toolchain - -Configuration sub-directories ------------------------------ - - nsh: - - Configures the NuttShell (nsh) located at examples/nsh. This - configuration is focused on low level, command-line driver testing. - - spirit-6lowpan - - This is another version of nsh that is similar to the above 'nsh' - configuration but is focused on testing the Spirit1 integration with - the 6LoWPAN network stack. It supports point-to-point, 6LoWPAN - communications between two b-l47e-iot01a boards. Additional differences - from the 'nsh" configuration are summarized below: - - NOTES: - - 1. You must must have two b-l475e-iot01a boards. - - 2. IPv6 networking is enabled with TCP/IP, UDP, 6LoWPAN, and NSH - Telnet support. - - 3. Configuration instructions: NSH does not configuration or - bring up the network. Currently that must be done manually. - The configurations steps are: - - a) Assign a unique 8-bit node address to the Spirit1 board in the - WPAN: - - nsh> ifconfig wpan0 hw 37 - - Where 37 the address is an example. It should be different for - each radio, but in the the range 1..ed and ef..fe (ee and ff are - the reserved for multicast and broadcast addresses, respectively. - Zero is a valid address but not recommended). - - b) Bring each the network up on each board in the WPAN: - - nsh> ifup wpan0 - - You can entry nsh> ifconfig to see if the node address and - derived IPv4 are set correctly (the IPv6 address will not be - determined until the network is UP). - - 4. examples/udp is enabled. This will allow two Spirit1 nodes to - exchange UDP packets. Basic instructions: - - 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: - - nsh> udpclient & - - Where 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. - - 5. examples/nettest is enabled. This will allow two Spirit1 nodes to - exchange TCP packets. Basic instructions: - - 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: - - nsh> tcpclient & - - Where 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. - - 6. 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 address derives from the 8-bit node address that was assigned - when the node was configured. - - 7. 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 - - Where 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 - - STATUS: - - 2017-08-01: Testing began. The Spirit1 no configurations with no - errors, but there are no tests yet in place to exercise it. - - 2017-08-02: The nettest, udp, telnet test programs were added. - - 2017-08-03: Successfully exchanging packets, but there there are - issues with address filtering, CRC calculation, and data integrity - (like bad UDP checksums). Lot's more to be done! - - 2017-08-04: Fixed some of the address filtering issues: In Basic - packets, need to force the Spirit to send the destination address. - This fixes address filtering. But... - - Converted to STack vs Basic packets. We need to do this because - the Basic packets do not provide the source node address. Now - correctly gets the source node address and uncompresses the source - IP address. - - In addition, to avoid packet loss due to data overrun, I enabled - the AutoAck, TX retries, the RX timeout options. - - With these changes (along with other, significant bugfixes), both - the UDP test is now fully functional. CRC filtering still must be - disabled. - - 2017-08-05: Add the Telnet client problem. Verified HC06 tests with - no debug output; verified Telnet seessions between two spirit nodes. - - At this point everything seems functional, but somewhat reliable. - Sometimes things seem to initialize in a bad state. - - 2017-08-06: Reducing the FIFO to 94 bytes fixed the problem with the - 2 byte CRC. - - Test Matrix: - The following configurations have been tested successfully (with - CRC disabled): - - TEST DATE - COMPRESSION UDP TCP Telnet - ----------- ----- ----- ------ - hc06 08/04 08/04 08/05 (CRC disabled) - hc1 --- --- --- - ipv6 --- --- --- - ----------- ----- ----- ------ - - Other configuration options have not been specifically addressed - (such non-compressable ports, non-MAC based IPv6 addresses, etc.) - - spirit-starhub and spirit-starpoint - - These two configurations implement hub and and star endpoint in a - star topology. Both configurations derive from the spirit-6lowpan - configuration and most of the notes there apply here as well. - - 1. You must must have three b-l475e-iot01a boards 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 - spirit-6lowpan in following is also set: - - CONFIG_NET_STAR=y - CONFIG_NET_STARPOINT=y - - The CONFIG_NET_STARPOINT selection informs the endpoint that it - must send all frames to the hub of the star, rather than directly - to the recipient. - - The star hub configuration, on the other hand, differs from the - spirit-6lowpan in these fundamental ways: - - CONFIG_NET_STAR=y - CONFIG_NET_STARHUB=y - CONFIG_NET_IPFORWARD=y - - The CONFIG_NET_IPFORWARD selection informs the hub that if it - receives any packets that are not destined for the hub, it should - forward those packets appropriately. - - 3. TCP and UDP Tests: The same TCP and UDP tests as described for - the spirit-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. - - Each node in the configuration must be manually initialized. - Ideally, this would be automatically initialized with software logic - and configuration data in non-volatilbe memory. The the procedure - is manual in this example. These are the basic initialization - steps with E1 and E2 representing the two star endpoints and C - representing the star hub: - - C: nsh> ifup wpan0 <-- Brings up the network on the hub - C: nsh> telnetd <-- Starts the Telnet daemon on the hub - C: nsh> ifconfig <-- To get the IP address of the hub - - E1: nsh> ifconfig wpan0 hw 37 <-- Sets E1 endpoint node address - E1: nsh> ifup wpan0 <-- Brings up the network on the E1 node - E1: nsh> telnetd <-- Starts the Telnet daemon on the E1 node - E1: nsh> ifconfig <-- To get the IP address of E1 endpoint - - E2: nsh> ifconfig wpan0 hw 38 <-- Sets E2 endpoint node address - E2: nsh> ifup wpan0 <-- Brings up the network on the E2 node - E2: nsh> telnetd <-- Starts the Telnet daemon on the E2 node - E2: nsh> ifconfig <-- To get the IP address of E2 endpoint - - It is not necessary to set the hub node address, that will automatically - be set to CONFIG_SPIRIT_HUBNODE when the hub boots. CONFIG_SPIRIT_HUBNODE - is the "well-known" address of the star hub. - - The modified usage of the TCP test is then show below: - - E1: nsh> tcpserver & - E2: nsh> tcpclient & - - Where is the IP address of the E1 endpoint. - - Similarly for the UDP test: - - E1: nsh> udpserver & - E2: nsh> udpclient & - - Telenet sessions may be initiated from the any node to any other node: - - XX: nsh> telnet <-- Runs the Telnet client on any node XX - - Where is the IP address of either the E1 or E2 endpoints - or of the star hub. - - 4. Hub UDP Test. The hub of the star does not support the same level of - test as for the endpoint-to-endpoint tests described above. The primary - role of the hub is packet forwarding. The hub does support to test - applications, however: (1) A Telnet client that will permit the hub to - establish remote NSH sesstions with any endpoint, and (2) A special - version of the udpclient program to support testing of Spirit broadcast. - - IPv6 does not support "broadcast" in the same since as IPv4. IPv6 - supports only multicast. The special multicast address, ff02::1 is - the "all-nodes address" and is functionally equivalent to broadcast. - - The spirit radios do support both multicast and broadcast with the - special addresses 0xee and 0xff, respectively. So the Spirit driver - will map the all-nodes IPv6 to the Spirit destination address 0xff and - the packet will be broadcast to all Spirit nodes. - - Here are the procedures for using the test - - C: nsh> ifup wpan0 <-- Brings up the network on the hub - - E1: nsh> ifconfig wpan0 hw 37 <-- Sets E1 endpoint node address - E1: nsh> ifup wpan0 <-- Brings up the network on the E1 node - E1: udpserver & <-- Start the UDP server - - E2: nsh> ifconfig wpan0 hw 38 <-- Sets E2 endpoint node address - E2: nsh> ifup wpan0 <-- Brings up the network on the E2 node - E2: udpserver & <-- Start the UDP server - - C: udpclient & <-- Starts the UDP client side of the test - - The client will broadcast the UDP packets and, as each UDP packet is - sent, it will be received by BOTH endpoints. - - STATUS: - 2017-08-05: Configurations added. Early testing suggests that there is - a problem when packets are received from multiple sources at high rates: - New incoming packets appear to cause RX FIFO errors and the driver does - not recover well. - - 2017-08-06: The RX FIFO errors are worse when debug is enabled. This led - me to believe that the cause of the RX FIFO errors was due to too many - interactions by the LP and HP work queue. I restructured the tasking to - reduce the amount of interlocking, but this did not eliminate the RX FIFO - errors. - - Hmmm.. this statement appears in the STMicro driver: "Sometimes Spirit1 - seems to NOT deliver (correctly) the 'IRQ_RX_DATA_READY' event for - packets which have a length which is close to a multiple of RX FIFO size. - Furthermore, in these cases also the content delivery seems to be - compromised as well as the generation of RX/TX FIFO errors. This can be - avoided by reducing the maximum packet length to a value which is lower - than the RX FIFO size." - - I tried implementing the RX FIFO almost full water mark thinking this - might be a work around... it is not. Still RX FIFO errors. From my - reading, the only known work-around is to reduce the maximum packet - size so that it is smaller than 96. I tried setting the maximum packet - length to 84 and that did NOT eliminate the RX FIFO error. - - At the end of the TCP test, the "nsh> ifconfig" command shows that - there were two TX timeouts. Perhaps this is related? I found that - the TX timeout was not being cancelled. It must be canceled on each - TX completed or TX error. This DID eliminate the RX FIFO error, but - now the test hangs and does not complete. - - Another Errata: "Using the STack packet format and no CRC field, the - reading from RX FIFO to the last received byte, is not possible. ..." - Workaround: "By configuring the packet handler with at least one byte - of CRC, the problem is solved. If the CRC is not required in the - application, configure one byte of CRC in the receiver only, to read - the payload correctly from RX FIFO." - - Reducing the FIFO to 94 bytes fixed the problem with the 2 byte CRC - but did not resolve that occasional RX FIFO error. - - 2017-08-07: The hang noted yesterday was due to logic that did not - restart the poll timer in the event that Spirit was not ready when the - time expired. Just unconditionally performing the poll fixed this. - - Then I noticed several assertions. In a busy radio environment, there - are many race conditions. Most typically, just when the driver is - setting up to perform a transmission, the hardware commits to a - reception. The symptom is that the driver times out out waiting to go - into the TX state (because it is in the RX state). The logic needed to - be beefed up to handle this routinely without asserting and without - leaving the Spirit in a bad state. - - The TCP test beats the radio very hard and it is actually heartening - that there are no failures that lead to data loss in this environment. - I would say it is functional but fragile in this usage, but probably - robust in a less busy environment. - - 2017-08-08: Added broadcast packet transfers using the hub-based - broadcast UDP client. This appears to be a problem the HC06 - compression and/or decompression. The decompression logic comes up - with the destination address of ff02::ff00:00fe:3500 (which derives - from the receiving node address of 37) instead of the all-nodes - multicast address of ff02::0001. It is then out of sync with the - IPHC headers and is unable to uncompress the rest of the packet - correctly. - - Trying again with HC1 compression, I see other isses. The first - frame is received correctly, but the following frames have an incorrect - packet length and generate RX FIFO errors. Forcing the send size to - 12 bytes of payload in apps/examples/udp (vs 96), eliminates this - problem and the broadcast works well. - - There is probably another issue related to broadcast TX setup: If - we are sending to the multicast or broadcast address, should we - not also disable ACKs, retries, and RX timeouts? What will happen - if multiple radios ACK? At a minimum it could keep the driver - unnecessarily busy. There is some prototype code to do just this - in the driver, but does not seem to work. - - 2017-08-26: There was only a single buffer for reassemblying larger - packets. This could be a problem issue for the hub configuration - which really needs the capability concurrently reassemble multiple - incoming streams. The design was extended to support multiple - reassembly buffers. - - Initial testing shows the same basic behavior as noted before: - The UDP test works and TCP test (usually) works. There are, - however, are errors in reported by the hub in the TCP test. - Occasionally the test will hang when the server echoes the data - back to the client. These errors are presumably the result of ACKs - from the receiver colliding with frames from the sender. - - Needs more investigation. - - 2017-09-08: The HC06 all nodes address decode problem mentioned on - 2017-08-08 has been corrected. The behavior in the test case has - not yet been reverified. I suspect that there made to some radio - configuration problems that are causing the RX FIFO errors and the - strange broadcast behavior. I recently got an STEVAL-IDS001V5M - sniffer that should tell me what is going on. But I have not yet - had sufficient free time to continue this testing. diff --git a/boards/arm/stm32l4/nucleo-l432kc/README.txt b/boards/arm/stm32l4/nucleo-l432kc/README.txt deleted file mode 100644 index fb40a9fc081..00000000000 --- a/boards/arm/stm32l4/nucleo-l432kc/README.txt +++ /dev/null @@ -1,469 +0,0 @@ -README -====== - -This README discusses issues unique to NuttX configurations for the ST -Nucleo-l432kc board from ST Micro. See - - http://www.st.com/nucleo-l432kc - -NucleoL432KC: - - Microprocessor: 32-bit ARM Cortex M4 at 80MHz STM32L432KCU6 - Memory: 256 KB Flash and 64 KB SRAM - ADC: 1×12-bit, 5 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 five 16-bit, one 32-bit, two low-power - 16 bit timers, two watchdog timers, and a SysTick timer - GPIO: Up to 26 I/O ports with interrupt capability, most 5v tolerant - I2C: Up to 2 × I2C interfaces - USARTs: Up to 3 USARTs, 2 UARTs, 1 LPUART - SPIs: Up to 2 SPIs - SAIs: 1 dual-channel audio interface - CAN interface - QSPI interface - USB: USB 2.0 full-speed device/host/OTG controller with on-chip PHY - CRC calculation unit - RTC - -Board features: - - Peripherals: 1 led - Debug: Serial wire debug and JTAG interfaces via on-board micro-usb stlink v2.1 - Expansion I/F Arduino Nano 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-L432KC for more - information about these boards. - -Contents -======== - - - Nucleo-32 Boards - - Development Environment - - GNU Toolchain Options - - IDEs - - NuttX EABI "buildroot" Toolchain - - NXFLAT Toolchain - - Hardware - - Button - - LED - - USARTs and Serial Consoles - - QFN32 - - mbed - - SPI Flash support - - Configurations - -Nucleo-32 Boards -================ - -The Nucleo-L432KC 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-F031K6 STM32F031K6T6 - NUCLEO-F042K6 STM32F042K6T6 - NUCLEO-F303K8 STM32F303K8T6 - NUCLEO-L011K4 STM32L011K4T6 - NUCLEO-L031K6 STM32L031K6T6 - NUCLEO-L432KC STM32L432KCU6 - -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 /nuttx. - - $ tools/configure.sh nucleo-l432kc:nsh - $ make qconfig - $ V=1 make context all 2>&1 | tee mout - - 2. Download the latest buildroot package into - - 3. unpack the buildroot tarball. The resulting directory may - have versioning information on it like buildroot-x.y.z. If so, - rename /buildroot-x.y.z to /buildroot. - - 4. cd /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 /nuttx. - - tools/configure.sh lpcxpresso-lpc1768: - - 2. Download the latest buildroot package into - - 3. unpack the buildroot tarball. The resulting directory may - have versioning information on it like buildroot-x.y.z. If so, - rename /buildroot-x.y.z to /buildroot. - - 4. cd /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-L432KC includes boot loader from mbed: - - https://mbed.org/handbook/Homepage - - Using the mbed loader: - - 1. Connect the Nucleo-L432kc 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-L432kc. The NUCLEO window will - close then re-open and the Nucleo-L432KC will be running the new code. - -Hardware -======== - - LEDs - ---- - The Nucleo L432KC provides a single user LED, LD3. LD3 - is the green LED connected to Arduino signal D13 corresponding to MCU I/O - PB3 (pin 26). - - - 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 LED is available: - - SYMBOL Meaning LD3 - ------------------- ----------------------- ----------- - 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 LD3, NuttX has successfully booted and is, apparently, running - normally. If LD3 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 STM32L432KC - ----------- ------------ - 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 STM32L432KC - ----------- ------------ - 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 - - 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. - -SPI Flash support: -===================== - - We can use an external SPI Serial Flash with nucleo-l432kc board. In this - case we tested with AT45DB081D (8Mbit = 1MiB). - - You can connect the AT45DB081D memory in the nucleo-l432kc board this way: - - -------------------------------- - | Memory nucleo-l432kc | - |------------------------------| - | SI ---> D11 (PB5) | - | SCK ---> D13 (PB3) | - | /RESET ---> 3V3 | - | /CS ---> D10 (PA11) | - | /WP ---> 3V3 | - | VCC ---> 3V3 | - | GND ---> GND | - | SO ---> D12 (PB4) | - -------------------------------- - - You can start with default "nucleo-l432kc/nsh" configuration option and - enable/disable these options using "make menuconfig" : - - System Type ---> - STM32L4 Peripheral Support ---> - [*] SPI1 - - Device Drivers ---> - -*- Memory Technology Device (MTD) Support ---> - -*- SPI-based AT45DB flash - (1000000) AT45DB Frequency - - File Systems ---> - [*] NXFFS file system - - Then after compiling and flashing the file nuttx.bin you can test the flash - this way: - - nsh> ls /mnt - /mnt: - at45db/ - - nsh> echo "Testing" > /mnt/at45db/file.txt - - nsh> ls /mnt/at45db - /mnt/at45db: - file.txt - - nsh> cat /mnt/at45db/file.txt - Testing - - nsh> - -Configurations -============== - - nsh: - --------- - Configures the NuttShell (nsh) located at apps/examples/nsh for the - Nucleo-L432KC 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 STM32L432KC - ----------- ------------ - 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 - - spwm - ---- - - Configures the sinusoidal PWM (SPWM) example which presents a simple use case - of the STM32L4 PWM lower-half driver without generic upper-half PWM logic. - - It uses TIM1 to generate PWM and TIM6 to change waveform samples - - At the moment, the waveform parameters are hardcoded, but it should be easy to - modify this example and make it more functional. diff --git a/boards/arm/stm32l4/nucleo-l452re/README.txt b/boards/arm/stm32l4/nucleo-l452re/README.txt deleted file mode 100644 index f7519b6e28a..00000000000 --- a/boards/arm/stm32l4/nucleo-l452re/README.txt +++ /dev/null @@ -1,268 +0,0 @@ -Nucleo-L452RE README -==================== - - This README file discusses the port of NuttX to the STMicro Nucleo-L452RE - board. That board features the STM32L452RET6 MCU with 512KiB of FLASH - and 160KiB of SRAM. - -Contents -======== - - - Status - - Nucleo-64 Boards - - LEDs - - Buttons - - Serial Console - - Configurations - -Status -====== - 2017-05-04: The board now boots and the basic NSH configurations works - without problem. - -Nucleo-64 Boards -================ - - The Nucleo-L452RE 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 including: - - 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 - -LEDs -==== - - The Nucleo-64 board has one user controllable LED, User LD2. This green - LED is a user LED connected to Arduino signal D13 corresponding to STM32 - I/O PA5 (PB13 on other some other Nucleo-64 boards). - - - 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/stm32_autoleds.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. - -Buttons -======= - - B1 USER: the user button is connected to the I/O PC13 (pin 2) of the STM32 - microcontroller. - -Serial Console -============== - - USART1 - ------ - Pins and Connectors: - - RXD: PA10 D3 CN9 pin 3, CN10 pin 33 - PB7 CN7 pin 21 - TXD: PA9 D8 CN5 pin 1, CN10 pin 21 - PB6 D10 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 STM32F072RB - ----------- ------------ - Pin 21 PA9 USART1_TX *Warning you make need to reverse RX/TX on - Pin 33 PA10 USART1_RX 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 To be provided - PA15 - PD6 - TXD: PA2 - PA14 - PD5 - - See "Virtual COM Port" and "RS-232 Shield" below. - - USART3 - ------ - Pins and Connectors: - - RXD: PB11 To be provided - PC5 - PC11 - D9 - TXD: PB10 - PC4 - PC10 - D8 - - USART3 - ------ - Pins and Connectors: - - RXD: PA1 To be provided - PC11 - TXD: PA0 - PC10 - - 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. - - 115200 8N1 BAUD should be configure to interface with the Virtual COM - port. - - Default - ------- - As shipped, SB62 and SB63 are open and SB13 and SB14 closed, so the - virtual COM port is enabled. - - RS-232 Shield - ------------- - Supports a single RS-232 connected via - - Nucleo STM32F4x1RE Shield - --------- --------------- -------- - CN9 Pin 1 PA3 USART2_RXD RXD - CN9 Pin 2 PA2 USART2_TXD TXD - - Support for this shield is enabled by selecting USART2 and configuring - SB13, 14, 62, and 63 as described above under "Virtual COM Port" - -Configurations -============== - - Information Common to All Configurations - ---------------------------------------- - Each configuration is maintained in a sub-directory and can be - selected as follow: - - tools/configure.sh nucleo-l452re: - - 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 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 USART2, as described above under "Serial Console". The - elevant configuration settings are listed below: - - CONFIG_STM32_USART2=y - CONFIG_STM32_USART2_SERIALDRIVER=y - CONFIG_STM32_USART=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 - - 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: - - Build Setup: - CONFIG_HOST_LINUX=y : Linux environment - - System Type -> Toolchain: - CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : GNU ARM EABI toolchain - - Configuration sub-directories - ----------------------------- - - nsh: - - Configures the NuttShell (nsh) located at examples/nsh. This - configuration is focused on low level, command-line driver testing. diff --git a/boards/arm/stm32l4/nucleo-l476rg/README.txt b/boards/arm/stm32l4/nucleo-l476rg/README.txt deleted file mode 100644 index e6c9e11f40f..00000000000 --- a/boards/arm/stm32l4/nucleo-l476rg/README.txt +++ /dev/null @@ -1,585 +0,0 @@ -README -====== - -This README discusses issues unique to NuttX configurations for the ST -NucleoL476RG board from ST Micro. See - - http://www.st.com/nucleo-l476rg - -NucleoL476RG: - - Microprocessor: 32-bit ARM Cortex M4 at 80MHz STM32L476RGT6 - Memory: 1024 KB Flash and 96+32 KB SRAM - ADC: 2×12-bit, 2.4 MSPS A/D converter: up to 24 channels - DMA: 16-stream DMA controllers with FIFOs and burst support - Timers: Up to 11 timers: up to eight 16-bit, two 32-bit timers, two - watchdog timers, and a SysTick timer - GPIO: Up to 51 I/O ports with interrupt capability - I2C: Up to 3 × I2C interfaces - USARTs: Up to 3 USARTs, 2 UARTs, 1 LPUART - SPIs: Up to 3 SPIs - SAIs: Up to 2 dual-channel audio interfaces - CAN interface - SDIO interface - QSPI interface - USB: USB 2.0 full-speed device/host/OTG controller with on-chip PHY - CRC calculation unit - RTC - -Board features: - - 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-L476RG 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 - - Other External Hardware/Devices - - Configurations - -Nucleo-64 Boards -================ - -The Nucleo-L476RG 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 /nuttx. - - $ tools/configure.sh nucleo-l476rg:nsh - $ make qconfig - $ V=1 make context all 2>&1 | tee mout - - 2. Download the latest buildroot package into - - 3. unpack the buildroot tarball. The resulting directory may - have versioning information on it like buildroot-x.y.z. If so, - rename /buildroot-x.y.z to /buildroot. - - 4. cd /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 /nuttx. - - tools/configure.sh lpcxpresso-lpc1768: - - 2. Download the latest buildroot package into - - 3. unpack the buildroot tarball. The resulting directory may - have versioning information on it like buildroot-x.y.z. If so, - rename /buildroot-x.y.z to /buildroot. - - 4. cd /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-L476RG includes boot loader from mbed: - - https://mbed.org/platforms/ST-Nucleo-L476RG/ - 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-L476RG/ - - Buttons - ------- - B1 USER: the user button is connected to the I/O PC13 (pin 2) of the STM32 - microcontroller. - - LEDs - ---- - The Nucleo L476RG 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_L476RG_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_L476RG_AJOY_MINBUTTONS to eliminate the - conflict. - - Current showstopper: I appear to be getting infinite interrupts as - soon as joystick button interrupts are enabled. - -Other External Hardware/Devices -=============================== - - Using external SPI SDCard - ------------------------- - It is possible to use external SDCard over SPI with the - nucleo-stm32l476rg Cortex-M4. This option will or can broaden the - functionality in your project, solution or application. - - In this NuttX project we attach an MH-SD Card Module (SPI). - [http://www.geeetech.com/wiki/index.php/Arduino_SD_card_Module] - - Other solutions should also work. - - Nucleo CN10 STM32L4x6RG - ----------- ------------ - Pin 31 PB3 SLCK - Pin 27 PB4 MISO - Pin 29 PB5 MOSI - Pin 25 PB10 CS - - Nucleo CN7 STM32L4x6RG - ----------- ------------ - Pin 18 +5V 5V - Pin 22 GND GND - - On the board the pins are labeled and are corresponding with the functions - as written before. - Configuring can be done by using ./tools/configure.sh nucleo-l476rg/spimmcsd - -Configurations -============== - - nsh: - --------- - Configures the NuttShell (nsh) located at apps/examples/nsh for the - Nucleo-L476RG 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 - - nxdemo - -------- - This is an NSH configuration that enables the NX graphics demo at - apps/examples/nxdemo. It uses the PCD8544 display on SPI1. diff --git a/boards/arm/stm32l4/nucleo-l496zg/README.txt b/boards/arm/stm32l4/nucleo-l496zg/README.txt deleted file mode 100644 index f354f2fdf67..00000000000 --- a/boards/arm/stm32l4/nucleo-l496zg/README.txt +++ /dev/null @@ -1,299 +0,0 @@ -README -====== - -This README discusses issues unique to NuttX configurations for the STMicro -Nucleo-144 board for STM32L4 chips. - -Contents -======== - - - Nucleo-144 Boards - - Nucleo L496ZG - - Hardware - - Button - - LED - - U[S]ARTs and Serial Consoles - - SPI - - SDIO - MMC - - SPI Test - - Configurations - nsh - -Nucleo-144 Boards: -================= - -The Nucleo-144 is a standard board for use with several STM32 parts in the -LQFP144 package. Variants with a STM32L4 MCU include: - - STM32 Part Board Variant Name - ------------- ------------------ - STM32L496ZGT6 NUCLEO-L496ZG - STM32L496ZGT6P NUCLEO-L496ZG-P - STM32L4A6ZGT6 NUCLEO-L4A6ZG - STM32L4R5ZIT6 NUCLEO-L4R5ZI - STM32L4R5ZIT6P NUCLEO-L4R5ZI-P - - ------------- ------------------ - -This directory supports only the STM32L4 variants of Nucleo-144. For others, -see boards/arm/stm32f7/nucleo-144 configuration. - -Please read the User Manual UM2179: Getting started with STM32 Nucleo board -software development tools and take note of the Powering options for the -board (6.3 Power supply and power selection) and the Solder bridges based -hardware configuration changes that are configurable (6.11 Solder bridges). - -Also note that UM1727 is not valid for L4 Nucleo-144 boards! - -Common Board Features: ---------------------- - - Peripherals: 8 leds, 2 push button (3 LEDs, 1 button) under software - control - Debug: STLINK/V2-1 debugger/programmer Uses a STM32F103CB to - provide a ST-Link for programming, debug similar to the - OpenOcd FTDI function - USB to JTAG front-end. - - Expansion I/F: ST Zio and Extended Ardino and Morpho Headers - -Nucleo L496ZG -============= - -ST Nucleo L496ZG board from ST Micro is supported. See - -http://www.st.com/content/st_com/en/products/evaluation-tools/product-evaluation-tools/mcu-eval-tools/stm32-mcu-eval-tools/stm32-mcu-nucleo/nucleo-l496zg.html - -The Nucleo L496ZG order part number is NUCLEO-L496ZG. It is one member of -the STM32 Nucleo-144 board family. - -NUCLEO-L496ZG Features: ----------------------- - - Microprocessor: STM32L496ZGT6 Core: ARM 32-bit Cortex®-M4 CPU with FPU, - 80 MHz, MPU, and DSP instructions. - Memory: 1024 KB Flash 320KB of SRAM (including 64KB of SRAM2) - ADC: 3×12-bit: up to 24 channels - DMA: 2 X 7-stream DMA controllers with FIFOs and burst support - Timers: Up to 13 timers: (2x 16-bit lowpower), two 32-bit timers, - 2x watchdogs, SysTick - GPIO: 114 I/O ports with interrupt capability - LCD: LCD-TFT Controller, Parallel interface - I2C: 4 × I2C interfaces (SMBus/PMBus) - U[S]ARTs: 3 USARTs, 2 UARTs (27 Mbit/s, ISO7816 interface, LIN, IrDA, - modem control) - SPI/12Ss: 6/3 (simplex) (up to 50 Mbit/s), 3 with muxed simplex I2S - for audio class accuracy via internal audio PLL or external - clock - QSPI: Dual mode Quad-SPI - SAIs: 2 Serial Audio Interfaces - CAN: 2 X CAN interface - SDMMC interface - USB: USB 2.0 full-speed device/host/OTG controller with on-chip - PHY - Camera Interface: 8/14 Bit - CRC calculation unit - TRG: True random number generator - RTC - -See https://developer.mbed.org/platforms/ST-Nucleo-L496ZG for additional -information about this board. - -Hardware -======== -< Section needs updating > - - GPIO - there are 144 I/O lines on the STM32L4xxZx with various pins pined out - on the Nucleo 144. - - Keep in mind that: - 1) The I/O is 3.3 Volt not 5 Volt like on the Arduino products. - 2) The Nucleo-144 board family has 3 pages of Solder Bridges AKA Solder - Blobs (SB) that can alter the factory configuration. We will note SB - in effect but will assume the factory default settings. - - Our main concern is establishing a console and LED utilization for - debugging. - - Buttons - ------- - B1 USER: the user button is connected to the I/O PC13 (Tamper support, SB173 - ON and SB180 OFF) - - LEDs - ---- - The Board provides a 3 user LEDs, LD1-LD3 - LED1 (Green) PB_0 (SB120 ON and SB119 OFF) - LED2 (Blue) PB_7 (SB139 ON) - LED3 (Red) PB_14 (SP118 ON) - - - When the I/O is HIGH value, the LEDs are on. - - When the I/O is LOW, the LEDs are 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/stm32_autoleds.c. The LEDs are used to encode OS - related events as follows when the LEDs are available: - - SYMBOL Meaning RED GREEN BLUE - ------------------- ----------------------- --- ----- ---- - - LED_STARTED NuttX has been started OFF OFF OFF - LED_HEAPALLOCATE Heap has been allocated OFF OFF ON - LED_IRQSENABLED Interrupts enabled OFF ON OFF - LED_STACKCREATED Idle stack created OFF ON ON - LED_INIRQ In an interrupt NC NC ON (momentary) - LED_SIGNAL In a signal handler NC ON OFF (momentary) - LED_ASSERTION An assertion failed ON NC ON (momentary) - LED_PANIC The system has crashed ON OFF OFF (flashing 2Hz) - LED_IDLE MCU is is sleep mode ON OFF OFF - -OFF - means that the OS is still initializing. Initialization is very fast - so if you see this at all, it probably means that the system is - hanging up somewhere in the initialization phases. - -GREEN - This means that the OS completed initialization. - -BLUE - Whenever and interrupt or signal handler is entered, the BLUE LED is - illuminated and extinguished when the interrupt or signal handler - exits. - -VIOLET - If a recovered assertion occurs, the RED and blue LED will be - illuminated briefly while the assertion is handled. You will - probably never see this. - -Flashing RED - In the event of a fatal crash, all other LEDs will be - extinguished and RED LED will FLASH at a 2Hz rate. - - Thus if the GREEN LED is lit, NuttX has successfully booted and is, - apparently, running normally. If the RED LED is flashing at - approximately 2Hz, then a fatal error has been detected and the system has - halted. - -Serial Consoles -=============== - - USART3 - ------ - - Default board is configured to use USART3 as console. - - Pins and Connectors: - - FUNC GPIO Connector - Pin NAME - ---- --- ------- ---- - TXD: PC4 CN8-9, A4 - RXD: PC5 CN8-11, A5 - ---- --- ------- ---- - - You must use a 3.3 TTL to RS-232 converter or a USB to 3.3V TTL - - Nucleo 144 FTDI TTL-232R-3V3 - ------------- ------------------- - TXD - CN8-9 - RXD - Pin 5 (Yellow) - RXD - CN8-11 - TXD - Pin 4 (Orange) - GND - GND Pin 1 (Black) - ------------- ------------------- - - *Note you will be reverse RX/TX - - Use make menuconfig to configure USART3 as the console: - - CONFIG_STM32L4_USART3=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 - - USART2 - ------ - - USART 2 could be used as console as well. - - Virtual COM Port - ---------------- - Yet another option is to use LPUART1 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. However the LPUART peripheral has not yet - been tested for this board. - - Solder Bridges. This configuration requires: - - PG7 LPUART1 TX SB131 ON and SB195 OFF (Default) - PG8 LPUART1 RX SB130 ON and SB193 OFF (Default) - - Default - ------- - As shipped, the virtual COM port is enabled. - -SPI ---- - Since this board is so generic, having a quick way to vet the SPI - configuration seams in order. So the board provides a quick test - that can be selected vi CONFIG_NUCLEO_SPI_TEST that will initialize - the selected buses (SPI1-SPI3) and send some text on the bus at - application initialization time board_app_initialize. - -SDIO ----- - To test the SD performance one can use a SparkFun microSD Sniffer - from https://www.sparkfun.com/products/9419 or similar board - and connect it as follows: - - VCC V3.3 CN11 16 - GND GND CN11-8 - CMD PD2 CN11-4 - CLK PC12 CN11-3 - DAT0 - PC8 CN12-2 - DAT1 - PC9 CN12-1 - DAT2 PC10 CN11-1 - CD PC11 CN11-2 - -Configurations -============== - -nsh: ----- - Configures the NuttShell (nsh) located at apps/examples/nsh for the - Nucleo-144 boards. The Configuration enables the serial interfaces - on USART6. 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. If this is the initial configuration then execute - - ./tools/configure.sh nucleo-l496zg:nsh - - in nuttx/ in order to start configuration process. - Caution: Doing this step more than once will overwrite .config with - the contents of the nucleo-l496zg/nsh/defconfig file. - - c. Execute 'make oldconfig' in nuttx/ in order to refresh the - configuration. - - d. Execute 'make menuconfig' in nuttx/ in order to start the - reconfiguration process. - - e. Save the .config file to reuse it in the future starting at step d. - - 2. By default, this configuration uses the ARM GNU toolchain - for Linux. That can easily be reconfigured, of course. - - CONFIG_HOST_LINUX=y : Builds under Linux - CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : ARM GNU for Linux - - 3. Although the default console is LPUART1 (which would correspond to - the Virtual COM port) I have done all testing with the console - device configured for USART3 (see instruction above under "Serial - Consoles). diff --git a/boards/arm/stm32l4/stm32l476vg-disco/README.txt b/boards/arm/stm32l4/stm32l476vg-disco/README.txt deleted file mode 100644 index d10bb5d2ed8..00000000000 --- a/boards/arm/stm32l4/stm32l476vg-disco/README.txt +++ /dev/null @@ -1,513 +0,0 @@ -XXX all this needs review and update -README -====== - -This README discusses issues unique to NuttX configurations for the ST -STM32L476VG Discovery board from ST Micro. See - - http://www.st.com/stm32l476g-disco - -STM32L476VG: - - Microprocessor: 32-bit ARM Cortex M4 at 80MHz STM32L476VGT6 - Memory: 1024 KB Flash and 96+32 KB SRAM - ADC: 3x12-bit, 2.4 MSPS A/D converter: up to 24 channels - DMA: 16-stream DMA controllers with FIFOs and burst support - Timers: Up to 11 timers: up to eight 16-bit, two 32-bit timers, two - watchdog timers, and a SysTick timer - GPIO: Up to 51 I/O ports with interrupt capability - I2C: Up to 3 x I2C interfaces - USARTs: Up to 3 USARTs, 2 UARTs, 1 LPUART - SPIs: Up to 3 SPIs - SAIs: Up to 2 dual-channel audio interfaces - CAN interface - SDIO interface - QSPI interface - USB: USB 2.0 full-speed device/host/OTG controller with on-chip PHY - CRC calculation unit - RTC - -Board features: - - Peripherals: 2 led, 1 d-pad joystick, 2 x LED, LCD, USC OTG FS, SAI stereo - Digital Microphone, MEMS Accelerometer, Magnetometer, - Gyroscope, 128 Mbit QSPI Flash, current ammeter - Debug: Serial wire debug and JTAG interfaces - - 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-L476RG for more - information about these boards. - -Contents -======== - - - mbed - - Hardware - - Button - - LED - - USARTs and Serial Consoles - - LQFP64 - - mbed - - Shields - - Configurations - -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 -============== - - knsh: - ---- - - This is identical to the nsh configuration below except that (1) NuttX - is built as a PROTECTED mode, monolithic module and the user applications - are built separately and, as a consequence, (2) some features that are - only available in the FLAT build are disabled. - - 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) - - 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 except files in .hex, .mot, .srec, 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. - - 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 Generic 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 : Generic 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. - - 4. This example has been used to verify the OTGFS functionality. USB is - not enabled in the default configuration but can be enabled with the - following settings: - - CONFIG_STM32L4_OTGFS=y - - CONFIG_USBDEV=y - CONFIG_USBDEV_SELFPOWERED=y - - These will enable the USB CDC/ACM serial device - - CONFIG_CDCACM=y - CONFIG_CDCACM_EP0MAXPACKET=64 - CONFIG_CDCACM_EPINTIN=1 - CONFIG_CDCACM_EPINTIN_FSSIZE=64 - CONFIG_CDCACM_EPINTIN_HSSIZE=64 - CONFIG_CDCACM_EPBULKOUT=3 - CONFIG_CDCACM_EPBULKOUT_FSSIZE=64 - CONFIG_CDCACM_EPBULKOUT_HSSIZE=512 - CONFIG_CDCACM_EPBULKIN=2 - CONFIG_CDCACM_EPBULKIN_FSSIZE=64 - CONFIG_CDCACM_EPBULKIN_HSSIZE=512 - CONFIG_CDCACM_NRDREQS=4 - CONFIG_CDCACM_NWRREQS=4 - CONFIG_CDCACM_BULKIN_REQLEN=96 - CONFIG_CDCACM_RXBUFSIZE=257 - CONFIG_CDCACM_TXBUFSIZE=193 - CONFIG_CDCACM_VENDORID=0x0525 - CONFIG_CDCACM_PRODUCTID=0xa4a7 - CONFIG_CDCACM_VENDORSTR="NuttX" - CONFIG_CDCACM_PRODUCTSTR="CDC/ACM Serial" - - CONFIG_SERIAL_REMOVABLE=y - - These will enable the USB serial example at apps/examples/usbserial - - CONFIG_BOARDCTL_USBDEVCTRL=y - - CONFIG_EXAMPLES_USBSERIAL=y - CONFIG_EXAMPLES_USBSERIAL_BUFSIZE=512 - CONFIG_EXAMPLES_USBSERIAL_TRACEINIT=y - CONFIG_EXAMPLES_USBSERIAL_TRACECLASS=y - CONFIG_EXAMPLES_USBSERIAL_TRACETRANSFERS=y - CONFIG_EXAMPLES_USBSERIAL_TRACECONTROLLER=y - CONFIG_EXAMPLES_USBSERIAL_TRACEINTERRUPTS=y - - Optional USB debug features: - - CONFIG_DEBUG_FEATURES=y - CONFIG_DEBUG_USB=y - CONFIG_ARCH_USBDUMP=y - CONFIG_USBDEV_TRACE=y - CONFIG_USBDEV_TRACE_NRECORDS=128 - CONFIG_USBDEV_TRACE_STRINGS=y - CONFIG_USBDEV_TRACE_INITIALIDSET=y - - CONFIG_NSH_USBDEV_TRACE=y - CONFIG_NSH_USBDEV_TRACEINIT=y - CONFIG_NSH_USBDEV_TRACECLASS=y - CONFIG_NSH_USBDEV_TRACETRANSFERS=y - CONFIG_NSH_USBDEV_TRACECONTROLLER=y - CONFIG_NSH_USBDEV_TRACEINTERRUPTS=y diff --git a/boards/arm/stm32l4/stm32l4r9ai-disco/README.txt b/boards/arm/stm32l4/stm32l4r9ai-disco/README.txt deleted file mode 100644 index 51363c62185..00000000000 --- a/boards/arm/stm32l4/stm32l4r9ai-disco/README.txt +++ /dev/null @@ -1,414 +0,0 @@ -README -====== - -This README discusses issues unique to NuttX configurations for the ST -STM32L4R9AI Discovery board from ST Micro. See - - https://www.st.com/content/st_com/en/products/evaluation-tools/product-evaluation-tools/mcu-eval-tools/stm32-mcu-eval-tools/stm32-mcu-discovery-kits/32l4r9idiscovery.html - -STM32L4R9AI: - - Microprocessor: 32-bit ARM Cortex M4 at 120MHz STM32L4R9AI - Memory: 2048 KB Flash and 192+64+384 KB SRAM - ADC: 1x12-bit, 5 MSPS A/D converter: up to 14 external channels - DAC: 2 channels - DFSDM: 4 filters, 8 channels - DMA: 16-stream DMA controllers with FIFOs and burst support - Timers: Up to 11 timers: up to eight 16-bit, two 32-bit timers, two - watchdog timers, and a SysTick timer - GPIO: Up to 131 I/O ports with interrupt capability - I2C: Up to 4 x I2C interfaces - USARTs: Up to 3 USARTs, 2 UARTs, 1 LPUART - SPIs: Up to 3 SPIs - SAIs: Up to 2 dual-channel audio interfaces - CAN interface - SDIO interface - OCTOSPI interface - Camera interface - USB: USB 2.0 full-speed device/host/OTG controller with on-chip PHY - CRC calculation unit - RTC - -Board features: - - Peripherals: 1 d-pad joystick, 2 x LED, AMOLED display, USC OTG FS, - 2 x MEMS Digital Microphones, SAI codec, 16 Mbit PSRAM, - 512 Mbit OCTOSPI Flash, current ammeter - Debug: Serial wire debug and JTAG interfaces - - Uses a STM32F103 to provide a ST-Link for programming, debug similar to the - OpenOcd FTDI function - USB to JTAG front-end. - -Contents -======== - - - mbed - - Hardware - - Button - - LED - - U[S]ARTs and Serial Consoles - - Segger J-Link - - LQFP64 - - Configurations - -mbed -==== - - The STM32L4R9AI-DISCO includes boot loader from mbed: - - https://mbed.org/handbook/Homepage - - Using the mbed loader: - - 1. Connect the board to the host PC using the USB connector. - 2. A new file system will appear called DIS_L4R9AI; 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 board. The DIS_L49RAIO window will - close then re-open and the board will be running the new code. - -Hardware -======== - - Buttons - ------- - B1 USER: the user button is connected to the I/O PC13 (pin 2) of the STM32 - microcontroller. - - LEDs - ---- - The STM32L4R9AI-DISCO board provides two user LEDs, LD1 (orange) and LD2 (green). - PB0 is LD1 (orange) - PH4 is LD2 (green) - - 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/stm32_autoleds.c. The LEDs are used to encode OS-related - events as follows when the green LED (PH4) 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 is on, 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. - - U[S]ARTs and 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_STM32L4_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 - - 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_STM32L4_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 - - UART4 - ------ - Pins and Connectors: - - RXD: PA1 -> CN11 D5 - TXD: PA0 -> CN17 A4 - - To configure USART4 as the console: - - CONFIG_STM32L4_UART4=y - CONFIG_USART4_SERIALDRIVER=y - CONFIG_USART4_SERIAL_CONSOLE=y - CONFIG_USART4_RXBUFSIZE=512 - CONFIG_USART4_TXBUFSIZE=256 - CONFIG_USART4_BAUD=2000000 - CONFIG_USART4_BITS=8 - CONFIG_USART4_PARITY=0 - CONFIG_USART4_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. - -Segger J-Link -============= - - Reference: https://www.segger.com/downloads/application-notes/AN00021 - - 1. Connect J-Link VTref (1) to pin VDD - 2. Connect J-Link SWDIO (7) to pin PA13 - 3. Connect J-Link SWCLK (9) to pin PA14 - 4. Connect J-Link SWO (13) to pin PB3 - 5. Connect J-Link RESET (15) to pin NRST - 6. Connect J-Link 5V-Supply (19) to pin 5V - 7. Connect J-Link GND (4) to pin GND - - Jumpers on CN4 (ST-Link) must be removed for external debug. - -Configurations -============== - - knsh: - ---- - - This is identical to the nsh configuration below except that (1) NuttX - is built as a PROTECTED mode, monolithic module and the user applications - are built separately and, as a consequence, (2) some features that are - only available in the FLAT build are disabled. - - 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) - - 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 except files in .hex, .mot, .srec, 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. - - nsh: - --- - Configures the NuttShell (nsh) located at apps/examples/nsh for the - STM32L4R9AI-DISCO board. The Configuration enables the serial interfaces - on UART4. 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: - - Execute 'make menuconfig' in nuttx/ in order to start the - reconfiguration process. - - 2. By default, this configuration uses the Generic 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 : Generic EABI toolchain for Linux - - 3. The default console is UART4 - - 4. This example can be used to verify the OTGFS functionality. USB is - not enabled in the default configuration but can be enabled with the - following settings: (TODO: need to test!) - - CONFIG_STM32L4_OTGFS=y - - CONFIG_USBDEV=y - CONFIG_USBDEV_SELFPOWERED=y - - These will enable the USB CDC/ACM serial device - - CONFIG_CDCACM=y - CONFIG_CDCACM_EP0MAXPACKET=64 - CONFIG_CDCACM_EPINTIN=1 - CONFIG_CDCACM_EPINTIN_FSSIZE=64 - CONFIG_CDCACM_EPINTIN_HSSIZE=64 - CONFIG_CDCACM_EPBULKOUT=3 - CONFIG_CDCACM_EPBULKOUT_FSSIZE=64 - CONFIG_CDCACM_EPBULKOUT_HSSIZE=512 - CONFIG_CDCACM_EPBULKIN=2 - CONFIG_CDCACM_EPBULKIN_FSSIZE=64 - CONFIG_CDCACM_EPBULKIN_HSSIZE=512 - CONFIG_CDCACM_NRDREQS=4 - CONFIG_CDCACM_NWRREQS=4 - CONFIG_CDCACM_BULKIN_REQLEN=96 - CONFIG_CDCACM_RXBUFSIZE=257 - CONFIG_CDCACM_TXBUFSIZE=193 - CONFIG_CDCACM_VENDORID=0x0525 - CONFIG_CDCACM_PRODUCTID=0xa4a7 - CONFIG_CDCACM_VENDORSTR="NuttX" - CONFIG_CDCACM_PRODUCTSTR="CDC/ACM Serial" - - CONFIG_SERIAL_REMOVABLE=y - - These will enable the USB serial example at apps/examples/usbserial - - CONFIG_BOARDCTL_USBDEVCTRL=y - - CONFIG_EXAMPLES_USBSERIAL=y - CONFIG_EXAMPLES_USBSERIAL_BUFSIZE=512 - CONFIG_EXAMPLES_USBSERIAL_TRACEINIT=y - CONFIG_EXAMPLES_USBSERIAL_TRACECLASS=y - CONFIG_EXAMPLES_USBSERIAL_TRACETRANSFERS=y - CONFIG_EXAMPLES_USBSERIAL_TRACECONTROLLER=y - CONFIG_EXAMPLES_USBSERIAL_TRACEINTERRUPTS=y - - Optional USB debug features: - - CONFIG_DEBUG_FEATURES=y - CONFIG_DEBUG_USB=y - CONFIG_ARCH_USBDUMP=y - CONFIG_USBDEV_TRACE=y - CONFIG_USBDEV_TRACE_NRECORDS=128 - CONFIG_USBDEV_TRACE_STRINGS=y - CONFIG_USBDEV_TRACE_INITIALIDSET=y - - CONFIG_NSH_USBDEV_TRACE=y - CONFIG_NSH_USBDEV_TRACEINIT=y - CONFIG_NSH_USBDEV_TRACECLASS=y - CONFIG_NSH_USBDEV_TRACETRANSFERS=y - CONFIG_NSH_USBDEV_TRACECONTROLLER=y - CONFIG_NSH_USBDEV_TRACEINTERRUPTS=y - - nxhello: - ------- - - A simple NSH example using apps/examples/nxhello, a very simply test of - basic NX functionality.