diff --git a/configs/README.txt b/configs/README.txt index 6cd5eef3f9..c8b02711a7 100644 --- a/configs/README.txt +++ b/configs/README.txt @@ -1709,6 +1709,10 @@ configs/sim This port does not support interrupts or a real timer (and hence no round robin scheduler) Otherwise, it is complete. +configs/shenzhou + This is the port of NuttX to the Shenzhou development board from + www.armjishu.com. This board features the STMicro STM32F107VCT MCU. + configs/skp16c26 Renesas M16C processor on the Renesas SKP16C26 StarterKit. This port uses the GNU m32c toolchain. STATUS: The port is complete but untested diff --git a/configs/shenzhou/README.txt b/configs/shenzhou/README.txt new file mode 100755 index 0000000000..bda76a783f --- /dev/null +++ b/configs/shenzhou/README.txt @@ -0,0 +1,1110 @@ +README +====== + +This README discusses issues unique to NuttX configurations for the Shenzhou +development board from www.armjishu.com featuring the STMicro STM32F107VCT +MCU. On-board features: + + - STM32F107VCT + - 10/100M PHY (DM9161AEP) + - TFT LCD Connector + - USB OTG + - CAN (CAN1=2) + - USART connectos (USART1-2) + - RS-485 + - SD card slot + - Audio DAC (PCM1770) + - SPI Flash (W25X16) + - (4) LEDs (LED1-4) + - 2.4G Wireless (NRF24L01 SPI module) + - 315MHz Wireless (module) + - (4) Buttons (KEY1-4, USERKEY2, USERKEY, TEMPER, WAKEUP) + - VBUS/external +4V select + - 5V/3.3V power conversion + - Extension connector + - JTAG + +Contents +======== + + - STM32F107VCT Pin Usage + - Development Environment + - GNU Toolchain Options + - IDEs + - NuttX buildroot Toolchain + - Shenzhou-specific Configuration Options + - LEDs + - Shenzhou-specific Configuration Options + - Configurations + +STM32F107VCT Pin Usage +====================== + +23 PA0 WAKEUP Connected to KEY4. Active low: Closing KEY4 pulls WAKEUP to ground. +24 PA1 MII_RX_CLK + RMII_REF_CLK +25 PA2 MII_MDIO +26 PA3 315M_VT +29 PA4 DAC_OUT1 +30 PA5 DAC_OUT2 JP10 + SPI1_SCK +31 PA6 SPI1_MISO +32 PA7 SPI1_MOSI +67 PA8 MCO +68 PA9 USB_VBUS JP3 + USART1_TX +69 PA10 USB_ID JP5 + USART1TX +70 PA11 USB_DM +71 PA12 USB_DP +72 PA13 TMS/SWDIO +76 PA14 TCK/SWCLK +77 PA15 TDI + +35 PB0 ADC_IN1 +36 PB1 ADC_IN2 +37 PB2 DATA_LE + BOOT1 JP13 +89 PB3 TDO/SWO +90 PB4 TRST +91 PB5 CAN2_RX +92 PB6 CAN2_TX JP11 + I2C1_SCL +93 PB7 I2C1_SDA +95 PB8 USB_PWR +96 PB9 F_CS +47 PB10 USERKEY +48 PB11 MII_TX_EN +51 PB12 I2S_WS + MII_TXD0 +52 PB13 I2S_CK + MII_TXD1 +53 PB14 SD_CD +54 PB15 I2S_DIN + +15 PC0 POTENTIO_METER +16 PC1 MII_MDC +17 PC2 WIRELESS_INT +18 PC3 WIRELESS_CE +33 PC4 USERKEY2 +34 PC5 TP_INT JP6 + MII_INT +63 PC6 I2S_MCK Pulled high +64 PC7 LCD_CS Pulled high +65 PC8 LCD_CS Pulled high +66 PC9 TP_CS Pulled hight +78 PC10 SPI3_SCK +79 PC11 SPI3_MISO +80 PC12 SPI3_MOSI +7 PC13 TAMPER +8 PC14 OSC32_IN Y1 32.768Khz XTAL +9 PC15 OSC32_OUT Y1 32.768Khz XTAL + +81 PD0 CAN1_RX +82 PD1 CAN1_TX +83 PD2 LED1 +84 PD3 LED2 +85 PD4 LED3 +86 PD5 485_TX + USART2_TX +87 PD6 485_RX JP4 + USART2_RX +88 PD7 LED4 + 485_DIR +55 PD8 MII_RX_DV + RMII_CRSDV +56 PD9 MII_RXD0 +57 PD10 MII_RXD1 +58 PD11 SD_CS +59 PD12 WIRELESS_CS +60 PD13 LCD_RS +61 PD14 LCD_WR +62 PD15 LCD_RD + +97 PE0 DB00 +98 PE1 DB01 +1 PE2 DB02 +2 PE3 DB03 +3 PE4 DB04 +4 PE5 DB05 +5 PE6 DB06 +38 PE7 DB07 +39 PE8 DB08 +40 PE9 DB09 +41 PE10 DB10 +42 PE11 DB11 +43 PE12 DB12 +44 PE13 DB13 +45 PE14 DB14 +46 PE15 DB15 + +73 N/C + +12 OSC_IN Y2 25Mhz XTAL +13 OSC_OUT Y2 25Mhz XTAL + +94 BOOT0 JP15 (3.3V or GND) +14 RESET S5 +6 VBAT JP14 (3.3V or battery) + +49 VSS_1 GND +74 VSS_2 GND +99 VSS_3 GND +27 VSS_4 GND +10 VSS_5 GND +19 VSSA VSSA +20 VREF- VREF- + + +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. Testing was performed using the Cygwin + environment because the development tools that I used only work under Windows. + +GNU Toolchain Options +===================== + + Toolchain Configurations + ------------------------ + The NuttX make system has been modified to support the following different + toolchain options. + + 1. The CodeSourcery GNU toolchain, + 2. The Atollic Toolchain, + 3. The devkitARM GNU toolchain, + 4. Raisonance GNU toolchain, or + 5. The NuttX buildroot Toolchain (see below). + + Most testing has been conducted using the CodeSourcery toolchain for Windows and + that is the default toolchain in most configurations. To use the Atollic, + devkitARM, Raisonance GNU, or NuttX buildroot toolchain, you simply need to + add one of the following configuration options to your .config (or defconfig) + file: + + CONFIG_STM32_CODESOURCERYW=y : CodeSourcery under Windows + CONFIG_STM32_CODESOURCERYL=y : CodeSourcery under Linux + CONFIG_STM32_ATOLLIC_LITE=y : The free, "Lite" version of Atollic toolchain under Windows + CONFIG_STM32_ATOLLIC_PRO=y : The paid, "Pro" version of Atollic toolchain under Windows + CONFIG_STM32_DEVKITARM=y : devkitARM under Windows + CONFIG_STM32_RAISONANCE=y : Raisonance RIDE7 under Windows + CONFIG_STM32_BUILDROOT=y : NuttX buildroot under Linux or Cygwin (default) + + If you change the default toolchain, then you may also have to modify the PATH in + the setenv.h file if your make cannot find the tools. + + NOTE: the CodeSourcery (for Windows), Atollic, devkitARM, and Raisonance toolchains are + Windows native toolchains. The CodeSourcery (for Linux) and NuttX buildroot + toolchains are Cygwin and/or Linux native toolchains. There are several limitations + to using a Windows based toolchain in a Cygwin environment. The three biggest are: + + 1. The Windows toolchain cannot follow Cygwin paths. Path conversions are + performed automatically in the Cygwin makefiles using the 'cygpath' utility + but you might easily find some new path problems. If so, check out 'cygpath -w' + + 2. Windows toolchains cannot follow Cygwin symbolic links. Many symbolic links + are used in Nuttx (e.g., include/arch). The make system works around these + problems for the Windows tools by copying directories instead of linking them. + But this can also cause some confusion for you: For example, you may edit + a file in a "linked" directory and find that your changes had no effect. + That is because you are building the copy of the file in the "fake" symbolic + directory. If you use a Windows toolchain, you should get in the habit of + making like this: + + make clean_context all + + An alias in your .bashrc file might make that less painful. + + 3. Dependencies are not made when using Windows versions of the GCC. This is + because the dependencies are generated using Windows pathes which do not + work with the Cygwin make. + + Support has been added for making dependencies with the windows-native toolchains. + That support can be enabled by modifying your Make.defs file as follows: + + - MKDEP = $(TOPDIR)/tools/mknulldeps.sh + + MKDEP = $(TOPDIR)/tools/mkdeps.sh --winpaths "$(TOPDIR)" + + If you have problems with the dependency build (for example, if you are not + building on C:), then you may need to modify tools/mkdeps.sh + + The CodeSourcery Toolchain (2009q1) + ----------------------------------- + The CodeSourcery toolchain (2009q1) does not work with default optimization + level of -Os (See Make.defs). It will work with -O0, -O1, or -O2, but not with + -Os. + + The Atollic "Pro" and "Lite" Toolchain + -------------------------------------- + One problem that I had with the Atollic toolchains is that the provide a gcc.exe + and g++.exe in the same bin/ file as their ARM binaries. If the Atollic bin/ path + appears in your PATH variable before /usr/bin, then you will get the wrong gcc + when you try to build host executables. This will cause to strange, uninterpretable + errors build some host binaries in tools/ when you first make. + + The Atollic "Lite" Toolchain + ---------------------------- + The free, "Lite" version of the Atollic toolchain does not support C++ nor + does it support ar, nm, objdump, or objdcopy. If you use the Atollic "Lite" + toolchain, you will have to set: + + CONFIG_HAVE_CXX=n + + In order to compile successfully. Otherwise, you will get errors like: + + "C++ Compiler only available in TrueSTUDIO Professional" + + The make may then fail in some of the post link processing because of some of + the other missing tools. The Make.defs file replaces the ar and nm with + the default system x86 tool versions and these seem to work okay. Disable all + of the following to avoid using objcopy: + + CONFIG_RRLOAD_BINARY=n + CONFIG_INTELHEX_BINARY=n + CONFIG_MOTOROLA_SREC=n + CONFIG_RAW_BINARY=n + + devkitARM + --------- + The devkitARM toolchain includes a version of MSYS make. Make sure that the + the paths to Cygwin's /bin and /usr/bin directories appear BEFORE the devkitARM + path or will get the wrong version of make. + +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). + + 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 pathes: 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 buildroot Toolchain +========================= + + A GNU GCC-based toolchain is assumed. The files */setenv.sh 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 + SourceForge download site (https://sourceforge.net/project/showfiles.php?group_id=189573). + This GNU toolchain builds and executes in the Linux or Cygwin environment. + + 1. You must have already configured Nuttx in /nuttx. + + cd tools + ./configure.sh shenzhou/ + + 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 configs/cortexm3-defconfig-4.3.3 .config + + 6. make oldconfig + + 7. make + + 8. Edit setenv.h, if necessary, so that the PATH variable includes + the path to the newly built binaries. + + See the file configs/README.txt in the buildroot source tree. That has more + detailed PLUS some special instructions that you will need to follow if you are + building a Cortex-M3 toolchain for Cygwin under Windows. + +LEDs +==== + +The Shenzhou board has four LEDs labeled LED1, LED2, LED3 and LED4 on the +board. These LEDs are not used by the board port unless CONFIG_ARCH_LEDS is +defined. In that case, the usage by the board port is defined in +include/board.h and src/up_leds.c. The LEDs are used to encode OS-related +events as follows: + + SYMBOL Meaning LED1* LED2 LED3 LED4**** + ------------------- ----------------------- ------- ------- ------- ------ + LED_STARTED NuttX has been started ON OFF OFF OFF + LED_HEAPALLOCATE Heap has been allocated OFF ON OFF OFF + LED_IRQSENABLED Interrupts enabled ON ON OFF OFF + LED_STACKCREATED Idle stack created OFF OFF ON OFF + LED_INIRQ In an interrupt** ON N/C N/C OFF + LED_SIGNAL In a signal handler*** N/C ON N/C OFF + LED_ASSERTION An assertion failed ON ON N/C OFF + LED_PANIC The system has crashed N/C N/C N/C ON + LED_IDLE STM32 is is sleep mode (Optional, not used) + + * If LED1, LED2, LED3 are statically on, then NuttX probably failed to boot + and these LEDs will give you some indication of where the failure was + ** The normal state is LED3 ON and LED1 faintly glowing. This faint glow + is because of timer interupts that result in the LED being illuminated + on a small proportion of the time. + *** LED2 may also flicker normally if signals are processed. +**** LED4 may not be available if RS-485 is also used it will then indicate + the RS-485 direction. + +Shenzhou-specific Configuration Options +============================================ + + CONFIG_ARCH - Identifies the arch/ subdirectory. This should + be set to: + + CONFIG_ARCH=arm + + CONFIG_ARCH_family - For use in C code: + + CONFIG_ARCH_ARM=y + + CONFIG_ARCH_architecture - For use in C code: + + CONFIG_ARCH_CORTEXM3=y + + CONFIG_ARCH_CHIP - Identifies the arch/*/chip subdirectory + + CONFIG_ARCH_CHIP=stm32 + + CONFIG_ARCH_CHIP_name - For use in C code to identify the exact + chip: + + CONFIG_ARCH_CHIP_STM32F107VCT=y + + CONFIG_ARCH_BOARD_STM32_CUSTOM_CLOCKCONFIG - Enables special STM32 clock + configuration features. + + CONFIG_ARCH_BOARD_STM32_CUSTOM_CLOCKCONFIG=n + + CONFIG_ARCH_BOARD - Identifies the configs subdirectory and + hence, the board that supports the particular chip or SoC. + + CONFIG_ARCH_BOARD=shenzhou (for the Shenzhou development board) + + CONFIG_ARCH_BOARD_name - For use in C code + + CONFIG_ARCH_BOARD_SHENZHOU=y + + CONFIG_ARCH_LOOPSPERMSEC - Must be calibrated for correct operation + of delay loops + + CONFIG_ENDIAN_BIG - define if big endian (default is little + endian) + + CONFIG_DRAM_SIZE - Describes the installed DRAM (SRAM in this case): + + CONFIG_DRAM_SIZE=0x00010000 (64Kb) + + CONFIG_DRAM_START - The start address of installed DRAM + + CONFIG_DRAM_START=0x20000000 + + CONFIG_STM32_CCMEXCLUDE - Exclude CCM SRAM from the HEAP + + In addition to internal SRAM, SRAM may also be available through the FSMC. + In order to use FSMC SRAM, the following additional things need to be + present in the NuttX configuration file: + + CONFIG_STM32_FSMC_SRAM - Indicates that SRAM is available via the + FSMC (as opposed to an LCD or FLASH). + + CONFIG_HEAP2_BASE - The base address of the SRAM in the FSMC address space (hex) + + CONFIG_HEAP2_END - The size of the SRAM in the FSMC address space (decimal) + + CONFIG_ARCH_IRQPRIO - The STM32107xxx supports interrupt prioritization + + CONFIG_ARCH_IRQPRIO=y + + CONFIG_ARCH_LEDS - Use LEDs to show state. Unique to boards that + have LEDs + + CONFIG_ARCH_INTERRUPTSTACK - This architecture supports an interrupt + stack. If defined, this symbol is the size of the interrupt + stack in bytes. If not defined, the user task stacks will be + used during interrupt handling. + + CONFIG_ARCH_STACKDUMP - Do stack dumps after assertions + + CONFIG_ARCH_LEDS - Use LEDs to show state. Unique to board architecture. + + CONFIG_ARCH_CALIBRATION - Enables some build in instrumentation that + cause a 100 second delay during boot-up. This 100 second delay + serves no purpose other than it allows you to calibratre + CONFIG_ARCH_LOOPSPERMSEC. You simply use a stop watch to measure + the 100 second delay then adjust CONFIG_ARCH_LOOPSPERMSEC until + the delay actually is 100 seconds. + + Individual subsystems can be enabled: + + AHB1 + ---- + CONFIG_STM32_CRC + CONFIG_STM32_BKPSRAM + CONFIG_STM32_CCMDATARAM + CONFIG_STM32_DMA1 + CONFIG_STM32_DMA2 + CONFIG_STM32_ETHMAC + CONFIG_STM32_OTGHS + + AHB2 + ---- + CONFIG_STM32_DCMI + CONFIG_STM32_CRYP + CONFIG_STM32_HASH + CONFIG_STM32_RNG + CONFIG_STM32_OTGFS + + AHB3 + ---- + CONFIG_STM32_FSMC + + APB1 + ---- + CONFIG_STM32_TIM2 + CONFIG_STM32_TIM3 + CONFIG_STM32_TIM4 + CONFIG_STM32_TIM5 + CONFIG_STM32_TIM6 + CONFIG_STM32_TIM7 + CONFIG_STM32_TIM12 + CONFIG_STM32_TIM13 + CONFIG_STM32_TIM14 + CONFIG_STM32_WWDG + CONFIG_STM32_IWDG + CONFIG_STM32_SPI2 + CONFIG_STM32_SPI3 + CONFIG_STM32_USART2 + CONFIG_STM32_USART3 + CONFIG_STM32_UART4 + CONFIG_STM32_UART5 + CONFIG_STM32_I2C1 + CONFIG_STM32_I2C2 + CONFIG_STM32_I2C3 + CONFIG_STM32_CAN1 + CONFIG_STM32_CAN2 + CONFIG_STM32_DAC1 + CONFIG_STM32_DAC2 + CONFIG_STM32_PWR -- Required for RTC + + APB2 + ---- + CONFIG_STM32_TIM1 + CONFIG_STM32_TIM8 + CONFIG_STM32_USART1 + CONFIG_STM32_USART6 + CONFIG_STM32_ADC1 + CONFIG_STM32_ADC2 + CONFIG_STM32_ADC3 + CONFIG_STM32_SDIO + CONFIG_STM32_SPI1 + CONFIG_STM32_SYSCFG + CONFIG_STM32_TIM9 + CONFIG_STM32_TIM10 + CONFIG_STM32_TIM11 + + Timer devices may be used for different purposes. One special purpose is + to generate modulated outputs for such things as motor control. If CONFIG_STM32_TIMn + is defined (as above) then the following may also be defined to indicate that + the timer is intended to be used for pulsed output modulation, ADC conversion, + or DAC conversion. Note that ADC/DAC require two definition: Not only do you have + to assign the timer (n) for used by the ADC or DAC, but then you also have to + configure which ADC or DAC (m) it is assigned to. + + CONFIG_STM32_TIMn_PWM Reserve timer n for use by PWM, n=1,..,14 + CONFIG_STM32_TIMn_ADC Reserve timer n for use by ADC, n=1,..,14 + CONFIG_STM32_TIMn_ADCm Reserve timer n to trigger ADCm, n=1,..,14, m=1,..,3 + CONFIG_STM32_TIMn_DAC Reserve timer n for use by DAC, n=1,..,14 + CONFIG_STM32_TIMn_DACm Reserve timer n to trigger DACm, n=1,..,14, m=1,..,2 + + For each timer that is enabled for PWM usage, we need the following additional + configuration settings: + + CONFIG_STM32_TIMx_CHANNEL - Specifies the timer output channel {1,..,4} + + NOTE: The STM32 timers are each capable of generating different signals on + each of the four channels with different duty cycles. That capability is + not supported by this driver: Only one output channel per timer. + + JTAG Enable settings (by default JTAG-DP and SW-DP are disabled): + + CONFIG_STM32_JTAG_FULL_ENABLE - Enables full SWJ (JTAG-DP + SW-DP) + CONFIG_STM32_JTAG_NOJNTRST_ENABLE - Enables full SWJ (JTAG-DP + SW-DP) + but without JNTRST. + CONFIG_STM32_JTAG_SW_ENABLE - Set JTAG-DP disabled and SW-DP enabled + + STM32107xxx specific device driver settings + + CONFIG_U[S]ARTn_SERIAL_CONSOLE - selects the USARTn (n=1,2,3) or UART + m (m=4,5) for the console and ttys0 (default is the USART1). + CONFIG_U[S]ARTn_RXBUFSIZE - Characters are buffered as received. + This specific the size of the receive buffer + CONFIG_U[S]ARTn_TXBUFSIZE - Characters are buffered before + being sent. This specific the size of the transmit buffer + CONFIG_U[S]ARTn_BAUD - The configure BAUD of the UART. Must be + CONFIG_U[S]ARTn_BITS - The number of bits. Must be either 7 or 8. + CONFIG_U[S]ARTn_PARTIY - 0=no parity, 1=odd parity, 2=even parity + CONFIG_U[S]ARTn_2STOP - Two stop bits + + CONFIG_STM32_SPI_INTERRUPTS - Select to enable interrupt driven SPI + support. Non-interrupt-driven, poll-waiting is recommended if the + interrupt rate would be to high in the interrupt driven case. + CONFIG_STM32_SPI_DMA - Use DMA to improve SPI transfer performance. + Cannot be used with CONFIG_STM32_SPI_INTERRUPT. + + CONFIG_SDIO_DMA - Support DMA data transfers. Requires CONFIG_STM32_SDIO + and CONFIG_STM32_DMA2. + CONFIG_SDIO_PRI - Select SDIO interrupt prority. Default: 128 + CONFIG_SDIO_DMAPRIO - Select SDIO DMA interrupt priority. + Default: Medium + CONFIG_SDIO_WIDTH_D1_ONLY - Select 1-bit transfer mode. Default: + 4-bit transfer mode. + + CONFIG_STM32_PHYADDR - The 5-bit address of the PHY on the board + CONFIG_STM32_MII - Support Ethernet MII interface + CONFIG_STM32_MII_MCO1 - Use MCO1 to clock the MII interface + CONFIG_STM32_MII_MCO2 - Use MCO2 to clock the MII interface + CONFIG_STM32_RMII - Support Ethernet RMII interface + CONFIG_STM32_AUTONEG - Use PHY autonegotion to determine speed and mode + CONFIG_STM32_ETHFD - If CONFIG_STM32_AUTONEG is not defined, then this + may be defined to select full duplex mode. Default: half-duplex + CONFIG_STM32_ETH100MBPS - If CONFIG_STM32_AUTONEG is not defined, then this + may be defined to select 100 MBps speed. Default: 10 Mbps + CONFIG_STM32_PHYSR - This must be provided if CONFIG_STM32_AUTONEG is + defined. The PHY status register address may diff from PHY to PHY. This + configuration sets the address of the PHY status register. + CONFIG_STM32_PHYSR_SPEED - This must be provided if CONFIG_STM32_AUTONEG is + defined. This provides bit mask indicating 10 or 100MBps speed. + CONFIG_STM32_PHYSR_100MBPS - This must be provided if CONFIG_STM32_AUTONEG is + defined. This provides the value of the speed bit(s) indicating 100MBps speed. + CONFIG_STM32_PHYSR_MODE - This must be provided if CONFIG_STM32_AUTONEG is + defined. This provide bit mask indicating full or half duplex modes. + CONFIG_STM32_PHYSR_FULLDUPLEX - This must be provided if CONFIG_STM32_AUTONEG is + defined. This provides the value of the mode bits indicating full duplex mode. + CONFIG_STM32_ETH_PTP - Precision Time Protocol (PTP). Not supported + but some hooks are indicated with this condition. + + Shenzhou CAN Configuration + + CONFIG_CAN - Enables CAN support (one or both of CONFIG_STM32_CAN1 or + CONFIG_STM32_CAN2 must also be defined) + CONFIG_CAN_FIFOSIZE - The size of the circular buffer of CAN messages. + Default: 8 + CONFIG_CAN_NPENDINGRTR - The size of the list of pending RTR requests. + Default: 4 + CONFIG_CAN_LOOPBACK - A CAN driver may or may not support a loopback + mode for testing. The STM32 CAN driver does support loopback mode. + CONFIG_CAN1_BAUD - CAN1 BAUD rate. Required if CONFIG_STM32_CAN1 is defined. + CONFIG_CAN2_BAUD - CAN1 BAUD rate. Required if CONFIG_STM32_CAN2 is defined. + CONFIG_CAN_TSEG1 - The number of CAN time quanta in segment 1. Default: 6 + CONFIG_CAN_TSEG2 - the number of CAN time quanta in segment 2. Default: 7 + CONFIG_CAN_REGDEBUG - If CONFIG_DEBUG is set, this will generate an + dump of all CAN registers. + + Shenzhou LCD Hardware Configuration + + The LCD driver supports the following LCDs on the STM324xG_EVAL board: + + AM-240320L8TNQW00H (LCD_ILI9320 or LCD_ILI9321) OR + AM-240320D5TOQW01H (LCD_ILI9325) + + Configuration options. + + CONFIG_LCD_LANDSCAPE - Define for 320x240 display "landscape" + support. Default is this 320x240 "landscape" orientation + For the Shenzhou board, the edge opposite from the row of buttons + is used as the top of the display in this orientation. + CONFIG_LCD_RLANDSCAPE - Define for 320x240 display "reverse + landscape" support. Default is this 320x240 "landscape" + orientation + For the Shenzhou board, the edge next to the row of buttons + is used as the top of the display in this orientation. + CONFIG_LCD_PORTRAIT - Define for 240x320 display "portrait" + orientation support. In this orientation, the STM3210E-EVAL's + LCD ribbon cable is at the bottom of the display. Default is + 320x240 "landscape" orientation. + In this orientation, the top of the display is to the left + of the buttons (if the board is held so that the buttons are at the + botton of the board). + CONFIG_LCD_RPORTRAIT - Define for 240x320 display "reverse + portrait" orientation support. In this orientation, the + STM3210E-EVAL's LCD ribbon cable is at the top of the display. + Default is 320x240 "landscape" orientation. + In this orientation, the top of the display is to the right + of the buttons (if the board is held so that the buttons are at the + botton of the board). + CONFIG_LCD_RDSHIFT - When reading 16-bit gram data, there appears + to be a shift in the returned data. This value fixes the offset. + Default 5. + + The LCD driver dynamically selects the LCD based on the reported LCD + ID value. However, code size can be reduced by suppressing support for + individual LCDs using: + + CONFIG_STM32_ILI9320_DISABLE (includes ILI9321) + CONFIG_STM32_ILI9325_DISABLE + + STM32 USB OTG FS Host Driver Support + + Pre-requisites + + CONFIG_USBHOST - Enable USB host support + CONFIG_STM32_OTGFS - Enable the STM32 USB OTG FS block + CONFIG_STM32_SYSCFG - Needed + CONFIG_SCHED_WORKQUEUE - Worker thread support is required + + Options: + + CONFIG_STM32_OTGFS_RXFIFO_SIZE - Size of the RX FIFO in 32-bit words. + Default 128 (512 bytes) + CONFIG_STM32_OTGFS_NPTXFIFO_SIZE - Size of the non-periodic Tx FIFO + in 32-bit words. Default 96 (384 bytes) + CONFIG_STM32_OTGFS_PTXFIFO_SIZE - Size of the periodic Tx FIFO in 32-bit + words. Default 96 (384 bytes) + CONFIG_STM32_OTGFS_DESCSIZE - Maximum size of a descriptor. Default: 128 + CONFIG_STM32_OTGFS_SOFINTR - Enable SOF interrupts. Why would you ever + want to do that? + CONFIG_STM32_USBHOST_REGDEBUG - Enable very low-level register access + debug. Depends on CONFIG_DEBUG. + CONFIG_STM32_USBHOST_PKTDUMP - Dump all incoming and outgoing USB + packets. Depends on CONFIG_DEBUG. + +Configurations +============== + +Each Shenzhou configuration is maintained in a sudirectory and +can be selected as follow: + + cd tools + ./configure.sh shenzhou/ + cd - + . ./setenv.sh + +Where is one of the following: + + dhcpd: + ----- + + This builds the DCHP server using the apps/examples/dhcpd application + (for execution from FLASH.) See apps/examples/README.txt for information + about the dhcpd example. The server address is 10.0.0.1 and it serves + IP addresses in the range 10.0.0.2 through 10.0.0.17 (all of which, of + course, are configurable). + + CONFIG_STM32_CODESOURCERYW=y : CodeSourcery under Windows + + nettest: + ------- + + This configuration directory may be used to verify networking performance + using the STM32's Ethernet controller. It uses apps/examples/nettest to excercise the + TCP/IP network. + + CONFIG_EXAMPLE_NETTEST_SERVER=n : Target is configured as the client + CONFIG_EXAMPLE_NETTEST_PERFORMANCE=y : Only network performance is verified. + CONFIG_EXAMPLE_NETTEST_IPADDR=(10<<24|0<<16|0<<8|2) : Target side is IP: 10.0.0.2 + CONFIG_EXAMPLE_NETTEST_DRIPADDR=(10<<24|0<<16|0<<8|1) : Host side is IP: 10.0.0.1 + CONFIG_EXAMPLE_NETTEST_CLIENTIP=(10<<24|0<<16|0<<8|1) : Server address used by which ever is client. + + nsh: + --- + Configures the NuttShell (nsh) located at apps/examples/nsh. The + Configuration enables both the serial and telnet NSH interfaces. + + CONFIG_STM32_CODESOURCERYW=y : CodeSourcery under Windows + CONFIG_NSH_DHCPC=n : DHCP is disabled + CONFIG_NSH_IPADDR=(10<<24|0<<16|0<<8|2) : Target IP address 10.0.0.2 + CONFIG_NSH_DRIPADDR=(10<<24|0<<16|0<<8|1) : Host IP address 10.0.0.1 + + NOTES: + 1. This example assumes that a network is connected. During its + initialization, it will try to negotiate the link speed. If you have + no network connected when you reset the board, there will be a long + delay (maybe 30 seconds?) before anything happens. That is the timeout + before the networking finally gives up and decides that no network is + available. + + 2. This example supports the ADC test (apps/examples/adc) but this must + be manually enabled by selecting: + + CONFIG_ADC=y : Enable the generic ADC infrastructure + CONFIG_STM32_ADC3=y : Enable ADC3 + CONFIG_STM32_TIM1=y : Enable Timer 1 + CONFIG_STM32_TIM1_ADC=y : Indicate that timer 1 will be used to trigger an ADC + CONFIG_STM32_TIM1_ADC3=y : Assign timer 1 to drive ADC3 sampling + CONFIG_STM32_ADC3_SAMPLE_FREQUENCY=100 : Select a sampling frequency + + See also apps/examples/README.txt + + General debug for analog devices (ADC/DAC): + + CONFIG_DEBUG_ANALOG + + 3. This example supports the PWM test (apps/examples/pwm) but this must + be manually enabled by selecting eeither + + CONFIG_PWM=y : Enable the generic PWM infrastructure + CONFIG_PWM_PULSECOUNT=n : Disable to support for TIM1/8 pulse counts + CONFIG_STM32_TIM4=y : Enable TIM4 + CONFIG_STM32_TIM4_PWM=y : Use TIM4 to generate PWM output + CONFIG_STM32_TIM4_CHANNEL=2 : Select output on TIM4, channel 2 + + If CONFIG_STM32_FSMC is disabled, output will appear on CN3, pin 32. + Ground is available on CN3, pin1. + + Or.. + + CONFIG_PWM=y : Enable the generic PWM infrastructure + CONFIG_PWM_PULSECOUNT=y : Enable to support for TIM1/8 pulse counts + CONFIG_STM32_TIM8=y : Enable TIM8 + CONFIG_STM32_TIM8_PWM=y : Use TIM8 to generate PWM output + CONFIG_STM32_TIM8_CHANNEL=4 : Select output on TIM8, channel 4 + + If CONFIG_STM32_FSMC is disabled, output will appear on CN3, pin 17 + Ground is available on CN23 pin1. + + See also include/board.h and apps/examples/README.txt + + Special PWM-only debug options: + + CONFIG_DEBUG_PWM + + 4. This example supports the CAN loopback test (apps/examples/can) but this + must be manually enabled by selecting: + + CONFIG_CAN=y : Enable the generic CAN infrastructure + CONFIG_CAN_EXID=y or n : Enable to support extended ID frames + CONFIG_STM32_CAN1=y : Enable CAN1 + CONFIG_CAN_LOOPBACK=y : Enable CAN loopback mode + + See also apps/examples/README.txt + + Special CAN-only debug options: + + CONFIG_DEBUG_CAN + CONFIG_CAN_REGDEBUG + + 5. This example can support an FTP client. In order to build in FTP client + support simply uncomment the following lines in the appconfig file (before + configuring) or in the apps/.config file (after configuring): + + #CONFIGURED_APPS += netutils/ftpc + #CONFIGURED_APPS += examples/ftpc + + 6. This example can support an FTP server. In order to build in FTP server + support simply uncomment the following lines in the appconfig file (before + configuring) or in the apps/.config file (after configuring): + + #CONFIGURED_APPS += netutils/ftpd + #CONFIGURED_APPS += examples/ftpd + + And enable poll() support in the NuttX configuration file: + + CONFIG_DISABLE_POLL=n + + 7. This example supports the watchdog timer test (apps/examples/watchdog) + but this must be manually enabled by selecting: + + CONFIG_WATCHDOG=y : Enables watchdog timer driver support + CONFIG_STM32_WWDG=y : Enables the WWDG timer facility, OR + CONFIG_STM32_IWDG=y : Enables the IWDG timer facility (but not both) + + The WWDG watchdog is driven off the (fast) 42MHz PCLK1 and, as result, + has a maximum timeout value of 49 milliseconds. For WWDG watchdog, you + should also add the fillowing to the configuration file: + + CONFIG_EXAMPLES_WATCHDOG_PINGDELAY=20 + CONFIG_EXAMPLES_WATCHDOG_TIMEOUT=49 + + The IWDG timer has a range of about 35 seconds and should not be an issue. + + 7. Adding LCD and graphics support: + + appconfig (apps/.config): Enable the application configurations that you + want to use. Asexamples: + + CONFIGURED_APPS += examples/nx : Pick one or more + CONFIGURED_APPS += examples/nxhello : + CONFIGURED_APPS += examples/nximage : + CONFIGURED_APPS += examples/nxlines : + + defconfig (nuttx/.config): + + CONFIG_STM32_FSMC=y : FSMC support is required for the LCD + CONFIG_NX=y : Enable graphics suppport + CONFIG_MM_REGIONS=3 : When FSMC is enabled, so is the on-board SRAM memory region + + 8. USB OTG FS Device or Host Support + + CONFIG_USBDEV - Enable USB device support, OR + CONFIG_USBHOST - Enable USB host support + CONFIG_STM32_OTGFS - Enable the STM32 USB OTG FS block + CONFIG_STM32_SYSCFG - Needed + CONFIG_SCHED_WORKQUEUE - Worker thread support is required + + 9. USB OTG FS Host Support. The following changes will enable support for + a USB host on the STM32F4Discovery, including support for a mass storage + class driver: + + CONFIG_USBDEV=n - Make sure tht USB device support is disabled + CONFIG_USBHOST=y - Enable USB host support + CONFIG_STM32_OTGFS=y - Enable the STM32 USB OTG FS block + CONFIG_STM32_SYSCFG=y - Needed for all USB OTF FS support + CONFIG_SCHED_WORKQUEUE=y - Worker thread support is required for the mass + storage class driver. + CONFIG_NSH_ARCHINIT=y - Architecture specific USB initialization + is needed for NSH + CONFIG_FS_FAT=y - Needed by the USB host mass storage class. + + With those changes, you can use NSH with a FLASH pen driver as shown + belong. Here NSH is started with nothing in the USB host slot: + + NuttShell (NSH) NuttX-x.yy + nsh> ls /dev + /dev: + console + null + ttyS0 + + After inserting the FLASH drive, the /dev/sda appears and can be + mounted like this: + + nsh> ls /dev + /dev: + console + null + sda + ttyS0 + nsh> mount -t vfat /dev/sda /mnt/stuff + nsh> ls /mnt/stuff + /mnt/stuff: + -rw-rw-rw- 16236 filea.c + + And files on the FLASH can be manipulated to standard interfaces: + + nsh> echo "This is a test" >/mnt/stuff/atest.txt + nsh> ls /mnt/stuff + /mnt/stuff: + -rw-rw-rw- 16236 filea.c + -rw-rw-rw- 16 atest.txt + nsh> cat /mnt/stuff/atest.txt + This is a test + nsh> cp /mnt/stuff/filea.c fileb.c + nsh> ls /mnt/stuff + /mnt/stuff: + -rw-rw-rw- 16236 filea.c + -rw-rw-rw- 16 atest.txt + -rw-rw-rw- 16236 fileb.c + + To prevent data loss, don't forget to un-mount the FLASH drive + before removing it: + + nsh> umount /mnt/stuff + + 11. This configuration requires that jumper JP22 be set to enable RS-232 + operation. + + nsh2: + ----- + + This is an alternative NSH configuration. One limitation of the Shenzhou + board is that you cannot have both a UART-based NSH console and SDIO support. + The nsh2 differs from the nsh configuration in the following ways: + + -CONFIG_STM32_USART3=y : USART3 is disabled + +CONFIG_STM32_USART3=n + + -CONFIG_STM32_SDIO=n : SDIO is enabled + +CONFIG_STM32_SDIO=y + + Logically, these are the only differences: This configuration has SDIO (and + the SD card) enabled and the serial console disabled. There is ONLY a + Telnet console!. + + There are some special settings to make life with only a Telnet + + CONFIG_SYSLOG=y - Enables the System Logging feature. + CONFIG_RAMLOG=y - Enable the RAM-based logging feature. + CONFIG_RAMLOG_CONSOLE=y - Use the RAM logger as the default console. + This means that any console output from non-Telnet threads will + go into the circular buffer in RAM. + CONFIG_RAMLOG_SYSLOG - This enables the RAM-based logger as the + system logger. This means that (1) in addition to the console + output from other tasks, ALL of the debug output will also to + to the circular buffer in RAM, and (2) NSH will now support a + command called 'dmesg' that can be used to dump the RAM log. + + There are a few other configuration differences as necessary to support + this different device configuration. Just the do the 'diff' if you are + curious. + + NOTES: + 1. See the notes for the nsh configuration. Most also apply to the nsh2 + configuration. Like the nsh configuration, this configuration can + be modified to support a variety of additional tests. + + 2. RS-232 is disabled, but Telnet is still available for use as a console. + Since RS-232 and SDIO use the same pins (one controlled by JP22), RS232 + and SDIO cannot be used concurrently. + + 3. This configuration requires that jumper JP22 be set to enable SDIO + operation. To enable MicroSD Card, which shares same I/Os with RS-232, + JP22 is not fitted. + + 4. In order to use SDIO without overruns, DMA must be used. The STM32 F4 + has 192Kb of SRAM in two banks: 112Kb of "system" SRAM located at + 0x2000:0000 and 64Kb of "CCM" SRAM located at 0x1000:0000. It appears + that you cannot perform DMA from CCM SRAM. The work around that I have now + is simply to omit the 64Kb of CCM SRAM from the heap so that all memory is + allocated from System SRAM. This is done by setting: + + CONFIG_MM_REGIONS=1 + + Then DMA works fine. The downside is, of course, is that we lose 64Kb + of precious SRAM. + + 5. Another SDIO/DMA issue. This one is probably a software bug. This is + the bug as stated in the TODO list: + + "If you use a large I/O buffer to access the file system, then the + MMCSD driver will perform multiple block SD transfers. With DMA + ON, this seems to result in CRC errors detected by the hardware + during the transfer. Workaround: CONFIG_MMCSD_MULTIBLOCK_DISABLE=y" + + For this reason, CONFIG_MMCSD_MULTIBLOCK_DISABLE=y appears in the defconfig + file. + + 6. Another DMA-related concern. I see this statement in the reference + manual: "The burst configuration has to be selected in order to respect + the AHB protocol, where bursts must not cross the 1 KB address boundary + because the minimum address space that can be allocated to a single slave + is 1 KB. This means that the 1 KB address boundary should not be crossed + by a burst block transfer, otherwise an AHB error would be generated, + that is not reported by the DMA registers." + + There is nothing in the DMA driver to prevent this now. + + nxconsole: + ---------- + This is yet another NSH configuration. This NSH configuration differs + from the others, however, in that it uses the NxConsole driver to host + the NSH shell. + + Some of the differences in this configuration and the normal nsh configuration + include these settings in the defconfig file: + + These select NX Multi-User mode: + + CONFG_NX_MULTIUSER=y + CONFIG_DISABLE_MQUEUE=n + + The following definition in the defconfig file to enables the NxConsole + driver: + + CONFIG_NXCONSOLE=y + + The appconfig file selects examples/nxconsole instead of examples/nsh: + + CONFIGURED_APPS += examples/nxconsole + + Other configuration settings: + + CONFIG_STM32_CODESOURCERYW=y : CodeSourcery under Windows + CONFIG_LCD_LANDSCAPE=y : 320x240 landscape + + nxwm + ---- + This is a special configuration setup for the NxWM window manager + UnitTest. The NxWM window manager can be found here: + + trunk/NxWidgets/nxwm + + The NxWM unit test can be found at: + + trunk/NxWidgets/UnitTests/nxwm + + Documentation for installing the NxWM unit test can be found here: + + trunk/NxWidgets/UnitTests/README.txt + + Here is the quick summary of the build steps: + + 1. Intall the nxwm configuration + + $ cd ~/nuttx/trunk/nuttx/tools + $ ./configure.sh shenzhou/nxwm + + 2. Make the build context (only) + + $ cd .. + $ . ./setenv.sh + $ make context + ... + + 3. Install the nxwm unit test + + $ cd ~/nuttx/trunk/NxWidgets + $ tools/install.sh ~/nuttx/trunk/apps nxwm + Creating symbolic link + - To ~/nuttx/trunk/NxWidgets/UnitTests/nxwm + - At ~/nuttx/trunk/apps/external + + 4. Build the NxWidgets library + + $ cd ~/nuttx/trunk/NxWidgets/libnxwidgets + $ make TOPDIR=~/nuttx/trunk/nuttx + ... + + 5. Build the NxWM library + + $ cd ~/nuttx/trunk/NxWidgets/nxwm + $ make TOPDIR=~//nuttx/trunk/nuttx + ... + + 6. Built NuttX with the installed unit test as the application + + $ cd ~/nuttx/trunk/nuttx + $ make + + ostest: + ------ + This configuration directory, performs a simple OS test using + examples/ostest. By default, this project assumes that you are + using the DFU bootloader. + + CONFIG_STM32_CODESOURCERYW=y : CodeSourcery under Windows + + telnetd: + -------- + + A simple test of the Telnet daemon(see apps/netutils/README.txt, + apps/examples/README.txt, and apps/examples/telnetd). This is + the same daemon that is used in the nsh configuration so if you + use NSH, then you don't care about this. This test is good for + testing the Telnet daemon only because it works in a simpler + environment than does the nsh configuration.