diff --git a/doc/platform/fsl_frdm_k64f.rst b/doc/platform/fsl_frdm_k64f.rst index 300f8d7057a..5e5281b3be3 100644 --- a/doc/platform/fsl_frdm_k64f.rst +++ b/doc/platform/fsl_frdm_k64f.rst @@ -6,20 +6,20 @@ Platform Configuration: fsl_frdm_k64f Overview ******** -The fsl_frdm_k64f platform configuration is used by Zephyr projects +The fsl_frdm_k64f platform configuration is used by Zephyr applications that run on the Freescale Freedom Development Platform (FRDM-K64F). It provides support for an ARM Cortex-M4 CPU and the following devices: -* :abbr:`Nested Vectored interrupt controller (NVIC)` +* Nested Vectored Interrupt Controller (NVIC) -* :abbr:`System Tick system clock (SYSTICK)` +* System Tick System Clock (SYSTICK) -* serial port over USB (K20) +* Serial Port over USB (K20) See `Procedures`_ for using third-party tools to load and debug (in system mode with no OS awareness) a -Zephyr-based project on the target. Debugging is -done with :abbr:`GNU Debugger (GDB)`, using Eclipse plugins. +Zephyr application image on the target. Debugging is +done with GNU Debugger (GDB), using Eclipse plugins. .. note:: This platform configuration may work with similar boards, @@ -31,7 +31,8 @@ Supported Boards The fsl_frdm_k64f platform configuration has been tested to run on the Freescale Freedom Development Platform. The physical characteristics of this board (including pin names, jumper settings, memory mappings, ...) -can be found below. +can be found below. No claims are made about its suitability for use with +any other hardware system. Pin Names ========= @@ -92,7 +93,7 @@ Pin Names Jumpers & Switches ================== -Zephyr Project uses the FRDM-K64F default switch and jumper settings. +The Zephyr kernel uses the FRDM-K64F default switch and jumper settings. The default switch settings for the Freescale FRDM-K64F are: @@ -109,7 +110,7 @@ The default switch settings for the Freescale FRDM-K64F are: Memory Mappings =============== -The :file:`fsl_frdm_k64f` platform configuration uses the +The fsl_frdm_k64f platform configuration uses the following default hardware memory map addresses and sizes: +--------------------------+---------+------------------+ @@ -197,7 +198,7 @@ hardware features: +--------------+------------+----------------------+ -Other hardware features are not currently supported by Zephyr Project. +Other hardware features are not currently supported by the Zephyr kernel. See `vendor documentation`_ for a complete list of Freescale FRDM-K64F board hardware features. @@ -221,7 +222,7 @@ Handlers are provided for exceptions 1-6, 11-12, and 14-15. The table here identifies the handlers used for each exception. +------+------------+----------------+--------------------------+ -| Exc# | Name | Remarks | Used by Zephyr Project | +| Exc# | Name | Remarks | Used by Zephyr Kernel | +======+============+================+==========================+ | 1 | Reset | | system initialization | +------+------------+----------------+--------------------------+ @@ -319,9 +320,9 @@ table options: :option:`SW_ISR_TABLE` and :option:`SW_ISR_TABLE_DYNAMIC` -Depending on whether static tables are provided by the fsl_frdm_k64f -platform configuration or -the project, two other kconfig options are available: +Depending on whether static tables are provided by the platform +configuration or by the application, two other kconfig options +are available: :option:`SW_ISR_TABLE_STATIC_CUSTOM` and :option:`IRQ_VECTOR_TABLE_CUSTOM` @@ -347,7 +348,7 @@ The following interrupt table scenarios exist: In this scenario, some demuxing must take place which causes a delay before the ISR runs. On the plus side, - the vector table can be automatically generated by Zephyr Project. + the vector table can be automatically generated by the Zephyr kernel. Also, an argument can be passed to the ISR, allowing multiple devices of the same type to share the same ISR. Sharing an ISR can potentially save as much, or even more, @@ -365,12 +366,12 @@ The following interrupt table scenarios exist: and pre-populated. ISRs can have arguments with an automatic exception handling epilogue. Table pre-population provides better boot performance because there is no call to - :c:func:`irq_connect` during boot up, however, - the user must provide a file (C or assembly). In the platform - configuration, the file is :file:`sw_isr_table.c`, - but it can have any name. This file contains the :makevar:`_IsrTable[]` - variable filled by hand with each interrupt's ISRs. The variable - is an array of type struct_IsrTableEntry. When a user + :c:func:`irq_connect` during boot up; however, + the user must provide a file to override the platform's + default ISR table defined in :file:`sw_isr_table.S`. + This file must contain the :makevar:`_sw_isr_table[]` + variable initialized with each interrupt's ISR. The variable + is an array of type struct _IsrTableEntry. When a user provides their own :file:`sw_isr_table.c`, the type can be found by including :file:`sw_isr_table.h`. @@ -379,15 +380,14 @@ The following interrupt table scenarios exist: the best performance. In this setup, there is no software table. ISRs are installed - directly in the vector table using the _IrqVectorTable symbol + directly in the vector table using the **_irq_vector_table** symbol in the .irq_vector_table section. The symbol resolves to an array of words containing the addresses of ISRs. The linker script puts that section directly after the section containing the first 16 exception vectors (.exc_vector_table) to form the full vector table in ROM. - An example of this can be found in the :file:`irq_vector_table.s` - file provided by the fsl_frdm_k64f platform configuration. - Because ISRs + An example of this can be found in the platform's + :file:`irq_vector_table.c`. Because ISRs hook directly into the vector table, this setup gives the best possible performance regarding latency when handling interrupts. @@ -399,15 +399,14 @@ The following interrupt table scenarios exist: This configuration prevents the use of tickless idle. :option:`SW_ISR_TABLE=y`, :option:`SW_ISR_TABLE_STATIC_CUSTOM=y` - For overriding the static ISR tables defined by the platform - configuration: + For overriding the static ISR tables defined by the platform: - In this setup, the platform configuration provides the **_IsrTable** symbol - and data using a :file:`sw_isr_table.s` or :file:`sw_isr_table.c` file. + In this setup, the platform provides the **_irq_vector_table** + symbol and data in :file:`sw_isr_table.s`. :option:`SW_ISR_TABLE=n`, :option:`IRQ_VECTOR_TABLE_CUSTOM=y` - In this setup, the platform configuration provides the **_IrqVectorTable** symbol - and data using a :file:`irq_vector_table.s` or :file:`irq_vector_table.c` file. + In this setup, the platform provides the **_irq_vector_table** symbol + and data in `irq_vector_table.c`. Configuration Options ===================== @@ -434,8 +433,7 @@ Configuration Options :option:`NUM_IRQS` The platform configuration sets this value to the correct number of - interrupts available on the board. The default is '1', - which in most cases will be incorrect. + interrupts available on the board. The default is '34'. :option:`SW_ISR_TABLE` Set to 'n' when the platform configuration does not provide one. @@ -714,7 +712,7 @@ from the shell. Prerequisites ------------- -* Have the Zephyr executable image file saved as a binary file. +* Have the Zephyr application image file saved as a binary file. (The build should have created this binary file automatically.) @@ -760,7 +758,7 @@ There is no support for the following: However, using a XIP kernel effectively provides TEXT/RODATA write protection in ROM. -* SRAM at addresses 0x1FFF0000-0x0x1FFFFFFF +* SRAM at addresses 0x1FFF0000-0x1FFFFFFF * Writing to the hardware's flash memory