+ Added: \ref DAP_SWD_Sequence to enable SWD multi-drop target selection \n
+ Added: Test Domain Timer values in the commands \ref DAP_Info, \ref DAP_Transfer to allow time synchronisation with \ref DAP_TestInput_gr \n
+ Added: \ref DAP_TestInput_gr to support additional test inputs optional with trace recording (for example power measurement)
+
+
+
+
V1.1.0
Added: \ref DAP_swo_gr to support Serial Wire Output (SWO) in UART mode\n
Added: \ref DAP_atomic_gr support for executing time critical DAP commands
-
V1.00
-
Version 1.00 was never released; version number skipped.
+
V1.0.0
+
Version 1.0.0 was never released; version number skipped.
V0.02
diff --git a/CMSIS/DoxyGen/DAP/src/dap_USB_cmds.txt b/CMSIS/DoxyGen/DAP/src/dap_USB_cmds.txt
index 12f8747d14..fec2ae1895 100644
--- a/CMSIS/DoxyGen/DAP/src/dap_USB_cmds.txt
+++ b/CMSIS/DoxyGen/DAP/src/dap_USB_cmds.txt
@@ -14,6 +14,9 @@ This configuration setting can be obtained with the command \ref DAP_Info and is
optimize the performance for Full-Speed or High-Speed USB. The debugger must ensure that each
data package fits within the limitations of the configured \ref DAP_PACKET_SIZE.
+\note
+Commands that are not implemented reply with 0xFF instead of repeating the command byte.
+The available commands can be evaluated using the command \ref DAP_Info with 0xF0 (Capabilities).
Conventions and Command Structure
---------------------------------
@@ -25,8 +28,10 @@ The following conventions describe the command semantic used in the following do
\> | Prefix indicating the direction: Command from host to Debug Unit.
\< | Prefix indicating the direction: Response from Debug Unit to host.
BYTE | 8-bit value.
- SHORT | 16-bit value.
- WORD | 32-bit value.
+ SHORT | 16-bit value (low byte first).
+ WORD | 32-bit value (low byte first).
+ LWORD | 64-bit value (low byte first).
+ FLOAT | 32-bit single precision floating point value (LSB first).
0x01 | Fixed HEX value in C notation. Used for example to identify a command.
Reserved | The field above is reserved for future extension.
\*\*\*\* | The field above has exactly one occurrence.
@@ -41,9 +46,9 @@ The commands are described in a structure consisting of three lines.
\b Examples:
\code
- BYTE | SHORT *| WORD ***|
+ | BYTE | SHORT *| WORD ***|
> 0x99 | RecLen | Data |
- ******|********|+++++++++|
+ |******|********|+++++++++|
\endcode
The Command with the Command-ID 0x99 is sent from the host computer to the Debug Unit.
@@ -52,9 +57,9 @@ The value of RecLen indicates the number of WORDS that follow with
Depending on the Command the Debug Unit may send a Response.
\code
- BYTE ***| WORD***********|
-< 0 | Register Value |
- *Reserved|****************|
+ | BYTE ***| WORD***********|
+ < 0 | Register Value |
+ |*Reserved|****************|
\endcode
*/
@@ -104,7 +109,9 @@ CMSIS-DAP SWO (Serial Wire Output)
----------------------------------
CMSIS-DAP (CoreSight Debug Access Port) specifies debug protocol and interface for devices with CoreSight Debug and Trace.
-Currently it only supports debug but not also trace.
+
+\note
+The \ref DAP_swo_gr are only available when \ref DAP_Info with ID=0xF0 (Capabilities) returns in \b Info - Bit 2: 1 = SWO UART or Bit 3: 1 = SWO Manchester.
The following extension adds support for trace over SWO (Serial Wire Output).
@@ -150,6 +157,34 @@ The Transfer Commands allow to:
- Terminate an active data transfer.
*/
+/**************************************************************************************************/
+/**
+\defgroup DAP_TestInput_gr Test Input Commands
+\ingroup DAP_Commands_gr
+\brief Management commands for optional Test Inputs.
+
+CMSIS-DAP provides a command set that allows to implement an optional Test Input (TI) management in the Debug Unit.
+Recording of up to 16 different Test Inputs is possible. Test Input values can be recorded as BYTE, SHORT, or WORD.
+The Debug Unit may include scaling parameters and dynamic ranges for a channel (for example a 14-bit value with a 2-bit range selection).
+
+Test Inputs could be used for various scenarios, for example:
+ - capture power measurement from A/D converters.
+ - capture wait states or cache misses from a memory system.
+ - capture data transfer parameters of an RF interface.
+ - test input pins of a Debug Unit.
+
+These Test Inputs can be recorded continuously with a specified trace recording frequency. The recording allows you to correlate
+the Test Input information with program execution. For recording of the CMSIS-DAP Firmware includes an optional Trace Data Management based on configurable memory blocks.
+This Trace Data Management also captures SWO trace information.
+
+\note
+The \ref DAP_TestInput_gr are only available when \ref DAP_Info with ID=0xF0 (Capabilities) returns in \b Info - Bit 6: 1 = Trace Data Management.
+
+\image html "TraceManagement.png" "Trace Data Management"
+
+*/
+
+
/**************************************************************************************************/
/**
\defgroup DAP_atomic_gr Atomic Commands
@@ -159,11 +194,15 @@ The Transfer Commands allow to:
CMSIS-DAP command set is extended with two top level commands that allow the execution of multiple DAP commands further USB communication.
Executing multiple CMSIS-DAP commands is typically a requirement at the reset time of some devices. The sequence after reset can be time
critical and any USB communication would violate the available time window.
- - \ref DAP_ExecuteCommands_gr : execute multiple DAP commands from a single comamnd request
+ - \ref DAP_ExecuteCommands_gr : execute multiple DAP commands from a single command request
- \ref DAP_QueueCommands_gr : queue of multiple DAP commands before execution
These two DAP commands are used to collect several other DAP commands before execution.
Packet Size and Packet Count limitation (as reported via \ref DAP_Info) must be respected by the debugger.
+
+\note
+The \ref DAP_atomic_gr are only available when \ref DAP_Info with ID=0xF0 (Capabilities) returns in \b Info - Bit 4: 1 = Atomic Commands.
+
*/
/**************************************************************************************************/
@@ -189,9 +228,9 @@ The DAP_Info Command provides configuration information about the Debug U
DAP_Info Command:
\code
- BYTE | BYTE |
+| BYTE | BYTE |
> 0x00 | ID |
- ******|******|
+|******|******|
\endcode
- \b ID: Request Identifier to obtain information in the Response:
@@ -201,16 +240,18 @@ The DAP_Info Command provides configuration information about the Debug U
- \b 0x04 = Get the CMSIS-DAP Firmware Version (string).
- \b 0x05 = Get the Target Device Vendor (string).
- \b 0x06 = Get the Target Device Name (string).
- - \b 0xF0 = Get information about the Capabilities (BYTE) of the Debug Unit.
+ - \b 0xF0 = Get information about the Capabilities (BYTE) of the Debug Unit (see below for details).
+ - \b 0xF1 = Get the Test Domain Timer parameter information (see below for details).
+ - \b 0xF2 = Get the Trace Data Management parameter information (see below for details).
- \b 0xFD = Get the SWO Trace Buffer Size (WORD).
- \b 0xFE = Get the maximum Packet Count (BYTE).
- \b 0xFF = Get the maximum Packet Size (SHORT).
DAP_Info Response:
\code
- BYTE | BYTE | BYTE |
+| BYTE | BYTE | BYTE |
< 0x00 | Len | Info |
- ******|******|++++++|
+|******|******|++++++|
\endcode
- \b Len: Info length in bytes.
@@ -220,13 +261,6 @@ The DAP_Info Command provides configuration information about the Debug U
- a \b SHORT value (indicated with Len = 2).
- a \b WORD value (indicated with Len = 4).
-The ID Capabilities obtains information about the available interface to the Device. The
-information BYTE contains bits that indicate which communication methods are provided to the Device.
- - Bit 0: 1 = SWD Serial Wire Debug communication is implemented (0 = not implemented).
- - Bit 1: 1 = JTAG communication is implemented (0 = not implemented).
- - Bit 2: 1 = SWO UART - UART Serial Wire Output is implemented (0 = not implemented).
- - Bit 3: 1 = SWO Manchester - Manchester Serial Wire Output is implemented (0 = not implemented).
-
\note
The ID for Vendor ID, Product ID, and Serial Number may return no string (indicated by Len = 0).
In this case the USB Device Information is used to obtain Vendor, Product, and Serial Number.
@@ -235,6 +269,73 @@ In this case the USB Device Information is used to obtain Vendor, Product, and S
Target Device Vendor and Target Device Name are only available on Debug Units with known
Target Device. Refer to \ref TARGET_DEVICE_FIXED for more information. If the Target Device is not known
no string is returned (indicated by Len = 0).
+
+
+
+DAP_Info Response (for ID=0xF0):
+
+The ID=0xF0 Capabilities obtains information about the available interface to the Device.
+The reply consists of one or two \b Info bytes with bits that indicate the features of the Debug Unit.
+The features indicate the command scope of the CMSIS-DAP firmware. If certain features are not available, the debugger should not call the related commands as the may not be implemented. Commands that are not implemented reply with 0xFF instead of repeating the command byte.
+
+
+\code
+| BYTE | BYTE | BYTE *| BYTE |
+< 0x00 | Len | Info0 | Info1 |
+|******|******|*******|*******|
+\endcode
+
+- \b Len: 1 = Info0 present, 2 = Info0, Info1 present.
+
+Available transfer protocols to target:
+ - Info0 - Bit 0: 1 = SWD Serial Wire Debug communication is implemented (0 = \ref DAP_swd_gr not implemented).
+ - Info0 - Bit 1: 1 = JTAG communication is implemented (0 = \ref DAP_jtag_gr not implemented).
+
+Serial Wire Trace (SWO) support:
+ - Info0 - Bit 2: 1 = SWO UART - UART Serial Wire Output is implemented (0 = not implemented).
+ - Info0 - Bit 3: 1 = SWO Manchester - Manchester Serial Wire Output is implemented (0 = not implemented).
+
+Command extensions for transfer protocol:
+ - Info0 - Bit 4: 1 = Atomic Commands - \ref DAP_atomic_gr support is implemented (0 = \ref DAP_atomic_gr not implemented).
+ - Info0 - Bit 5: 1 = \ref DAP_SWD_Sequence command is implemented (0 = \ref DAP_SWD_Sequence not implemented).
+
+Time synchronisation via Test Domain Timer:
+ - Info0 - Bit 6: 1 = Test Domain Timer - debug unit support for Test Domain Timer is implemented (0 = not implemented).
+
+Test Input management:
+ - Info1 - Bit 0: 1 = Trace Data Management - Trace Data Management is implemented (0 = not implemented).
+
+
+
+DAP_Info Response (for ID=0xF1):
+
+The ID=0xF1 Test Domain Timer obtains the parameter information about an optional 32-bit Test Domain Timer that may be used for various time measurements.
+
+\code
+| BYTE | BYTE | WORD *****|
+< 0x00 | 0x08 | Frequency |
+|******|******|***********|
+\endcode
+
+- \b Frequency: Input frequency of the Test Domain Timer which indicates the resolution of the 32-bit TD_TimeStamp values.
+
+
+
+
+DAP_Info Response (for ID=0xF2):
+
+The ID=0xF2 Trace Data Management obtains the parameter information about an optional Trace Data Management.
+
+\code
+| BYTE | BYTE | SHORT *****| SHORT ****|
+< 0x00 | 0x04 | BlockCount | BlockSize |
+|******|******|************|***********|
+\endcode
+
+- \b BlockCount: Number of data blocks in the Trace Data Management.
+- \b BlockSize: Size (in bytes) of a data block in the Trace Data Management.
+
+
*/
@@ -251,9 +352,9 @@ This status information may be displayed on the Debug Unit. Therefore a Debug Un
DAP_HostStatus Command:
\code
- BYTE | BYTE **| BYTE **|
+| BYTE | BYTE **| BYTE **|
> 0x01 | Type | Status |
- ******|********|********|
+|******|********|********|
\endcode
- \b Type: specifies the type of the information that is sent in \b Status:
- \b 0 = Connect: Status indicates that the debugger is connected to the Debug Unit.
@@ -264,9 +365,9 @@ This status information may be displayed on the Debug Unit. Therefore a Debug Un
DAP_HostStatus Response:
\code
- BYTE | BYTE **|
+| BYTE | BYTE **|
< 0x01 | 0x00 |
- ******|********|
+|******|********|
\endcode
*/
@@ -283,9 +384,9 @@ connection to the Target Device.
DAP_Connect Command:
\code
- BYTE | BYTE |
+| BYTE | BYTE |
> 0x02 | Port |
- ******|******|
+|******|******|
\endcode
- \b Port: Selects the DAP port mode and configures the DAP I/O pins. The possible values are:
@@ -296,9 +397,9 @@ connection to the Target Device.
DAP_Connect Response:
\code
- BYTE | BYTE |
+| BYTE | BYTE |
< 0x02 | Port |
- ******|******|
+|******|******|
\endcode
- \b Port: DAP port mode initialized. The possible values are:
@@ -318,16 +419,16 @@ The DAP_Disconnect Command de-initializes the DAP I/O pins by calling the
DAP_Disconnect Command:
\code
- BYTE |
+| BYTE |
> 0x03 |
- ******|
+|******|
\endcode
DAP_Disconnect Response:
\code
- BYTE | BYTE |
+| BYTE | BYTE |
< 0x03 | Status |
- ******|********|
+|******|********|
\endcode
- \b Status: \ref DAP_Response_Status
@@ -345,9 +446,9 @@ the Target Device.
DAP_WriteABORT Command:
\code
- BYTE | BYTE *****| WORD *|
+| BYTE | BYTE *****| WORD *|
> 0x08 | DAP Index | Abort |
- ******|***********|*******|
+|******|***********|*******|
\endcode
- DAP Index: Zero based device index of the selected JTAG device. For SWD mode the value is ignored.
@@ -355,9 +456,9 @@ the Target Device.
DAP_WriteABORT Response:
\code
- BYTE | BYTE **|
+| BYTE | BYTE **|
< 0x08 | Status |
- ******|********|
+|******|********|
\endcode
- \b Status: \ref DAP_Response_Status
@@ -374,18 +475,18 @@ The DAP_Delay< Command waits for a time period specified in micro-seconds
DAP_Delay Command:
\code
- BYTE | SHORT |
+| BYTE | SHORT |
> 0x09 | Delay |
- ******|*******|
+|******|*******|
\endcode
- \b Delay: wait time in µs.
DAP_Delay Response:
\code
- BYTE | BYTE |
+| BYTE | BYTE |
< 0x09 | Status |
- ******|********|
+|******|********|
\endcode
- \b Status: \ref DAP_Response_Status
@@ -403,16 +504,16 @@ This command calls the user configurable function \ref RESET_TARGET.
DAP_ResetTarget Command:
\code
- BYTE |
+| BYTE |
> 0x0A |
- ******|
+|******|
\endcode
DAP_ResetTarget Response:
\code
- BYTE | BYTE | BYTE |
+| BYTE | BYTE | BYTE |
< 0x0A | Status | Execute |
- ******|********|*********|
+|******|********|*********|
\endcode
- \b Execute: indicates whether a device specific reset sequence was executed.
@@ -447,9 +548,9 @@ selected I/O Pins and wait until they the expected value appears or a timeout ex
DAP_SWJ_Pins Command:
\code
- BYTE | BYTE ******| BYTE ******| Word ****|
+| BYTE | BYTE ******| BYTE ******| Word ****|
> 0x10 | Pin Output | Pin Select | Pin Wait |
- ******|************|************|**********|
+|******|************|************|**********|
\endcode
- Pin Output: Value for selected output pins
@@ -460,9 +561,9 @@ selected I/O Pins and wait until they the expected value appears or a timeout ex
DAP_SWJ_Pins Response:
\code
- BYTE | BYTE *****|
+| BYTE | BYTE *****|
< 0x10 | Pin Input |
- ******|***********|
+|******|***********|
\endcode
- Pin Input: Pin state read from target Device.
*/
@@ -478,18 +579,18 @@ The DAP_SWJ_Clock Command sets the clock frequency for JTAG and SWD commu
DAP_SWJ_Clock Command:
\code
- BYTE | WORD *|
+| BYTE | WORD *|
> 0x11 | Clock |
- ******|*******|
+|******|*******|
\endcode
- \b Clock: Selects maximum SWD/JTAG Clock (SWCLK/TCK) value in Hz
DAP_SWJ_Clock Response:
\code
- BYTE | BYTE **|
+| BYTE | BYTE **|
< 0x11 | Status |
- ******|********|
+|******|********|
\endcode
- \b Status: \ref DAP_Response_Status
@@ -508,9 +609,9 @@ SWD/JTAG Reset, SWD<->JTAG switch and Dormant operation.
DAP_SWJ_Sequence Command
\code
- BYTE | BYTE **************| BYTE *************|
+| BYTE | BYTE **************| BYTE *************|
> 0x12 | Sequence Bit Count | Sequence Bit Data |
- ******|********************|+++++++++++++++++++|
+|******|********************|+++++++++++++++++++|
\endcode
- Sequence Bit Count: Number of bits in sequence: 1..256 (256 encoded as 0)
@@ -519,9 +620,9 @@ SWD/JTAG Reset, SWD<->JTAG switch and Dormant operation.
DAP_SWJ_Sequence Response:
\code
- BYTE | BYTE **|
+| BYTE | BYTE **|
< 0x12 | Status |
- ******|********|
+|******|********|
\endcode
- \b Status: \ref DAP_Response_Status
@@ -539,9 +640,9 @@ the SWD protocol refer to the ARM Debug Interface v5 - Interface Specificatio
DAP_SWD_Configure Command:
\code
- BYTE | BYTE *********|
+| BYTE | BYTE *********|
> 0x13 | Configuration |
- ******|***************|
+|******|***************|
\endcode
- \b Configuration: Contains information about SWD specific features \n
@@ -552,14 +653,62 @@ the SWD protocol refer to the ARM Debug Interface v5 - Interface Specificatio
DAP_SWD_Configure Response:
\code
- BYTE | BYTE **|
+| BYTE | BYTE **|
< 0x13 | Status |
- ******|********|
+|******|********|
+\endcode
+
+- \b Status: \ref DAP_Response_Status
+*/
+
+/**************************************************************************************************/
+/**
+\defgroup DAP_SWD_Sequence DAP_SWD_Sequence
+\ingroup DAP_swd_gr
+\brief Generate SWD sequence and output on SWDIO or capture input from SWDIO data.
+\details
+\note
+The \ref DAP_SWD_Sequence is only available when \ref DAP_Info with ID=0xF0 (Capabilities) returns in \b Info0 - Bit 5: 1 = \ref DAP_SWD_Sequence is implemented.
+
+
+The DAP_SWD_Sequence Command is used to generate special sequences in SWD mode on the pins SWCLK and SWDIO.
+For example, for SWD multi-drop target selection (see picture) it is required to put the SWDIO pin to input mode (where it is not driven).
+
+\image html "SWD_Sequence.png" "SWD sequence for multi-drop target selection"
+
+ - For mode=0 (output: SWDIO is driven), the data for the SWDIO pin are part of the DAP_SWD_Sequence Command.
+ - For mode=1 (input: SWDIO is not driven), the data from the SWDIO pin are captured and returned as part of the DAP_SWD_Sequence Response.
+
+DAP_SWD_Sequence Command:
+\code
+| BYTE | BYTE **********| BYTE *********| BYTE ******|
+> 0x21 | Sequence Count | Sequence Info | SWDIO Data |
+|******|****************|///////////////|++++++++++++|
+\endcode
+
+- Sequence Count: Number of Sequences
+- Sequence Info: Contains number of SWCLK cycles and SWDIO mode
+ - Bit 5 .. 0: Number of TCK cycles: 1 .. 64 (64 encoded as 0)
+ - Bit 6: reserved
+ - Bit 7: mode: 0=output (SWDIO Data in command), 1=input (SWDIO Data in response)
+- SWDIO Data (only for output mode): Data generated on SWDIO
+ - One bit for each TCK cycle
+ - LSB transmitted first, padded to BYTE boundary
+
+DAP_SWD_Sequence Response:
+\code
+| BYTE | BYTE **| BYTE ******|
+< 0x14 | Status | SWDIO Data |
+|******|********|++++++++++++|
\endcode
+- SWDIO Data (only for input mode): Data captured from SWDIO
+ - One bit for each SWCLK cycle for input mode
+ - LSB received first, padded to BYTE boundary
- \b Status: \ref DAP_Response_Status
*/
+
/**************************************************************************************************/
/**
\defgroup DAP_SWO_Transport DAP_SWO_Transport
@@ -574,9 +723,9 @@ Sets the SWO transport mode for reading trace data.
DAP_SWO_Transport Request:
\code
- BYTE | BYTE |
+ | BYTE | BYTE |
> 0x17 | Transport |
- ******|***********|
+ |******|***********|
\endcode
- \b Transport:
@@ -586,9 +735,9 @@ Sets the SWO transport mode for reading trace data.
DAP_SWO_Transport Response:
\code
- BYTE | BYTE |
+ | BYTE | BYTE |
< 0x17 | Status |
- ******|********|
+ |******|********|
\endcode
- \b Status: \ref DAP_Response_Status
@@ -611,9 +760,9 @@ Sets the SWO trace capture mode.
DAP_SWO_Mode Request:
\code
- BYTE | BYTE |
+ | BYTE | BYTE |
> 0x18 | Mode |
- ******|******|
+ |******|******|
\endcode
- \b Mode:
@@ -623,9 +772,9 @@ Sets the SWO trace capture mode.
DAP_SWO_Mode Response:
\code
- BYTE | BYTE |
+ | BYTE | BYTE |
< 0x18 | Status |
- ******|********|
+ |******|********|
\endcode
- \b Status: \ref DAP_Response_Status
@@ -645,17 +794,17 @@ Sets the baudrate for capturing SWO trace data. Can be called iteratively to det
DAP_SWO_Baudrate Request:
\code
- BYTE | WORD |
+ | BYTE | WORD |
> 0x19 | Baudrate |
- ******|**********|
+ |******|**********|
\endcode
- \b Baudrate: Requested baudrate
DAP_SWO_Baudrate Response:
\code
- BYTE | WORD |
+ | BYTE | WORD |
< 0x19 | Baudrate |
- ******|**********|
+ |******|**********|
\endcode
- \b Baudrate: Actual baudrate or 0 (baudrate not configured)
@@ -683,9 +832,9 @@ Controls the SWO trace data capture.
DAP_SWO_Control Request:
\code
- BYTE | BYTE |
+ | BYTE | BYTE |
> 0x1A | Control |
- ******|*********|
+ |******|*********|
\endcode
- \b Control:
- 0 - Stop
@@ -693,9 +842,9 @@ Controls the SWO trace data capture.
DAP_SWO_Control Response:
\code
- BYTE | BYTE |
+ | BYTE | BYTE |
< 0x1A | Status |
- ******|********|
+ |******|********|
\endcode
- \b Status: \ref DAP_Response_Status
@@ -717,16 +866,16 @@ Reads the SWO trace status.
DAP_SWO_Status Request:
\code
- BYTE |
+ | BYTE |
> 0x1B |
- ******|
+ |******|
\endcode
DAP_SWO_Status Response:
\code
- BYTE | BYTE | WORD |
+ | BYTE | BYTE | WORD |
< 0x1B | Trace Status | Trace Count |
- ******|**************|*************|
+ |******|**************|*************|
\endcode
- Trace Status:
@@ -750,17 +899,17 @@ Reads the captured SWO trace data from Trace Buffer.
DAP_SWO_Data Request:
\code
- BYTE | SHORT |
+ | BYTE | SHORT |
> 0x1C | Trace Count |
- ******|*************|
+ |******|*************|
\endcode
- Trace Count: Maxim number of Trace Data bytes to read
DAP_SWO_Data Response:
\code
- BYTE | BYTE | SHORT | BYTE |
+ | BYTE | BYTE | SHORT | BYTE |
< 0x1C | Trace Status | Trace Count | Trace Data |
- ******|**************|*************|////////////|
+ |******|**************|*************|////////////|
\endcode
- Trace Status:
@@ -775,7 +924,7 @@ Reads the captured SWO trace data from Trace Buffer.
/**
\defgroup DAP_JTAG_Sequence DAP_JTAG_Sequence
\ingroup DAP_jtag_gr
-\brief Generate JTAG sequence TMS,TDI and capture TDO
+\brief Generate JTAG sequence TMS, TDI and capture TDO
\details
The DAP_JTAG_Sequence Command may be used to auto-detect devices on the JTAG chain.
The result of this command can be used to calculate on the host computer the number of JTAG
@@ -783,9 +932,9 @@ devices and the JTAG IR register length. This information is the input for \ref
DAP_JTAG_Sequence Command:
\code
- BYTE | BYTE **********| BYTE *********| BYTE ****|
+| BYTE | BYTE **********| BYTE *********| BYTE ****|
> 0x14 | Sequence Count | Sequence Info | TDI Data |
- ******|****************|///////////////|//////////|
+|******|****************|///////////////|//////////|
\endcode
- Sequence Count: Number of Sequences
@@ -799,9 +948,9 @@ devices and the JTAG IR register length. This information is the input for \ref
DAP_JTAG_Sequence Response:
\code
- BYTE | BYTE **| BYTE ****|
-< 0x14 | Status |TDO Data |
- ******|********|++++++++++|
+| BYTE | BYTE **| BYTE ****|
+< 0x14 | Status | TDO Data |
+|******|********|++++++++++|
\endcode
- TDO Data: Data captured from TDO
@@ -823,9 +972,9 @@ configured by the debugger on the host computer.
DAP_JTAG_Configure Command:
\code
- BYTE | BYTE *| BYTE *****|
+| BYTE | BYTE *| BYTE *****|
> 0x15 | Count | IR Length |
- ******|*******|+++++++++++|
+|******|*******|+++++++++++|
\endcode
- \b Count: Number of devices in chain
@@ -833,9 +982,9 @@ configured by the debugger on the host computer.
DAP_JTAG_Configure Response:
\code
- BYTE | BYTE **|
+| BYTE | BYTE **|
< 0x15 | Status |
- ******|********|
+|******|********|
\endcode
- \b Status: \ref DAP_Response_Status
@@ -852,18 +1001,18 @@ The DAP_JTAG_IDCODE Command request the JTAG IDCODE for the selected devi
DAP_JTAG_IDCODE Command:
\code
- BYTE | BYTE ******|
+| BYTE | BYTE ******|
> 0x16 | JTAG Index |
- ******|************|
+|******|************|
\endcode
- JTAG Index: Zero based JTAG index of selected device.
DAP_JTAG_IDCODE Response:
\code
- BYTE | BYTE **| WORD ***|
+| BYTE | BYTE **| WORD ***|
< 0x16 | Status | ID Code |
- ******|********|*********|
+|******|********|*********|
\endcode
- ID Code: 32-bit JTAG ID Code of the device.
@@ -881,9 +1030,9 @@ The DAP_TransferConfigure Command sets parameters for \ref DAP_Transfer a
DAP_TransferConfigure Command:
\code
- BYTE | BYTE ******** SHORT *****| SHORT ******|
+| BYTE | BYTE ******** SHORT *****| SHORT ******|
> 0x04 | Idle Cycles | WAIT Retry | Match Retry |
- ******|*************|************|*************|
+|******|*************|************|*************|
\endcode
- Idle Cycles: Number of extra idle cycles after each transfer.
@@ -899,9 +1048,9 @@ The DAP_TransferConfigure Command sets parameters for \ref DAP_Transfer a
DAP_TransferConfigure Response:
\code
- BYTE | BYTE **|
+| BYTE | BYTE **|
< 0x04 | Status |
- ******|********|
+|******|********|
\endcode
- \b Status: \ref DAP_Response_Status
@@ -928,9 +1077,9 @@ The data transfer is aborted on a communication error:
DAP_Transfer Command:
\code
- BYTE | BYTE *****| BYTE **********| BYTE *************| WORD *********|
+| BYTE | BYTE *****| BYTE **********| BYTE *************| WORD *********|
> 0x05 | DAP Index | Transfer Count | Transfer Request | Transfer Data |
- ******|***********|****************|+++++++++++++++++++++++++++++++++++|
+|******|***********|****************|+++++++++++++++++++++++++++++++++++|
\endcode
- DAP Index: Zero based device index of the selected JTAG device. For SWD mode the value is ignored.
@@ -944,6 +1093,7 @@ The data transfer is aborted on a communication error:
- Bit 3: A3 Register Address bit 3.
- Bit 4: Value Match (only valid for Read Register): 0 = Normal Read Register, 1 = Read Register with Value Match.
- Bit 5: Match Mask (only valid for Write Register): 0 = Normal Write Register, 1 = Write Match Mask (instead of Register).
+ - Bit 7: TD_TimeStamp request: 0 = No time stamp, 1 = Include time stamp value from Test Domain Timer before every Transfer Data word (restrictions see note).
- Transfer Data: register value or match value
- for Write Register transfer request: the register value for the CoreSight register.
@@ -951,11 +1101,16 @@ The data transfer is aborted on a communication error:
- for Value Match transfer request: the match value of the CoreSight register.
- no data is sent for other operations.
+\note
+Transfer Request - Bit 7 (Time Stamp) cannot be combined with Bit 4 (Value Match) or Bit 5 (Match Mask).
+
+
+
DAP_Transfer Response:
\code
- BYTE | BYTE **********| BYTE *************| WORD *********|
-< 0x05 | Transfer Count | Transfer Response | Transfer Data |
- ******|****************|*******************|+++++++++++++++|
+| BYTE | BYTE **********| BYTE *************| WORD ********| WORD *********|
+< 0x05 | Transfer Count | Transfer Response | TD_TimeStamp | Transfer Data |
+|******|****************|*******************|//////////////|+++++++++++++++|
\endcode
- Transfer Count: Number of transfers: 1 .. 255 that are executed.
@@ -969,6 +1124,8 @@ The data transfer is aborted on a communication error:
- Bit 3: 1 = Protocol Error (SWD)
- Bit 4: 1 = Value Mismatch (Read Register with Value Match)
+- TD_TimeStamp: current Test Domain Timer value is added before each Transfer Data word when Transfer Request - bit 7: TD_TimeStamp request is set.
+
- Transfer Data: register value or match value in the order of the Transfer Request.
- for Read Register transfer request: the register value of the CoreSight register.
- no data is sent for other operations.
@@ -994,9 +1151,9 @@ The data transfer is aborted on a communication error:
DAP_TransferBlock Command:
\code
- BYTE | BYTE *****| SHORT**********| BYTE *************| WORD *********|
+| BYTE | BYTE *****| SHORT**********| BYTE *************| WORD *********|
> 0x06 | DAP Index | Transfer Count | Transfer Request | Transfer Data |
- ******|***********|****************|*******************|+++++++++++++++|
+|******|***********|****************|*******************|+++++++++++++++|
\endcode
- DAP Index: Zero based device index of the selected JTAG device. For SWD mode the value is ignored.
@@ -1004,10 +1161,10 @@ The data transfer is aborted on a communication error:
- Transfer Count: Number of transfers: 1 .. 65535.
- Transfer Request: Contains information about requested access from host
- - Bit0: APnDP: 0 = DP (Debug Port), 1 = AP (Access Port)
- - Bit1: RnW: 0 = Write Register, 1 = Read Register
- - Bit2: A2 := Register Address bit 2
- - Bit3: A3 := Register Address bit 3
+ - Bit 0: APnDP: 0 = DP (Debug Port), 1 = AP (Access Port)
+ - Bit 1: RnW: 0 = Write Register, 1 = Read Register
+ - Bit 2: A2 := Register Address bit 2
+ - Bit 3: A3 := Register Address bit 3
- Transfer Data: register values
- for Write Register transfer request: the register values written to the CoreSight register.
@@ -1015,9 +1172,9 @@ The data transfer is aborted on a communication error:
DAP_TransferBlock Response:
\code
- BYTE | SHORT *********| BYTE *************| WORD *********|
+| BYTE | SHORT *********| BYTE *************| WORD *********|
< 0x06 | Transfer Count | Transfer Response | Transfer Data |
- ******|****************|*******************|+++++++++++++++|
+|******|****************|*******************|+++++++++++++++|
\endcode
- DAP Index: Zero based device index of the selected JTAG device. For SWD mode the value is ignored.
@@ -1030,7 +1187,7 @@ The data transfer is aborted on a communication error:
- 2 = WAIT
- 4 = FAULT
- 7 = NO_ACK (no response from target)
- - Bit3: Protocol Error (SWD)
+ - Bit 3: Protocol Error (SWD)
- Transfer Data: register values
- no data is receive for Write Register operations.
@@ -1049,12 +1206,280 @@ aborted \ref DAP_Transfer or \ref DAP_TransferBlock command will respond with in
DAP_TransferAbort Command:
\code
- BYTE |
+| BYTE |
> 0x07 |
- ******|
+|******|
\endcode
*/
+
+/**************************************************************************************************/
+/**
+\defgroup DAP_TI_Info DAP_TI_Info
+\ingroup DAP_TestInput_gr
+\brief Get information about Test Input channel parameters of the CMSIS-DAP Debug Unit.
+
+The DAP_TI_Info Command provides information about additional Test Inputs that are possible to capture with the CMSIS-DAP Debug Unit.
+
+DAP_TI_Info Request:
+\code
+ | BYTE | BYTE | BYTE ***|
+ > 0x1D | ID | Channel |
+ |******|******|*********|
+\endcode
+
+- \b ID: Request Identifier to obtain information in the Response:
+ - \b 0x00 = Get general Test Input channel parameters (\b Channel value not used).
+ - \b 0x01 = Get parameters of a specific Test Input \b Channel.
+ - \b 0x02 = Get possible data capturing frequencies.
+
+- \b Channel: channel number.
+
+DAP_TI_Info Response for \b ID=0x00: Get general Test Input channel parameters
+\code
+ | BYTE | BYTE ****|
+ < 0x1D | Channels |
+ |******|**********|
+\endcode
+- \b Channels: number of channels available in the Debug Unit.
+
+DAP_TI_Info Response for \b ID=0x01: Get parameters of a specific Channel
+\code
+ | BYTE | BYTE ***| BYTE ******| BYTE ***| LWORD ***| LWORD *****| BYTE ****| FLOAT *| FLOAT *|
+ < 0x1D | Channel | Attributes | NumBits | IdString | UnitString | Compress | MinVal | MaxVal |
+ |******|*********|************|*********|**********|************|**********|++++++++|++++++++|
+\endcode
+- \b Channel: channel number that information belongs to.
+
+- \b Attributes: attributes of the data channel
+ - Bit 0..1: DataSize: number of bytes recorded (0=BYTE, 1=SHORT, 2=WORD)
+ - Bit 2..3: NumRanges: channel data provides additional range bits (see below)
+ - Bit 4: DT_TimeStamp: 1= channel provides time stamp based on Test Domain Timer
+- \b NumBits: resolution of the channel in bits
+- \b IdString: is a up to 8 character 8-bit US ASCII string that identifies the channel
+- \b UnitString: is a up to 8 character 8-bit US ASCII string that identifies the measurement unit of the channel (V, mA, kHz)
+- \b Compress: describes the difference communication that is optionally available (see below)
+- \b MinVal: minimum data value (= 0) represents the \b MinVal. Repeated for each range.
+- \b MaxVal: maximum data value result represents the \b MaxVal. Repeated for each range.
+
+\note
+\b NoRanges: specifies if the channel data has data ranges; possible values are:
+ - 0 = 1 range (1 MinVal/MaxVal value pair in the response).
+ - 1 = 2 ranges (2 MinVal/MaxVal value pairs are provided in the response)
+ - 2 = 4 ranges (4 MinVal/MaxVal value pairs are provided in the response)
+
+\note
+\b Compress specifies a method for data differences by this channel.
+ - 0 = no data differences can be communicated. Only Contiguous Value Format is transmitted in \ref DAP_TI_TransferBlock Response.
+ - 1 = data differences are transmitted when a single bit is different.
+ - 2 = new data are transmitted when a value has a significant difference. The least significant 3-bits are ignored. This is useful for A/D values.
+ - 3 = new data are transmitted when a value has a significant dynamic difference. Only the uppermost 8-bits are considered. This is useful for dynamic A/D values such as the currency consumption of a device.
+
+\note
+Data Value Scaling: the information \b NoBits, \b MinVal, \b MaxVal is used to convert the binary data value
+into a floating data value for displaying purposes. If both \b MinVal and \b MinMax are 0 no scaling formula is provided and raw data may be displayed instead.
+Scaling considers the \b NoBits value, for example at 12-bit resolution the maximum data value is 0x3FF.
+
+\note
+Data Ranges: the information \b NoRanges, \b NoBits allows scaled data value based on range information.
+The range information is provided in the upper data bits. For example a data channel with NoBits=12 and NRanges=2 provides in bit 0..11 the data value and in bit 12..13 the range value.
+
+Example 1: parameters for a channel that supports voltage measurement
+\code
+ IdString = 'U0' // Voltage symbol for U0 input
+ UnitString = 'V'; // ASCII character to denote voltage
+ NoBits = 10; // 10 bit A/D resolution
+ NoRanges = 0; // no ranges are supported
+ Compress = 2; // data differences may be communicated
+ MinVal = 2.5; // A/D result = 0x000 represents 2.5V
+ MaxVal = 6.0; // A/D result = 0x3FF represents 6.0V
+\endcode
+
+Example 2: parameters for a channel that supports current measurement with two ranges
+\code
+ IdString = 'I'; // Current symbol for I input
+ UnitString = 'mA'; // ASCII character to denote milli Ampere
+ NoBits = 12; // 12 bit A/D resolution (bit 0 .. 11 of data values contain A/D result)
+ NoRanges = 1; // 2 ranges are supported (bit 12 of data values contains range)
+ Compress = 3; // dynamic data differences may be communicated
+ MinVal[0] = 0; // A/D result = 0x000 in range 0 represents 0.0mA
+ MaxVal[0] = 1.0; // A/D result = 0xFFF in range 0 represents 1.0mA
+ MinVal[1] = 4.0; // A/D result = 0x000 in range 0 represents 4.0mA
+ MaxVal[1] = 20.0; // A/D result = 0xFFF in range 0 represents 20.0mA
+\endcode
+
+For a channel that reports MinVal = MaxVal = 0 the formula needs to be provided by the debugger as the debug unit is using perhaps an external shunt resistor.
+
+DAP_TI_Info Response for \b ID=0x02: Get possible data capturing frequencies for recording of a specific channel
+\code
+ | BYTE | BYTE ***| BYTE ********|DWORD ++++|
+ < 0x1D | Channel | NoSelections |Frequency |
+ |******|*********|**************|++++++++++|
+\endcode
+- \b Channel: channel number that information belongs to.
+ - Channel = 0..0xF: information of the selected channel
+ - Channel = 0xFF: information for common channel data capturing
+
+- \b NoSelections: number of possible capture frequencies
+ - NoSelections = 0: channel does not support data recording
+ - NoSelections = 1..15: channel allows selection of individual data capture frequencies.
+ - NoSelections = 0xFF: channel allows selection of a common data capture frequency.
+
+- \b Frequency: capture frequencies (repeated as indicated by NoSelection = 1..15)
+ - Frequency[0] capture frequency for CapSelect=0 (see DAP_TI_Capture)
+ - Frequency[1] capture frequency for CapSelect=1 (see DAP_TI_Capture)
+ - Frequency[n] capture frequency for CapSelect=n (see DAP_TI_Capture)
+*/
+
+
+/**************************************************************************************************/
+/**
+\defgroup DAP_TI_Value DAP_TI_Value
+\ingroup DAP_TestInput_gr
+\brief Get live data values from Test Input channels.
+
+The DAP_TI_Value Command returns the live (current) values of the Test Inputs in the
+CMSIS-DAP Debug Unit. Returned are live data that are currently available in the Test Inputs channels.
+
+DAP_TI_Value Request:
+\code
+ | BYTE | SHORT ******| BYTE ***********|
+ > 0x1E | ChannelMask | DT_Time_Request |
+ |******|*************|*****************|
+\endcode
+
+- \b ChannelMask: Bit mask that encodes the channels that should be scanned.
+- \b Time_Request:
+ - 0: No Time Stamp in response.
+ - 1: Include Time Stamp in response.
+
+DAP_TI_Value Response:
+\code
+ | BYTE | SHORT ******| WORD ++++++++|++++++++++++|
+ < 0x1E | ChannelMask | TD_TimeStamp | DataValues |
+ |******|*************|++++++++++++++|++++++++++++|
+\endcode
+- \b ChannelMask: Bit mask of channels that are actually scanned. Depending on the capabilities of the Debug Unit, this might be less than the request channels.
+
+- TD_TimeStamp: Test Domain Timer value at the beginning the the request (only present if \b DT_Time_Request is set to 1).
+
+- \b DataValues: data values of the various Test Inputs (starting with channel=0). The size of \b DataValues depends on the data size (see \ref DAP_TI_Info Response, Attributes bit 0..2) In case of SHORT or WORD data format, the LSB is send first.
+*/
+
+
+/**************************************************************************************************/
+/**
+\defgroup DAP_TI_Capture DAP_TI_Capture
+\ingroup DAP_TestInput_gr
+\brief Control continuous data recording of Test Input channels.
+
+The DAP_TI_Capture Command controls the data recording of the various Test Input channels.
+
+DAP_TI_Capture Request:
+\code
+ | BYTE | SHORT ******| SHORT ******| BYTE **| BYTE *****|
+ > 0x1F | ChannelMask | ChannelDiff | Action | CapSelect |
+ |******|*************|*************|********|***********|
+\endcode
+
+- \b ChannelMask: Bit mask that encodes the channels that should be recorded.
+
+- \b ChannelDiff: Bit mask that enables the channel to communicate data differences.
+ - \b 0x1 = Debug Unit may decide to send data differences.
+ - \b 0x0 = Debug Unit will always send data values.
+
+- \b Action: start or stop recording.
+ - \b 0x1 = start recording.
+ - \b 0x0 = stop recording.
+
+- \b CapSelect: select recording frequency for the data capturing (frequency is obtained via \ref DAP_TI_Info ID=0x02)
+
+
+DAP_TI_Capture Response:
+\code
+ | BYTE | SHORT ******|
+ < 0x1F | ChannelMask |
+ |******|*************|
+\endcode
+- \b ChannelMask: Bit mask of channels that are currently recorded. Depending on the capabilities of the Debug Unit, this might be less than the request channels.
+*/
+
+/**************************************************************************************************/
+/**
+\defgroup DAP_TI_TransferBlock DAP_TI_TransferBlock
+\ingroup DAP_TestInput_gr
+\brief Transfer the data that are recorded for various Test Input channels.
+
+The DAP_TI_TransferBlock Command initiates the data transfer of a single trace data block of the recorded trace data.
+The command delivers the content of one trace data block in the Trace Data Management system.
+
+DAP_TI_TransferBlock Request:
+\code
+ | BYTE | BYTE *******|
+ > 0x20 | DataRequest |
+ |******|*************|
+\endcode
+
+- \b DataRequest: specifies the requested data from the Trace Data Management system.
+ - bit 0: 1 = deliver one trace data block from any full trace data block (this includes SWO).
+ - bit 1: 1 = deliver one trace data block from SWO channel (even when partially filled).
+ - bit 2: 1 = deliver one trace data block from any partially filled trace data block (this includes SWO).
+
+DAP_TI_TransferBlock Response:
+\code
+ | BYTE | BYTE ***| SHORT ****| WORD ********|+++++++++++++|
+ < 0x20 | Channel | DataParms | TD_TimeStamp | ChannelData |
+ |******|*********|///////////|//////////////|+++++++++++++|
+\endcode
+- \b Channel:
+ - bit 0..3: number of the channel that the data belong to.
+ - bit 4: SWO record indicator: 1 = data belong to SWO data recording.
+ - bit 6: First record indicator: 1 = DataParms and TimeStamp is transferred. 0 = Only ChannelData.
+ - bit 7: No data indicator: 1 = No ChannelData available for this request. 0 = ChannelData are available.
+- \b DataParms: parameters for ChannelData.
+ - bit 0..12: number of data values in \b ChannelData. \ref DAP_TI_TransferBlock Response is repeated until all values are transmitted.
+ - bit 14: 1 = difference value format. 0 = contiguous value format.
+ - bit 15: 1 = Trace Data Management overflow since last \ref DAP_TI_TransferBlock Request. 0 = no overflow.
+- \b TD_TimeStamp: Test Domain Timer value at the read time of data values for ChannelData.
+- \b ChannelData: data values from the recorded Test Input channel.
+
+The ChannelData reply has depending on DataParms bit 14 two different formats. If \b ChannelDiff in DAP_TI_Capture Request is set
+for the specific channel, the Debug Unit may decide the data format depending on the trace data values.
+
+Contiguous Value Format transmits sequentially all data values stored in the trace data buffer. When DataParms bit 14 = 0 the \b ChannelData has the following format:
+\code
+ |************|************|************|......
+ | TraceValue | TraceValue | TraceValue |
+ |************|************|************|......
+\endcode
+
+The size of \b TraceValue depends on the data size for the channel (see \ref DAP_TI_Info Response, Attributes bit 0..2).
+\ref DAP_TI_TransferBlock Response is repeated until the number of \b TraceValues specified by DataParms bit 0 .. 12 is transmitted.
+
+Difference Value Format transmits data values only when there is a significant difference. When DataParms bit 14 = 1 the \b ChannelData has the following format:
+\code
+ |*************| SHORT *****|*************|......
+ | TraceValue0 | ValueIndex | TraceValueI |
+ |*************|////////////|/////////////|......
+\endcode
+- \b TraceValue0: is the first data value on the trace data buffer
+- \b ValueIndex: information about the next data value in TraceValueI.
+ - bit 0..12: \b index in trace data buffer of next data value with significant difference.
+ - bit 15: 1 = last trace value of trace data buffer send by \ref DAP_TI_TransferBlock Response.
+- \b TraceValueI: is the trace data value in in trace data buffer referenced by \b index.
+
+The size of \b TraceValue0 and \b TraceValueI depends on the data size for the channel (see \ref DAP_TI_Info Response, Attributes bit 0..2).
+\ref DAP_TI_TransferBlock Response is repeated until \b ValueIndex with bit 15 = 1 is transmitted.
+
+\note
+When all data values in the trace buffer are identical, \b ValueIndex is set to number of data values with bit 15 set to 1.
+
+
+
+*/
+
+
+
/**************************************************************************************************/
/**
\defgroup DAP_ExecuteCommands_gr DAP_ExecuteCommands
@@ -1065,9 +1490,9 @@ Executes multiple DAP commands that are provided in a single packet. Packet size
DAP_ExecuteCommands Request:
\code
- BYTE | BYTE | |
+ | BYTE | BYTE **|+++++++++++++++++++|
> 0x7F | NumCmd | Command Requests |
- ******|********|+++++++++++++++++++|
+ |******|********|+++++++++++++++++++|
\endcode
- \b NumCmd: Number of commands to execute
@@ -1075,9 +1500,9 @@ Executes multiple DAP commands that are provided in a single packet. Packet size
DAP_ExecuteCommands Response:
\code
- BYTE | BYTE | |
+ | BYTE | BYTE **|+++++++++++++++++++|
< 0x7F | NumCmd | Command Responses |
- ******|********|+++++++++++++++++++|
+ |******|********|+++++++++++++++++++|
\endcode
- \b NumCmd: Number of commands executed
@@ -1089,21 +1514,24 @@ Execute two \ref DAP_SWJ_Pins commands with \ref DAP_Delay in between.
Request:
\code
- BYTE | BYTE | BYTE | BYTE | BYTE | WORD | BYTE | SHORT | BYTE | BYTE | BYTE | WORD |
+ | BYTE | BYTE | BYTE | BYTE ******| BYTE ******| WORD ****| BYTE | SHORT | BYTE | BYTE ******| BYTE ******| WORD ****|
> 0x7F | 0x03 | 0x10 | Pin Output | Pin Select | Pin Wait | 0x09 | Delay | 0x10 | Pin Output | Pin Select | Pin Wait |
- ******|******|******|************|************|**********|******|*******|******|************|************|**********|
+ |******|******|******|************|************|**********|******|*******|******|************|************|**********|
|NumCmd| DAP_SWJ_Pins | DAP_Delay | DAP_SWJ_Pins |
\endcode
Response:
\code
- BYTE | BYTE | BYTE | BYTE | BYTE | BYTE | BYTE | BYTE |
+ | BYTE | BYTE | BYTE | BYTE *****| BYTE | BYTE **| BYTE | BYTE *****|
< 0x7F | 0x03 | 0x10 | Pin Input | 0x09 | Status | 0x10 | Pin Input |
- ******|******|******|***********|******|********|******|***********|
+ |******|******|******|***********|******|********|******|***********|
|NumCmd| DAP_SWJ_Pins | DAP_Delay | DAP_SWJ_Pins |
\endcode
*/
+
+
+
/**************************************************************************************************/
/**
\defgroup DAP_QueueCommands_gr DAP_QueueCommands
@@ -1119,15 +1547,15 @@ The command is similar to \ref DAP_ExecuteCommands_gr on a packet level but queu
DAP_QueueCommands Request:
\code
- BYTE | BYTE | |
+ | BYTE | BYTE **|+++++++++++++++++++|
> 0x7E | NumCmd | Command Requests | First queued packet
- ******|********|+++++++++++++++++++|
+ |******|********|+++++++++++++++++++|
.
.
.
- BYTE | BYTE | |
+ | BYTE | BYTE **|+++++++++++++++++++|
> 0x7E | NumCmd | Command Requests | Last queued packet
- ******|********|+++++++++++++++++++|
+ |******|********|+++++++++++++++++++|
\endcode
- \b > Command Request (any command except \b DAP_QueueCommands) \n
@@ -1137,15 +1565,15 @@ The command is similar to \ref DAP_ExecuteCommands_gr on a packet level but queu
DAP_QueueCommands Response:
\code
- BYTE | BYTE | |
+ | BYTE | BYTE **|+++++++++++++++++++|
< 0x7F | NumCmd | Command Responses |
- ******|********|+++++++++++++++++++|
+ |******|********|+++++++++++++++++++|
.
.
.
- BYTE | BYTE | |
+ | BYTE | BYTE **|+++++++++++++++++++|
< 0x7F | NumCmd | Command Responses |
- ******|********|+++++++++++++++++++|
+ |******|********|+++++++++++++++++++|
\endcode
- \b < Command Response (first non \b DAP_QueueCommands command)
@@ -1162,48 +1590,48 @@ Send \ref DAP_SWJ_Pins in fourth packet which executes queued commands and comma
\b Request:
\code
- BYTE | BYTE | BYTE | BYTE | BYTE | WORD | BYTE | SHORT |
+ | BYTE | BYTE | BYTE | BYTE ******| BYTE ******| WORD ****| BYTE | SHORT |
> 0x7E | 0x02 | 0x10 | Pin Output | Pin Select | Pin Wait | 0x09 | Delay |
- ******|******|******|************|************|**********|******|*******|
+ |******|******|******|************|************|**********|******|*******|
Queue|NumCmd| DAP_SWJ_Pins | DAP_Delay |
- BYTE | BYTE | BYTE | BYTE | BYTE | WORD |
+ | BYTE | BYTE | BYTE | BYTE ******| BYTE ******| WORD ****|
> 0x7E | 0x01 | 0x10 | Pin Output | Pin Select | Pin Wait |
- ******|******|******|************|************|**********|
+ |******|******|******|************|************|**********|
Queue|NumCmd| DAP_SWJ_Pins |
- BYTE | BYTE | BYTE | SHORT |
+ | BYTE | BYTE | BYTE | SHORT |
> 0x7E | 0x01 | 0x09 | Delay |
- ******|******|******|*******|
+ |******|******|******|*******|
Queue|NumCmd| DAP_Delay |
- BYTE | BYTE | BYTE | WORD |
+ | BYTE | BYTE ******| BYTE ******| WORD ****|
> 0x10 | Pin Output | Pin Select | Pin Wait |
- ******|************|************|**********|
+ |******|************|************|**********|
DAP_SWJ_Pins |
\endcode
\b Response:
\code
- BYTE | BYTE | BYTE | BYTE | BYTE | BYTE |
+ | BYTE | BYTE | BYTE | BYTE *****| BYTE | BYTE **|
< 0x7F | 0x02 | 0x10 | Pin Input | 0x09 | Status |
- ******|******|******|***********|******|********|
+ |******|******|******|***********|******|********|
|NumCmd| DAP_SWJ_Pins | DAP_Delay |
- BYTE | BYTE | BYTE | BYTE |
+ | BYTE | BYTE | BYTE | BYTE *****|
< 0x7F | 0x01 | 0x10 | Pin Input |
- ******|******|******|***********|
+ |******|******|******|***********|
|NumCmd| DAP_SWJ_Pins |
- BYTE | BYTE | BYTE | BYTE |
+ | BYTE | BYTE | BYTE | BYTE **|
< 0x7F | 0x01 | 0x09 | Status |
- ******|******|******|********|
+ |******|******|******|********|
|NumCmd| DAP_Delay |
- BYTE | BYTE |
+ | BYTE | BYTE *****|
< 0x10 | Pin Input |
- ******|***********|
+ |******|***********|
DAP_SWJ_Pins |
\endcode
*/
diff --git a/CMSIS/DoxyGen/DAP/src/dap_config.txt b/CMSIS/DoxyGen/DAP/src/dap_config.txt
index 9d492036aa..e6c3c47de9 100644
--- a/CMSIS/DoxyGen/DAP/src/dap_config.txt
+++ b/CMSIS/DoxyGen/DAP/src/dap_config.txt
@@ -14,10 +14,10 @@ The picture below shows the setup with an isolation adapter.
Hardware Requirements
---------------------
-The CMSIS-DAP Firmware is designed for Debug Units that fulfill the following hardware
+The CMSIS-DAP Firmware is designed for Debug Units that fulfil the following hardware
requirements:
- Cortex-M0, Cortex-M0+, Cortex-M3, or Cortex-M4 processor-based microcontroller.
- - CPU Clock: 48MHz or higher; Microcontroller must have a SYSTICK timer.
+ - CPU Clock: 48MHz or higher; microcontroller must have a SYSTICK timer.
- RAM: 8KB or more; Flash ROM: 16KB or more.
- Full-speed or High-speed USB Device Peripheral.
- 7 standard I/O pins for JTAG/SWD Device Interface.
@@ -40,11 +40,11 @@ Folders and Files | Description
.\\Firmware\\Example\\XMC4200 | CMSIS-DAP Firmware adapted to the Infineon XMC4200-based Debug Unit.
The CMSIS-DAP Firmware is designed to execute on a Debug Unit that is using a Cortex-M0, Cortex-M0+, Cortex-M3, or Cortex-M4
-processor-based microcontroller. To deploy the firmware to a new Debug Unit copy an existing firmware adaption to a new folder.
+processor-based microcontroller. To deploy the firmware to a new Debug Unit copy an existing firmware adaptation to a new folder.
For example, copy the folder .\\Firmware\\XMC4200 to a folder called .\\Firmware\\MyDebugUnit.
-To following steps describe the adaption of the CMSIS-DAP Firmware to a new Debug Unit:
-1. \ref DAP_ConfigMCU_gr : Select the microcontroller and replace the CMSIS-CORE files.
+To following steps describe the adaptation of the CMSIS-DAP Firmware to a new Debug Unit:
+1. \ref DAP_ConfigMCU_gr : Select the microcontroller and replace the CMSIS-Core (Cortex-M) files.
2. \ref DAP_ConfigIO_gr : Adapt the I/O Ports and specify other parameters for the Debug Unit.
3. \ref DAP_ConfigUSB_gr : Adapt the USB Peripheral to the microcontroller.
4. \ref DAP_USART_gr : Optional you may add a CMSIS-Driver USART to interface to SWO.
@@ -58,7 +58,7 @@ To following steps describe the adaption of the CMSIS-DAP Firmware to a new Debu
\defgroup DAP_ConfigMCU_gr Debug Unit Processor
\ingroup DAP_Config_gr
@{
-CMSIS-DAP Firmware runs on Debug Units with a Cortex-M Microcontroller.
+CMSIS-DAP Firmware runs on Debug Units with a Cortex-M microcontroller.
The CMSIS-DAP Firmware is designed to execute on a Debug Unit that is using a Cortex-M0, Cortex-M0+, Cortex-M3, or Cortex-M4
processor-based microcontroller.
@@ -163,7 +163,7 @@ A CMSIS-DAP conforming Debug Unit must be validated.
A CMSIS-DAP Debug Unit must be validate using the Keil MDK-ARM Debugger.
A validation project for MDK is provided in the folder .\\Validation\\MDK.
The project Blinky.uvproj is a "Blinky" application and needs to be adapted for the target hardware
-that is connected to the Debug Unit. Once the adaption is complete, you may open a Command Prompt and
+that is connected to the Debug Unit. Once the adaptation is complete, you may open a Command Prompt and
call the batch file TestAll.bat optionally with the path to UV4.EXE. This should generate the
following output.
diff --git a/CMSIS/DoxyGen/DAP/src/images/CMSIS_DAP_INTERFACE.png b/CMSIS/DoxyGen/DAP/src/images/CMSIS_DAP_INTERFACE.png
index 85fe9728d1..e97fd891ab 100644
Binary files a/CMSIS/DoxyGen/DAP/src/images/CMSIS_DAP_INTERFACE.png and b/CMSIS/DoxyGen/DAP/src/images/CMSIS_DAP_INTERFACE.png differ
diff --git a/CMSIS/DoxyGen/DAP/src/images/SWD_Sequence.png b/CMSIS/DoxyGen/DAP/src/images/SWD_Sequence.png
new file mode 100644
index 0000000000..0fe7f504dc
Binary files /dev/null and b/CMSIS/DoxyGen/DAP/src/images/SWD_Sequence.png differ
diff --git a/CMSIS/DoxyGen/DAP/src/images/TraceManagement.png b/CMSIS/DoxyGen/DAP/src/images/TraceManagement.png
new file mode 100644
index 0000000000..1a1207fe63
Binary files /dev/null and b/CMSIS/DoxyGen/DAP/src/images/TraceManagement.png differ
diff --git a/CMSIS/DoxyGen/DSP/dsp.dxy b/CMSIS/DoxyGen/DSP/dsp.dxy
index b08275a9ec..f1ff40ad5b 100644
--- a/CMSIS/DoxyGen/DSP/dsp.dxy
+++ b/CMSIS/DoxyGen/DSP/dsp.dxy
@@ -38,7 +38,7 @@ PROJECT_NAME = CMSIS-DSP
# could be handy for archiving the generated documentation or if some version
# control system is used.
-PROJECT_NUMBER = "Version 1.5.1"
+PROJECT_NUMBER = "Version 1.5.2"
# Using the PROJECT_BRIEF tag one can provide an optional one line description
# for a project that appears at the top of each page and should give viewer a
diff --git a/CMSIS/DoxyGen/DSP/src/Change Log.txt b/CMSIS/DoxyGen/DSP/src/Change Log.txt
index c868ab60a3..db9d638f5f 100644
--- a/CMSIS/DoxyGen/DSP/src/Change Log.txt
+++ b/CMSIS/DoxyGen/DSP/src/Change Log.txt
@@ -1,10 +1,16 @@
/**
\page ChangeLog_pg Change Log
+
+Version 1.5.2
+
+Modified arm_math.h
+ - fixed GNU Compiler specific diagnostics.
+
Version 1.5.1
-Changed copyrigth note.
+Changed copyright note.
Added ARMv8M DSP libraries.
diff --git a/CMSIS/DoxyGen/Doxygen_Templates/printComponentTabs.js b/CMSIS/DoxyGen/Doxygen_Templates/printComponentTabs.js
index 096c47f93e..96fba828f2 100644
--- a/CMSIS/DoxyGen/Doxygen_Templates/printComponentTabs.js
+++ b/CMSIS/DoxyGen/Doxygen_Templates/printComponentTabs.js
@@ -13,16 +13,17 @@ function tabElement(id, folderName, tabTxt ) {
var arr = [];
// fill array
- arr.push( new tabElement( "GEN", "/General/html/", "General") );
- arr.push( new tabElement( "CORE", "/Core/html/", "Core") );
- arr.push( new tabElement( "DRV", "/Driver/html/", "Driver") );
- arr.push( new tabElement( "DSP", "/DSP/html/", "DSP") );
- arr.push( new tabElement( "RTOSv1", "/RTOS/html/", "RTOS v1") );
- arr.push( new tabElement( "RTOSv2", "/RTOS2/html/", "RTOS v2") );
-// arr.push( new tabElement( "RTX", "/RTX/html/", "RTX") );
- arr.push( new tabElement( "PACK", "/Pack/html/", "Pack") );
- arr.push( new tabElement( "SVD", "/SVD/html/", "SVD") );
- arr.push( new tabElement( "DAP", "/DAP/html/", "DAP") );
+ arr.push( new tabElement( "GEN", "/General/html/", "General") );
+ arr.push( new tabElement( "CORE_A", "/Core_A/html/", "CMSIS-Core(A)") );
+ arr.push( new tabElement( "CORE_M", "/Core/html/", "CMSIS-Core(M)") );
+ arr.push( new tabElement( "DRV", "/Driver/html/", "Driver") );
+ arr.push( new tabElement( "DSP", "/DSP/html/", "DSP") );
+ arr.push( new tabElement( "RTOSv1", "/RTOS/html/", "RTOS v1") );
+ arr.push( new tabElement( "RTOSv2", "/RTOS2/html/", "RTOS v2") );
+ arr.push( new tabElement( "PACK", "/Pack/html/", "Pack") );
+ arr.push( new tabElement( "SVD", "/SVD/html/", "SVD") );
+ arr.push( new tabElement( "DAP", "/DAP/html/", "DAP") );
+ arr.push( new tabElement( "ZONE", "/Zone/html/", "Zone") );
// write tabs
// called from the header file.
diff --git a/CMSIS/DoxyGen/Driver/src/Driver_CAN.c b/CMSIS/DoxyGen/Driver/src/Driver_CAN.c
index 0213de9489..ec3d0e860d 100644
--- a/CMSIS/DoxyGen/Driver/src/Driver_CAN.c
+++ b/CMSIS/DoxyGen/Driver/src/Driver_CAN.c
@@ -28,7 +28,7 @@ CAN 2.0B supports:
- \ref Remote_Frame requests
\anchor CAN_FD
-**CAN FD**
+CAN FD
Support for CAN FD depends on the hardware.
A CMSIS-Driver that supports CAN FD has the capability \ref ARM_CAN_CAPABILITIES data field \b fd_mode = \token{1}, which can be
@@ -40,7 +40,7 @@ CAN FD supports:
CAN FD does not support \ref Remote_Frame requests.
-**Block Diagram**
+Block Diagram
The CAN Driver API defines a CAN interface for middleware components. The CAN Driver supports multiple
nodes, which are able to send and receive messages, but not simultaneously.
@@ -57,12 +57,12 @@ The driver implementation is a typical part of the Device Family Pack (DFP) that
peripherals of the microcontroller family.
-**Driver Functions**
+Driver Functions
The driver functions are published in the access struct as explained in \ref DriverFunctions
- \ref ARM_DRIVER_CAN : access struct for CAN driver functions
-**Example Code**
+Example Code
The following example code shows the usage of the CAN interface.
@@ -278,7 +278,7 @@ In general, data transmission is performed on an autonomous basis with the data
However, sending a Remote Frame allows a destination node to request the data from the source node.
The examples below shows the data exchange using a Remote Transmission Request (RTR).
-**Example for automatic Data Message response on RTR**
+Example for automatic Data Message response on RTR
For automatic data message response on an RTR, the object is configured with the function \ref ARM_CAN_ObjectConfigure \em obj_cfg = \ref ARM_CAN_OBJ_RX_RTR_TX_DATA.
@@ -306,7 +306,7 @@ and the related \em obj_idx.
\endcode
-**Example for automatic Data Message reception using RTR**
+Example for automatic Data Message reception using RTR
For automatic data message reception on an RTR, the object is configured with the function \ref ARM_CAN_ObjectConfigure \em obj_cfg = \ref ARM_CAN_OBJ_TX_RTR_RX_DATA.
diff --git a/CMSIS/DoxyGen/Driver/src/Driver_ETH.c b/CMSIS/DoxyGen/Driver/src/Driver_ETH.c
index 7e0fb3d976..8d6e808776 100644
--- a/CMSIS/DoxyGen/Driver/src/Driver_ETH.c
+++ b/CMSIS/DoxyGen/Driver/src/Driver_ETH.c
@@ -20,7 +20,7 @@ Wikipedia offers more information about
the Ethernet.
-**Block Diagram**
+Block Diagram
The Ethernet PHY connects typically to the Ethernet MAC using an MII (Media Independent Interface) or RMII (Reduced Media Independent Interface).
@@ -28,7 +28,7 @@ The Ethernet PHY connects typically to the Ethernet MAC using an MII (Media Inde
\image html EthernetSchematic.png "Block Diagram of a typical Ethernet Interface"
-**Ethernet API**
+Ethernet API
The following header files define the Application Programming Interface (API) for the Ethernet interface:
- \b %Driver_ETH.h : Common definitions of the Ethernet PHY and MAC part
@@ -42,7 +42,7 @@ The driver implementation of the Ethernet PHY is a typical part of a \b Network
For parameters, the value marked with (default) is the setting after the driver initialization.
-**Driver Functions**
+Driver Functions
The driver functions are published in the access struct as explained in \ref DriverFunctions
- \ref ARM_DRIVER_ETH_MAC : access struct for Ethernet MAC driver functions.
@@ -51,7 +51,7 @@ The driver functions are published in the access struct as explained in \ref Dri
Both drivers are used in combination and usually the Ethernet MAC provides a media interface to the Ethernet PHY.
A typical setup sequence for the drivers is shown below:
-**Example Code**
+Example Code
The following example code shows the usage of the Ethernet interface.
diff --git a/CMSIS/DoxyGen/Driver/src/Driver_Flash.c b/CMSIS/DoxyGen/Driver/src/Driver_Flash.c
index 19f5f30664..cd63f1a024 100644
--- a/CMSIS/DoxyGen/Driver/src/Driver_Flash.c
+++ b/CMSIS/DoxyGen/Driver/src/Driver_Flash.c
@@ -18,21 +18,19 @@ characteristic of these Flash devices allow a direct code execution
(XIP) and data storage in a single memory
product.
-**Flash API**
+Flash API
-The \b Flash \b API provides a generic API suitable for Flashes with NOR memory cells independent from the actual interface
+The Flash API provides a generic API suitable for Flashes with NOR memory cells independent from the actual interface
to the MCU (memory bus, SPI, ...). SPI
flashes are typically not named NOR flashes but have usually same flash cell properties.
The following header files define the Application Programming Interface (API) for the Flash interface:
- \b %Driver_Flash.h : Driver API for Flash Device Interface
-
-**Driver Functions**
+Driver Functions
The driver functions are published in the access struct as explained in \ref DriverFunctions
- \ref ARM_DRIVER_FLASH : access struct for Flash driver functions
-
@{
*/
/*
diff --git a/CMSIS/DoxyGen/Driver/src/Driver_I2C.c b/CMSIS/DoxyGen/Driver/src/Driver_I2C.c
index 074b0f56e0..17be13d2ab 100644
--- a/CMSIS/DoxyGen/Driver/src/Driver_I2C.c
+++ b/CMSIS/DoxyGen/Driver/src/Driver_I2C.c
@@ -33,7 +33,7 @@ Devices can operation in Master or Slave mode:
- To operate in Slave mode set the slave address using the function \ref ARM_I2C_Control. The functions \ref ARM_I2C_SlaveTransmit or \ref ARM_I2C_SlaveReceive are used to transfer data in Slave mode.
-**I2C Slave Address**
+I2C Slave Address
Depending on the device, I2C supports 7-bit and 10-bit Slaves addresses.
The element address_10_bit in \ref ARM_I2C_CAPABILITIES indicates that the driver is able to handle 10-bit addresses.
@@ -43,14 +43,14 @@ I2C also supports a General Call to all Slaves by using the slave add
A General Call is recognized by Slaves have a slave address value \ref ARM_I2C_ADDRESS_GC registered with the
function \ref ARM_I2C_Control.
-**Block Diagram**
+Block Diagram
The I2C driver allows you to connect low-speed peripherals to a motherboard, embedded system, cellphone, or other electronic device.
\image html I2C_BlockDiagram.png "Master/Slave connected via I2C interface"
-**I2C API**
+I2C API
The following header files define the Application Programming Interface (API) for the I2C interface:
- \b %Driver_I2C.h : Driver API for I2C Bus Peripheral
@@ -59,24 +59,21 @@ The driver implementation is a typical part of the Device Family Pack (DFP) that
peripherals of the microcontroller family.
-**Driver Functions**
+Driver Functions
The driver functions are published in the access struct as explained in \ref DriverFunctions
- \ref ARM_DRIVER_I2C : access struct for I2C driver functions
-\anchor example **Example Code**
+\anchor example Example Code
The following example code shows the usage of the I2C interface in Master mode.
\include I2C_Demo.c
-\if TODO_later
The following example code shows the usage of the I2C interface in Slave mode.
-Add: Code example that shows usage of slave mode.
-\endif
-
+\include I2C_SlaveDemo.c
@{
*/
diff --git a/CMSIS/DoxyGen/Driver/src/Driver_MCI.c b/CMSIS/DoxyGen/Driver/src/Driver_MCI.c
index 9d5ee28310..7624a50edc 100644
--- a/CMSIS/DoxyGen/Driver/src/Driver_MCI.c
+++ b/CMSIS/DoxyGen/Driver/src/Driver_MCI.c
@@ -24,7 +24,7 @@ es that are directly soldered to the PCB (eMMC).
- The SD Association provides detailed documentation under www.sdcard.org.
- The MultiMediaCard Association (merged with JEDEC) provides detailed documentation under www.jedec.org.
-**Block Diagram**
+Block Diagram
The MCI driver allows you to exchange data of the SD/MMC memory via SD/MMC interface.
@@ -42,7 +42,7 @@ The following modes are supported by SD/MMC memory cards:
\image html SD_4BitBusMode.png "SD memory connected via 4-bit SD Bus Mode"
-**MCI API**
+MCI API
The following header files define the Application Programming Interface (API) for the MCI interface:
- \b %Driver_MCI.h : Driver API for Memory Card Interface using SD/MMC interface
@@ -54,7 +54,7 @@ peripherals of the microcontroller family.
For parameters, the value marked with (default) is the setting after the driver initialization.
-**Driver Functions**
+Driver Functions
The driver functions are published in the access struct as explained in \ref DriverFunctions
- \ref ARM_DRIVER_MCI : access struct for MCI driver functions
diff --git a/CMSIS/DoxyGen/Driver/src/Driver_NAND.c b/CMSIS/DoxyGen/Driver/src/Driver_NAND.c
index 69ed9f7604..efd24ead22 100644
--- a/CMSIS/DoxyGen/Driver/src/Driver_NAND.c
+++ b/CMSIS/DoxyGen/Driver/src/Driver_NAND.c
@@ -17,14 +17,14 @@
Wikipedia offers more information about
the Flash Memories, including NAND.
-**Block Diagram**
+Block Diagram
\image html NAND_Schematics.png "Simplified NAND Flash Schematic"
-**NAND API**
+NAND API
The following header files define the Application Programming Interface (API) for the NAND interface:
- \b %Driver_NAND.h : Driver API for NAND Flash Device Interface
@@ -33,7 +33,7 @@ The driver implementation is a typical part of the Device Family Pack (DFP) that
peripherals of the microcontroller family.
-**Driver Functions**
+Driver Functions
The driver functions are published in the access struct as explained in \ref DriverFunctions
- \ref ARM_DRIVER_NAND : access struct for NAND driver functions
diff --git a/CMSIS/DoxyGen/Driver/src/Driver_SAI.c b/CMSIS/DoxyGen/Driver/src/Driver_SAI.c
index 251cafcc88..d630d36ae3 100644
--- a/CMSIS/DoxyGen/Driver/src/Driver_SAI.c
+++ b/CMSIS/DoxyGen/Driver/src/Driver_SAI.c
@@ -39,14 +39,14 @@ can transfer digital audio using various protocols:
- \ref Driver_SAI_User
-**Block Diagram**
+Block Diagram
\image html SAI_Schematics.png "Simplified SAI Schematic"
-**SAI API**
+SAI API
The following header files define the Application Programming Interface (API) for the SAI interface:
- \b %Driver_SAI.h : Driver API for Serial Audio Interface
@@ -56,7 +56,7 @@ The driver implementation is a typical part of the
the microcontroller family.
-**Driver Functions**
+Driver Functions
The driver functions are published in the access struct as explained in \ref DriverFunctions
- \ref ARM_DRIVER_SAI : access struct for SAI driver functions
diff --git a/CMSIS/DoxyGen/Driver/src/Driver_SPI.c b/CMSIS/DoxyGen/Driver/src/Driver_SPI.c
index 9d93de0782..84924b6154 100644
--- a/CMSIS/DoxyGen/Driver/src/Driver_SPI.c
+++ b/CMSIS/DoxyGen/Driver/src/Driver_SPI.c
@@ -17,7 +17,7 @@ the interface is often used to connect peripheral components at board (PCB) leve
Slave (SCLK and SS are inputs). Wikipedia offers more information about
the Serial Peripheral Interface Bus.
-**Block Diagram**
+Block Diagram
The SPI Driver API defines a SPI interface for middleware components. The SPI Driver supports multiple
slaves, but if only one slave is connected, then the Slave Select signal can be omitted.
@@ -39,7 +39,7 @@ SCLK | Serial Clock | Serial clock output from Master.
MISO | Master In, Slave Out | MISO input of the Master connects to MISO output of the Slave.
-**SPI API**
+SPI API
The following header files define the Application Programming Interface (API) for the SPI interface:
- \b %Driver_SPI.h : Driver API for SPI Bus Peripheral
@@ -48,13 +48,13 @@ The driver implementation is a typical part of the Device Family Pack (DFP) that
peripherals of the microcontroller family.
-**Driver Functions**
+Driver Functions
The driver functions are published in the access struct as explained in \ref DriverFunctions
- \ref ARM_DRIVER_SPI : access struct for SPI driver functions
-**Example Code**
+Example Code
The following example code shows the usage of the SPI interface.
diff --git a/CMSIS/DoxyGen/Driver/src/Driver_Storage.c b/CMSIS/DoxyGen/Driver/src/Driver_Storage.c
index 7725cd26fb..6cd43d812d 100644
--- a/CMSIS/DoxyGen/Driver/src/Driver_Storage.c
+++ b/CMSIS/DoxyGen/Driver/src/Driver_Storage.c
@@ -33,13 +33,13 @@ storage driver.
\image html storage_sw_stack.png
-**Storage API**
+Storage API
The following header files define the Application Programming Interface (API) for the Flash interface:
- \b %Driver_Storage.h : Driver API for Storage Device Interface
-**Driver Functions**
+Driver Functions
The driver functions are published in the access struct as explained in \ref StorageDriverFunctions
- \ref ARM_DRIVER_STORAGE : access struct for Storage driver functions
diff --git a/CMSIS/DoxyGen/Driver/src/Driver_USART.c b/CMSIS/DoxyGen/Driver/src/Driver_USART.c
index 507409e5a0..e28432ab31 100644
--- a/CMSIS/DoxyGen/Driver/src/Driver_USART.c
+++ b/CMSIS/DoxyGen/Driver/src/Driver_USART.c
@@ -22,7 +22,7 @@ Wikipedia offers more information about
the Universal asynchronous receiver/transmitter.
-**USART API**
+USART API
The following header files define the Application Programming Interface (API) for the USART interface:
- \b %Driver_USART.h : Driver API for Universal Synchronous Asynchronous Receiver/Transmitter
@@ -31,13 +31,13 @@ The driver implementation is a typical part of the Device Family Pack (DFP) that
peripherals of the microcontroller family.
-**Driver Functions**
+Driver Functions
The driver functions are published in the access struct as explained in \ref DriverFunctions
- \ref ARM_DRIVER_USART : access struct for USART driver functions
-**Example Code**
+Example Code
The following example code shows the usage of the USART interface for asynchronous communication.
diff --git a/CMSIS/DoxyGen/Driver/src/Driver_USB.c b/CMSIS/DoxyGen/Driver/src/Driver_USB.c
index 366ce27c0d..9b324368ec 100644
--- a/CMSIS/DoxyGen/Driver/src/Driver_USB.c
+++ b/CMSIS/DoxyGen/Driver/src/Driver_USB.c
@@ -20,7 +20,7 @@ In microcontroller (MCU) applications, the interface is often used to connect a
- The USB Implementers Forum provides detailed documentation under www.usb.org.
-**Block Diagram**
+Block Diagram
Typically only one USB Device is connected to a USB Host. If several USB devices must be connected to the same USB host, then
the connection must be done via a USB hub.
@@ -30,7 +30,7 @@ the connection must be done via a USB hub.
-**USB API**
+USB API
The following header files define the Application Programming Interface (API) for the USB interface:
- \b %Driver_USB.h : Common definitions of the USBD and USBH interface
@@ -41,7 +41,7 @@ The driver implementation is a typical part of the Device Family Pack (DFP) that
peripherals of the microcontroller family.
-**Driver Functions**
+Driver Functions
The driver functions are published in the access struct as explained in \ref DriverFunctions
- \ref ARM_DRIVER_USBD : access struct for USBD driver functions
@@ -65,7 +65,7 @@ A typical setup sequence for the driver is shown below:
\ingroup usb_interface_gr
\details
-**USB Device API**
+USB Device API
The header file \b Driver_USBD.h defines the API for the USB Device Driver interface used by middleware components.
The driver implementation itself is a typical part of the Device Family Pack, which provides entry points to the interface
@@ -77,7 +77,7 @@ Callbacks are called by the driver, in interrupt context when an appropriate eve
and endpoint related events (\ref USBD_ep_events).
-**USB Device Function Call Sequence**
+USB Device Function Call Sequence
To use the USBD driver invoke the API functions in the following order:
@@ -109,7 +109,7 @@ To use the USBD driver invoke the API functions in the following order:
\addtogroup usbh_interface_gr
\ingroup usb_interface_gr
\details
-**USB Host API**
+USB Host API
The header file \b Driver_USBH.h defines the API for the USB Host Driver interface used by middleware components.
The driver implementation itself is a typical part of the Device Family Pack, which provides entry points to the interface
@@ -122,7 +122,7 @@ and pipe related events (\ref ARM_USBH_SignalPipeEvent).
\cond
-**USB Host Function Call Sequence**
+USB Host Function Call Sequence
To use the USBH driver invoke the API functions in the following order:
diff --git a/CMSIS/DoxyGen/Driver/src/I2C_SlaveDemo.c b/CMSIS/DoxyGen/Driver/src/I2C_SlaveDemo.c
new file mode 100644
index 0000000000..4017f3b63d
--- /dev/null
+++ b/CMSIS/DoxyGen/Driver/src/I2C_SlaveDemo.c
@@ -0,0 +1,36 @@
+#include "Driver_I2C.h"
+
+// I2C driver instance
+extern ARM_DRIVER_I2C Driver_I2C0;
+static ARM_DRIVER_I2C *i2cDev = &Driver_I2C0;
+
+static volatile uint32_t event = 0;
+
+static void I2C_DrvEvent (uint32_t e) {
+ event |= e;
+}
+
+int main (void) {
+ uint8_t cnt = 0;
+
+ /* Initialize I2C peripheral */
+ i2cDev->Initialize(I2C_DrvEvent);
+
+ /* Power-on SPI peripheral */
+ i2cDev->PowerControl(ARM_POWER_FULL);
+
+ /* Configure USART bus*/
+ i2cDev->Control(ARM_I2C_OWN_ADDRESS, 0x78);
+
+ while (1) {
+ /* Receive chuck */
+ i2cDev->SlaveReceive(&cnt, 1);
+ while ((event & ARM_event_TRANSFER_DONE) == 0);
+ event &= ~ARM_event_TRANSFER_DONE;
+
+ /* Transmit chunk back */
+ i2cDev->SlaveTransmit(&cnt, 1);
+ while ((event & ARM_event_TRANSFER_DONE) == 0);
+ event &= ~ARM_event_TRANSFER_DONE;
+ }
+}
diff --git a/CMSIS/DoxyGen/General/general.dxy b/CMSIS/DoxyGen/General/general.dxy
index 801a628d6b..92c6e8de0c 100644
--- a/CMSIS/DoxyGen/General/general.dxy
+++ b/CMSIS/DoxyGen/General/general.dxy
@@ -38,7 +38,7 @@ PROJECT_NAME = CMSIS
# could be handy for archiving the generated documentation or if some version
# control system is used.
-PROJECT_NUMBER = "Version 5.0.1"
+PROJECT_NUMBER = "Version 5.1.0"
# Using the PROJECT_BRIEF tag one can provide an optional one line description
# for a project that appears at the top of each page and should give viewer a
diff --git a/CMSIS/DoxyGen/General/src/introduction.txt b/CMSIS/DoxyGen/General/src/introduction.txt
index 8b15df8184..b2f2d84faa 100644
--- a/CMSIS/DoxyGen/General/src/introduction.txt
+++ b/CMSIS/DoxyGen/General/src/introduction.txt
@@ -19,9 +19,11 @@ including CMSIS-CORE: API for the Cortex-M processor core and peripherals.
+ - CMSIS-Core (Cortex-M): API for the Cortex-M processor core and peripherals.
It provides a standardized interface for Cortex-M0, Cortex-M0+, Cortex-M3, Cortex-M4, Cortex-M7, Cortex-M23, Cortex-M33, SC000, and SC300.
Also included are SIMD intrinsic functions for Cortex-M4, Cortex-M7, and Cortex-M33 SIMD instructions.
+
+ - CMSIS-Core (Cortex-A): API and basic run-time system for the Cortex-A5/A7/A9 processor core and peripherals.
- CMSIS-Driver: defines generic peripheral driver interfaces for middleware making it reusable across supported devices. The API is RTOS independent
and connects microcontroller peripherals with middleware that implements for example communication stacks, file systems, or graphic user interfaces.
@@ -45,6 +47,9 @@ The CMSIS components are:
- CMSIS-DAP: Debug Access Port. Standardized firmware for a Debug Unit that connects to the CoreSight Debug Access Port. CMSIS-DAP is distributed as a separate package and is
well suited for integration on evaluation boards. This component is provided as separate download.
+
+ - CMSIS-Zone: System resource definition and partitioning. Defines methods to describe system resources and to partition
+ these resources into multiple projects and execution areas.
\note Refer to \ref CM_Pack_Content for more information on the content of the Software Pack.
@@ -63,7 +68,8 @@ In detail the benefits of the CMSIS are:
- Provides interfaces for debug connectivity, debug peripheral views, software delivery, and device support to reduce time-to-market for new microcontroller deployment.
- Provides a compiler independent layer that allows using different compilers. CMSIS is supported by mainstream compilers.
- Enhances program debugging with peripheral information for debuggers and ITM channels for printf-style output and RTOS kernel awareness.
- - CMSIS is delivered in CMSIS-Pack format which enables fast software delivery, simplifies updates, and enables consistent integration into development tools.
+ - CMSIS is delivered in CMSIS-Pack format which enables fast software delivery, simplifies updates, and enables consistent integration into development tools.
+ - CMSIS-Zone will simplify system resource and partitioning as it manages the configuration of multiple processors, memory areas, and peripherals.
\section CodingRules Coding Rules
@@ -144,11 +150,12 @@ CMSIS Directory
Directory |Content
:-------------------------|:----------------------------------------------------------------------------------------------------------------------------------------
\b Documentation |This documentation
-\b Core |User code templates for Core related files, referenced in ARM.CMSIS.PDSC
+\b Core |User code templates for CMSIS-Core (Cortex-M) related files, referenced in ARM.CMSIS.PDSC
+\b Core_A |User code templates for CMSIS-Core (Cortex-A) related files, referenced in ARM.CMSIS.PDSC
\b DAP |CMSIS-DAP Debug Access Port source code and reference implementations
\b Driver |Header files for the CMSIS-Driver peripheral interface API
\b DSP_Lib |CMSIS-DSP software library source code
-\b Include |Include files for CMSIS-CORE and CMSIS-DSP
+\b Include |Include files for CMSIS-Core (Cortex-M) and CMSIS-DSP
\b Lib |CMSIS-DSP generated libraries for ARMCC and GCC
\b Pack |CMSIS-Pack example
\b RTOS |CMSIS-RTOS Version 1 along with RTX reference implementation
@@ -167,22 +174,36 @@ Directory |Content
The following table shows the overall high-level history of the various CMSIS releases.
In addition, each CMSIS component has its own release history:
-- CORE Revision History
-- DAP Revision History
+- CMSIS-Core (Cortex-M) Revision History
+- CMSIS-Core (Cortex-A) Revision History
- Driver Revision History
- DSP Revision History (Change Log)
-- Pack Revision History
- RTOS v1 Revision History
- RTOS v2 Revision History
+- Pack Revision History
- SVD Revision History
-
-
+- DAP Revision History
+- Zone Revision History
Version
Description
+
+
5.1.0
+
+ - CMSIS-Core (Cortex-M) 5.0.2 several minor corrections and enhancements
+ - CMSIS-Core (Cortex-A) 1.0.0 implements a basic run-time system for Cortex-A5/A7/A9
+ - CMSIS-Driver 2.05 status typedef made volatile
+ - CMSIS-DSP 1.5.2 fixed GNU Compiler specific diagnostics
+ - CMSIS-RTOS 2.1.1 added support for Cortex-A5/A7/A9 to RTX5
+ - CMSIS-PACK 1.5.0 added SDF format specification
+ - CMSIS-SVD 1.3.3 (unchanged)
+ - CMSIS-DAP 1.1.0 (unchanged)
+ - CMSIS-Zone 0.0.1 (Preview) format to describe system resources and tool for partitioning of resources
+
+
5.0.1
@@ -194,11 +215,12 @@ In addition, each CMSIS component has its own release history:
- CMSIS-SVD 1.3.3 (unchanged)
- CMSIS-DAP 1.1.0 (unchanged)
-
+
+
5.0.0
Added support for: ARMv8-M architecture including TrustZone for ARMv8-M and Cortex-M23, Cortex-M33 processors
- - CMSIS-CORE 5.0.0 added support for ARMv8-M and Cortex-M23, Cortex-M33 processors
+ - CMSIS-Core (Cortex-M) 5.0.0 added support for ARMv8-M and Cortex-M23, Cortex-M33 processors
- CMSIS-Driver 2.04.0 (unchanged)
- CMSIS-DSP 1.4.9 minor corrections and performance improvements
- CMSIS-RTOS 2.0.0 new API with RTX 5.0.0 reference implementation and corrections in RTX 4.8.2
@@ -212,7 +234,7 @@ In addition, each CMSIS component has its own release history:
Maintenance release that is fixing defects. See component's revision history for more details.
See component's revision history for more details.
- - CMSIS-CORE 4.30.0
+ - CMSIS-Core (Cortex-M) 4.30.0
- CMSIS-DAP 1.1.0 (unchanged)
- CMSIS-Driver 2.04.0
- CMSIS-DSP 1.4.7
@@ -226,7 +248,7 @@ In addition, each CMSIS component has its own release history:
Feature release adding CMSIS-DAP (see extended End User Licence Agreement) and CMSIS-Driver for CAN.
See component's revision history for more details.
- - CMSIS-CORE 4.20.0
+ - CMSIS-Core (Cortex-M) 4.20.0
- CMSIS-DAP 1.1.0
- CMSIS-Driver 2.03.0
- CMSIS-DSP 1.4.5 (unchanged)
@@ -239,7 +261,7 @@ In addition, each CMSIS component has its own release history:
4.3.0
Maintenance release adding SAI CMSIS-Driver and fixing defects. See component's revision history for more details.
- - CMSIS-CORE 4.10.0
+ - CMSIS-Core (Cortex-M) 4.10.0
- CMSIS-Driver 2.02.0
- CMSIS-DSP 1.4.5
- CMSIS-RTOS RTX 4.78.0
@@ -298,7 +320,7 @@ In addition, each CMSIS component has its own release history:
1.00
-
Initial release of CMSIS-CORE for Cortex-M3 processor
+
Initial release of CMSIS-Core (Cortex-M) for Cortex-M3 processor
diff --git a/CMSIS/DoxyGen/Pack/Pack.dxy b/CMSIS/DoxyGen/Pack/Pack.dxy
index b6bcbacab0..9967ab432b 100644
--- a/CMSIS/DoxyGen/Pack/Pack.dxy
+++ b/CMSIS/DoxyGen/Pack/Pack.dxy
@@ -38,7 +38,7 @@ PROJECT_NAME = CMSIS-Pack
# could be handy for archiving the generated documentation or if some version
# control system is used.
-PROJECT_NUMBER = "Version 1.4.9"
+PROJECT_NUMBER = "Version 1.5.0"
# Using the PROJECT_BRIEF tag one can provide an optional one line description
# for a project that appears at the top of each page and should give viewer a
@@ -775,6 +775,7 @@ INPUT = . \
src/generators_schema.txt \
src/xml_types.txt \
src/cpdsc_schema.txt \
+ src/sdf_schema.txt \
src/pack_index.txt
# This tag can be used to specify the character encoding of the source files
diff --git a/CMSIS/DoxyGen/Pack/src/General.txt b/CMSIS/DoxyGen/Pack/src/General.txt
index f8a7de9ef2..d127a766a7 100644
--- a/CMSIS/DoxyGen/Pack/src/General.txt
+++ b/CMSIS/DoxyGen/Pack/src/General.txt
@@ -74,6 +74,13 @@ Files relevant to CMSIS-Pack are present in the following \b ARM::CMSIS director
Version
Description
+
+
1.5.0
+
Modifications compared to Version 1.4.9
+- added \ref sdf_pg
+- updates to \ref DeviceVendorEnum "Device Vendor"
+
+
1.4.9
Modifications compared to Version 1.4.8
diff --git a/CMSIS/DoxyGen/Pack/src/components_schema.txt b/CMSIS/DoxyGen/Pack/src/components_schema.txt
index 942e6966fe..e5c06eab70 100644
--- a/CMSIS/DoxyGen/Pack/src/components_schema.txt
+++ b/CMSIS/DoxyGen/Pack/src/components_schema.txt
@@ -17,8 +17,8 @@ not used by multiple components.
...
-
- CMSIS-CORE for Cortex-M, SC000, and SC300 processor.
+
+ CMSIS-Core (Cortex-M) for Cortex-M, SC000, and SC300 processor.
diff --git a/CMSIS/DoxyGen/Pack/src/conditions_schema.txt b/CMSIS/DoxyGen/Pack/src/conditions_schema.txt
index 00cdaa0651..4d8fd81fd8 100644
--- a/CMSIS/DoxyGen/Pack/src/conditions_schema.txt
+++ b/CMSIS/DoxyGen/Pack/src/conditions_schema.txt
@@ -31,15 +31,15 @@ be ignored.
-
+ True if the component Device Startup is selected and the device has a Cortex-M processor
- True if CMSIS-CORE == TRUE and either GCC or ARMCC and device running in little-endian byte ordering
-
+ True if CMSIS-Core == TRUE and either GCC or ARMCC and device running in little-endian byte ordering
+
diff --git a/CMSIS/DoxyGen/Pack/src/cpdsc_schema.txt b/CMSIS/DoxyGen/Pack/src/cpdsc_schema.txt
index 01b6916705..5aee870ec4 100644
--- a/CMSIS/DoxyGen/Pack/src/cpdsc_schema.txt
+++ b/CMSIS/DoxyGen/Pack/src/cpdsc_schema.txt
@@ -48,7 +48,7 @@ is allowed. A CPDSC file can describe one or more projects.
RestrictedString
-
optional
+
required for all multi-core devices
Punits
Specifies the number of processor units in a symmetric multi-processor core (MPCore). Defaults to single-core CPU (\token{1}) when left empty.
InstancesType
-
optional
+
required for all multi-core devices
Dcore
Specifies the processor core. Use predefined values as listed in the table \ref DcoreEnum "Device Cores".
DcoreEnum
-
optional
+
required
Dfpu
Specifies whether a hardware Floating Point Unit is present in the processor. Use predefined values as listed in the table \ref DfpuEnum "Device FPU".
DfpuEnum
-
optional
+
required
Dmpu
Specifies whether a Memory Protection Unit is present in the processor. Use predefined values as listed in the table \ref DmpuEnum "Device MPU".
DmpuEnum
-
optional
+
required
Dtz
-
Specifies whether an ARMv8M based device implements TrustZone. Use predefined values as listed in the table \ref DtzEnum "Device TZ".
+
Specifies whether an ARMv8-M based device implements TrustZone. Use predefined values as listed in the table \ref DtzEnum "Device TZ".
DtzEnum
-
optional
+
required for ARMv8-M based devices
Ddsp
-
Specifies whether an ARMv8M based device supports the DSP instructions set. Use predefined values as listed in the table \ref DdspEnum "Device DSP".
+
Specifies whether a device supports the DSP instructions set. Use predefined values as listed in the table \ref DdspEnum "Device DSP".
DdspEnum
-
optional
+
required
Dendian
Specifies the endianess of the processor. Use predefined values as listed in the table \ref DendianEnum "Endinaness".
DendianEnum
-
optional
+
required
Dclock
Specifies the max clock frequency of the processor subsystem
xs:unsignedInt
-
optional
+
required
DcoreVersion
@@ -1551,6 +1554,11 @@ all processors, no processor must be specified in \elem{Pname}.
+\note While the different attributes can be spreaded over the family levels, they add-up and at the leaf (device level), a
+complete set of attributes should be present (at least Dcore, Dfpu, Dmpu, Ddsp, Dendian, Dclock, and DcoreVersion). Adding-up
+means that you can overwrite previous attributes on the next level. For example, if you have a subFamily that has a general
+Dclock of 50000000 (50 Mhz), you can still specify for one of the subFamily members a different Dclock (such as 66000000).
+
\anchor DeviceVendorEnum Table: Device Vendors
@@ -1596,14 +1604,19 @@ Contact cmsis@arm.com to ask for an extension. These values can be used in the e
ARM Ltd.
http://www.arm.com
+
+
ArteryTek:143
+
ArteryTek
+
http://www.arterytek.com
+
Atmel:3
-
Atmel Corporation
+
Atmel Corporation (now Microchip)
http://www.atmel.com
CSR:118
-
CSR:
+
CSR
http://www.csr.com
@@ -1631,6 +1644,11 @@ Contact cmsis@arm.com to ask for an extension. These values can be used in the e
GigaDevice
http://www.gigadevice.com
+
+
HDSC:145
+
HUADA Semiconductor
+
http://www.hdsc.com.cn
+
Holtek:106
Holtek Microelectronics
@@ -1666,6 +1684,11 @@ Contact cmsis@arm.com to ask for an extension. These values can be used in the e
MegaChips
http://www.megachips.com
+
+
Microchip:3
+
Microchip (previously Atmel)
+
http://www.microchip.com
+
MicroSemi:112
Microsemi
@@ -1696,6 +1719,11 @@ Contact cmsis@arm.com to ask for an extension. These values can be used in the e
NXP
http://www.nxp.com
+
+
ONSemiconductor:141
+
ON Semiconductor
+
http://www.onsemi.com
+
Panasonic:131
Panasonic
@@ -1711,6 +1739,11 @@ Contact cmsis@arm.com to ask for an extension. These values can be used in the e
Repine Signals
http://www.redpinesignals.com
+
+
RelChip:146
+
RelChip
+
http://www.relchip.com/
+
Renesas:117
Renesas
@@ -1746,6 +1779,11 @@ Contact cmsis@arm.com to ask for an extension. These values can be used in the e
STMicroelectronics
http://www.st.com
+
+
Synwit:144
+
Synwit Technology Co.,LTD.
+
http://www.synwit.cn
+
Texas Instruments:16
Texas Instruments
@@ -1761,6 +1799,11 @@ Contact cmsis@arm.com to ask for an extension. These values can be used in the e
Triad Semiconductor
http://www.triadsemi.com
+
+
Vorago:137
+
Vorago Technologies
+
http://www.voragotech.com
+
WIZnet:122
WIZnet
@@ -1793,7 +1836,7 @@ The table lists the predefined Flash algorithm style. These values can be used i
@@ -3903,12 +3946,28 @@ Describes a patch a debugger shall apply when reading data from the device.
\b Example
\code
-
+
...
-
- ...
-
- ...
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
...
diff --git a/CMSIS/DoxyGen/Pack/src/examples_schema.txt b/CMSIS/DoxyGen/Pack/src/examples_schema.txt
index cabbcc812d..a24d3005dd 100644
--- a/CMSIS/DoxyGen/Pack/src/examples_schema.txt
+++ b/CMSIS/DoxyGen/Pack/src/examples_schema.txt
@@ -19,7 +19,7 @@ Each example can specify attributes listing related components using Class (Ccla
-
+ BlinkyGetting Started
@@ -314,7 +314,7 @@ The environment element describes the name of the environment and the project fi
Example ProjectFor a specific board
...
-
+
...
Blinky
@@ -371,7 +371,7 @@ This can be used to list all related components within an example.
\code
...
-
+
...
diff --git a/CMSIS/DoxyGen/Pack/src/flash_algorithms.txt b/CMSIS/DoxyGen/Pack/src/flash_algorithms.txt
index 3894d5a362..8f2e89958f 100644
--- a/CMSIS/DoxyGen/Pack/src/flash_algorithms.txt
+++ b/CMSIS/DoxyGen/Pack/src/flash_algorithms.txt
@@ -1,8 +1,6 @@
/**************************************************************************************************/
/**
-\page flashAlgorithm Flash Programming Algorithms
-
-[TOC]
+\page flashAlgorithm Flash Programming
Flash Programming Algorithms are a piece of software to erase or download applications to Flash devices. A \ref createPack_DFP
usually contains predefined Flash algorithms for programming the devices that are supported by the DFP. A template for
@@ -123,6 +121,20 @@ Function Name |Indication |Description
\ref UnInit |mandatory |De-initialize the microcontroller after one of the Flash programming steps.
\ref Verify |optional |Compare Flash memory content with the program code.
+The following diagrams show how the functions of the Flash Programming Algorithms are executed by a development tool.
+
+The Flash Erase sequence is executed to erase the Flash content.
+
+\image html FlashErase.png "Flash Erase"
+
+The Flash Program sequence is executed to program the Flash memory.
+
+\image html FlashProgram.png "Flash Program"
+
+The Flash Verify sequence is executed to verify the content after flash programming.
+
+\image html FlashVerify.png "Flash Verify"
+
diff --git a/CMSIS/DoxyGen/Pack/src/generators_schema.txt b/CMSIS/DoxyGen/Pack/src/generators_schema.txt
index 154eafe832..05b91485e0 100644
--- a/CMSIS/DoxyGen/Pack/src/generators_schema.txt
+++ b/CMSIS/DoxyGen/Pack/src/generators_schema.txt
@@ -79,9 +79,9 @@ generated and included and maintained as part of the project.
- Condition to include CMSIS core and Device Startup components
+ Condition to include CMSIS-Core (Cortex-M) and Device Startup components
-
+
diff --git a/CMSIS/DoxyGen/Pack/src/images/DebugConnect.vsd b/CMSIS/DoxyGen/Pack/src/images/DebugConnect.vsd
index 6281562a42..f6a775d328 100644
Binary files a/CMSIS/DoxyGen/Pack/src/images/DebugConnect.vsd and b/CMSIS/DoxyGen/Pack/src/images/DebugConnect.vsd differ
diff --git a/CMSIS/DoxyGen/Pack/src/images/DebugDisconnect.vsd b/CMSIS/DoxyGen/Pack/src/images/DebugDisconnect.vsd
index 33fe05e56a..f60e53e6f7 100644
Binary files a/CMSIS/DoxyGen/Pack/src/images/DebugDisconnect.vsd and b/CMSIS/DoxyGen/Pack/src/images/DebugDisconnect.vsd differ
diff --git a/CMSIS/DoxyGen/Pack/src/images/FlashDownload.vsd b/CMSIS/DoxyGen/Pack/src/images/FlashDownload.vsd
new file mode 100644
index 0000000000..0485d1b122
Binary files /dev/null and b/CMSIS/DoxyGen/Pack/src/images/FlashDownload.vsd differ
diff --git a/CMSIS/DoxyGen/Pack/src/images/FlashErase.png b/CMSIS/DoxyGen/Pack/src/images/FlashErase.png
new file mode 100644
index 0000000000..61980451ed
Binary files /dev/null and b/CMSIS/DoxyGen/Pack/src/images/FlashErase.png differ
diff --git a/CMSIS/DoxyGen/Pack/src/images/FlashProgram.png b/CMSIS/DoxyGen/Pack/src/images/FlashProgram.png
new file mode 100644
index 0000000000..da7d37deae
Binary files /dev/null and b/CMSIS/DoxyGen/Pack/src/images/FlashProgram.png differ
diff --git a/CMSIS/DoxyGen/Pack/src/images/FlashVerify.png b/CMSIS/DoxyGen/Pack/src/images/FlashVerify.png
new file mode 100644
index 0000000000..3dc1955ec5
Binary files /dev/null and b/CMSIS/DoxyGen/Pack/src/images/FlashVerify.png differ
diff --git a/CMSIS/DoxyGen/Pack/src/images/Reset.vsd b/CMSIS/DoxyGen/Pack/src/images/Reset.vsd
index 80d22cf13c..a9a9909e8d 100644
Binary files a/CMSIS/DoxyGen/Pack/src/images/Reset.vsd and b/CMSIS/DoxyGen/Pack/src/images/Reset.vsd differ
diff --git a/CMSIS/DoxyGen/Pack/src/pack_dfp.txt b/CMSIS/DoxyGen/Pack/src/pack_dfp.txt
index 89c48bd4ff..927ed0ae52 100644
--- a/CMSIS/DoxyGen/Pack/src/pack_dfp.txt
+++ b/CMSIS/DoxyGen/Pack/src/pack_dfp.txt
@@ -125,7 +125,7 @@ further details. Afterwards, install the Pack in your development tool.
We will address this problem in the next section.
\section cp_System_Startp System and Startup Files
-CMSIS-CORE defines the following files to be used by
+CMSIS-Core (Cortex-M) defines the following files to be used by
an embedded application:
- \c startup_.s with reset handler and exception vectors. It is executed after reset and calls \c SystemInit and may
contain stack and heap configurations for the user application.
@@ -136,7 +136,7 @@ an embedded application:
\image html SystemStartupFiles.png "System and startup files in relation to user code"
-\note CMSIS-CORE
+\note CMSIS-Core (Cortex-M)
explains the structure of the system and startup files and how to create them.
Copy the \e content of the 02_System_and_Startup directory of the \b Pack_with_Device_Support.zip file to the
@@ -146,10 +146,10 @@ Copy the \e content of the 02_System_and_Startup directory of the \b Pack
Add a \c \ section in your PDSC with the following (the \ref cp_Conditions "conditions" section
provides more information on this step):
\code{.xml}
-
+
- MyVendor MVCM3 Series devices and CMSIS-CORE
-
+ MyVendor MVCM3 Series devices and CMSIS-Core (Cortex-M)
+
@@ -172,7 +172,7 @@ provides more information on this step):
Add a \c \ section in your PDSC with the following (the \ref cp_Components "components" section
provides more information on this step):
\code
-
+ System Startup for MyVendor MVCM3 Series
@@ -465,7 +465,7 @@ Finally, \ref cp_Components "software components" and \ref cp_Examples "example
Add the following lines to the PDSC file in the \elem{components} section:
\code
-
+GPIO HAL for MyVendor MVCM3 Series
@@ -473,7 +473,7 @@ Add the following lines to the PDSC file in the \elem{components} section:
-
+ADC HAL for MyVendor MVCM3 Series
@@ -481,7 +481,7 @@ Add the following lines to the PDSC file in the \elem{components} section:
-
+I2C Driver for MVCM3 Series
#define RTE_Drivers_I2C0 /* Driver I2C0 */
@@ -494,7 +494,7 @@ Add the following lines to the PDSC file in the \elem{components} section:
-
+UART Driver for MVCM3 Series
#define RTE_Drivers_UART0 /* Driver UART0 */
diff --git a/CMSIS/DoxyGen/Pack/src/pack_example.txt b/CMSIS/DoxyGen/Pack/src/pack_example.txt
index d286324de3..ee26c7efe0 100644
--- a/CMSIS/DoxyGen/Pack/src/pack_example.txt
+++ b/CMSIS/DoxyGen/Pack/src/pack_example.txt
@@ -14,7 +14,7 @@ sub-directories:
|-----------------------------------|-------------------------------------------------------------------------------------------|------------------------------------|
|\b Boards |CMSIS-RTOS Blinky uVision project running on the MCB1800 development board |\ref pdsc_examples_pg "" |
|\ref PE_CMSIS_Driver "CMSIS_Driver"|CMSIS-Driver compliant peripheral drivers|\ref element_component ""|
-|\ref PE_Device "Device" |CMSIS-CORE files for LPC1800 series |\ref element_device "" |
+|\ref PE_Device "Device" |CMSIS-Core (Cortex-M) files for LPC1800 series |\ref element_device "" |
|\ref PE_Documents "Documents" |Documentation for devices and boards |\ref element_book "" |
|\b Flash |\ref flashAlgorithm and a sub-directory called \b LPC18xx43xx_IAP containing a uVision project for IAP (In-Application Programming) support|\ref element_algorithm ""|
|\b Images |Images of the MCB1800 development board |\ref pdsc_boards_pg "" |
diff --git a/CMSIS/DoxyGen/Pack/src/pack_swcomponents.txt b/CMSIS/DoxyGen/Pack/src/pack_swcomponents.txt
index 0b8ad6eb95..dc94ddeca6 100644
--- a/CMSIS/DoxyGen/Pack/src/pack_swcomponents.txt
+++ b/CMSIS/DoxyGen/Pack/src/pack_swcomponents.txt
@@ -269,7 +269,7 @@ Add a \ref pdsc_conditions_pg "" section with the following:
-
+
@@ -544,7 +544,7 @@ Add an \ref pdsc_examples_pg "" section with the following:
-
+
diff --git a/CMSIS/DoxyGen/Pack/src/pdsc_format.txt b/CMSIS/DoxyGen/Pack/src/pdsc_format.txt
index 94f60e5ddb..2b9becabcc 100644
--- a/CMSIS/DoxyGen/Pack/src/pdsc_format.txt
+++ b/CMSIS/DoxyGen/Pack/src/pdsc_format.txt
@@ -815,7 +815,7 @@ needs to be the same as specified in the element \ref element_generator. The des
the opening and closing tags of the element \b description.
It is recommended to use an already agreed taxonomy for interchangeable components. For example, the combination of class \token{CMSIS}
-and group \token{Startup} is defined for the device-specific CMSIS-CORE files.
+and group \token{Startup} is defined for the device-specific CMSIS-Core (Cortex-M) files.
@@ -928,7 +928,7 @@ The table lists predefined Component Classes.
Components providing interfaces for Evaluation and Development Boards
CMSIS
-
Components defined by Cortex Microcontroller Software Interface Standard (e.g. CMSIS-CORE, CMSIS-DSP and CMSIS-RTOS)
@@ -996,8 +996,8 @@ No other Component Groups have been defined so far.
Description
-
CORE
-
A component containing device support in accordance to the CMSIS-CORE specification (startup, system and device files)
+
Core
+
A component containing device support in accordance to the CMSIS-Core (Cortex-M) specification (startup, system and device files)
DSP
diff --git a/CMSIS/DoxyGen/Pack/src/sdf_schema.txt b/CMSIS/DoxyGen/Pack/src/sdf_schema.txt
new file mode 100644
index 0000000000..6b3d1c1a02
--- /dev/null
+++ b/CMSIS/DoxyGen/Pack/src/sdf_schema.txt
@@ -0,0 +1,1238 @@
+/**
+\page sdf_pg System Description File (*.SDF) Format
+
+An SDF file enables the silicon provider to describe more complex debug topologies than with a \ref debug_description in a
+tool agnostic way. Multiple debug and access ports and the setup of the different debug/trace components can be described
+consistently. Also, mandatory settings for a debugger can be described, such as trace signal delay settings,
+availability/usability of certain reset methods or timings, etc. This information is used by the debugger to access the right
+components that are requested by the user or application. The SDF format provides the XML elements for defining the debug
+system view of a device. These are "expert" settings that cannot be specified in a PDSC file.
+
+\note SDF files are referenced in a PDSC file via the \c \ element.
+
+Example CMSIS System Description File (*.SDF)
+\code
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 0x0BA01477
+
+
+
+
+
+ 0
+
+
+ AHB-AP
+ 0xE00FF000
+
+
+
+
+
+
+ 0xE000E000
+ 0
+
+
+
+
+ 0xE0001000
+ 0
+
+
+
+
+ 0xE0002000
+ 0
+
+
+
+
+
+
+
+
+ 0x4BA00477
+
+
+
+
+
+ 0
+
+
+ AHB-AP
+ 0xE00FF000
+
+
+
+
+
+
+ 0xE000E000
+ 0
+
+
+
+
+ 0xE0001000
+ 0
+
+
+
+
+ 0xE0002000
+ 0
+
+
+
+
+ 0xE0000000
+ 0
+
+
+
+
+ V7-M
+ CONTINUOUS
+ 1;2;4
+
+
+ 0xE0040000
+ 0
+
+
+
+
+ 3.5
+ true
+
+
+ 0xE0041000
+ 0
+
+
+
+
+ 32
+ 0x4000
+
+
+ 0xE0042000
+ 0
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+\endcode
+
+
+\section sdf_structure SDF top level structure
+
+The XML schema file sdf_schema.xsd defines the sections used in a *.SDF file. The current sdf_schema.xsd
+can be found under the ARM.CMSIS.*.Pack in the .\\CMSIS\\Utilities-directory.
+
+\section element_system_description /system_description
+
+
+
Parents
+
Element Chain
+
+
+
root
+
description root point for SDF
+
+
+
Attributes
+
Description
+
Type
+
Use
+
+
+
schemaVersion
+
Version of sdf_schema.xsd the description is compatible with
+
xs:decimal
+
required
+
+
+
Child Elements
+
Description
+
Type
+
Occurrence
+
+
+
\refelem{debug_and_trace_config}
+
Description how to configure debug and trace.
+
complexType
+
1..1
+
+
+
\refelem{platform}
+
Overall platform description.
+
complexType
+
1..1
+
+
+
+\delim
+
+\section element_debug_and_trace_config /system_description/debug_and_trace_config
+
+Describes the recommended debug and trace configuration for the device.
+
+
Describes a configuration item attribute/value pair
+
xs:string
+
0..*
+
+
+
+For a list of applicable configuration items, refer to \ref element_config_item "config_item".
+\delim
+
+\section element_config_item /system_description/.../config_item
+
+A config_item can appear in various SDF elements. This group contains individual configuration items.
+
+
+
+Debug element
+-------------
+
+The \b config_items applicable to the \ref element_debug "debug" element are the following:
+
+| Item | Description |
+|------------------------|-------------|
+| TRSTOnConnect | Debugger should perform TAP reset on connect (True/False) - Default Value:True |
+| SRSTOnConnect | Debugger should perform a System reset on connect (True/False) - Default Value:False |
+| AllowTRST | Allow the Debugger to perform TAP reset (True/False) - Default Value:True |
+| DoSoftTRST | Debugger should perform a Soft Reset (True/False) - Default Value:True |
+| TRSTHoldTime | TAP reset hold time in milliseconds - Default Value:10 |
+| TRSTPostResetTime | Delay after TAP reset before next operation - Default Value:10 |
+| ResetHoldTime | Time in milliseconds that the target is held in a hardware reset state - Default Value:100 |
+| PostResetDelay | Time in milliseconds that the target will wait after reset is released before attempting any other debugging operations - Default Value:10 |
+| Linked_SRST_TRST | Target hardware has System Reset and TAP reset physically linked (True/False) - Default Value:False|
+
+Device element
+--------------
+
+The \b config_items applicable to the \ref element_device "device" element are the following (only applicable for devices
+that are child elements of another device or DAP):
+
+| Item | Description | Use |
+|------------------------|-------------|-----|
+| CORESIGHT_BASE_ADDRESS | the 4K aligned base address of a CoreSight device | Required |
+| CORESIGHT_AP_INDEX | the access port index of the device | Required |
+
+Trace element
+-----------
+
+The \b config_items applicable to the \ref element_trace "trace" element are the following:
+-# Parallel trace capture device configuration items ("type" = "parallel"). These "config_items" enable you to configure
+ delays on the trace lines by a specified amount of time relative to the trace capture device defaults. These delays are
+ used to allow for variations in target hardware. These configuration items have default values if not present.
+ | Item | Description | Default |
+ |------------------------|-------------|----------|
+ | CLOCK_EDGE | Set to 0 or 1 to specify the clock edge on which to capture data | 1 |
+ | DELAY_TRACE_CLOCK | Adjust the sampling point for the trace clock by the specified number of picoseconds | 0 |
+ | DELAY_TRACE_SIGNAL_1 to DELAY_TRACE_SIGNAL_n | Adjust the sampling point for parallel trace signal 'n' by the specified number of picoseconds | 0 |
+
+-# High-speed serial trace configuration items ("type"="HSSTP"). These configuration items do not have any default values. If
+ they are not present in the SDF file then HSSTP trace is not supported by the target.
+ | Item | Description |
+ |------------------------|-------------|
+ | HSSTP_LANES | The number of lanes (1-6) |
+ | HSSTP_SPEED | The HSSTP link speed (HSSTP_2_5Gbps, , HSSTP_3_0Gbps, HSSTP_3_125Gbps, HSSTP_4_25Gbps, HSSTP_5_0Gbps, HSSTP_6_0Gbps, HSSTP_6_25Gbps, HSSTP_8_0Gbps, HSSTP_10_0Gbps, HSSTP_10_3125Gbps, HSSTP_12_0Gbps, HSSTP_12_5Gbps, HSSTP_SETM_1_5Gbps, HSSTP_SETM_3_0Gbps, HSSTP_SETM_6_0Gbps)
+ | HSSTP_PROTOCOL | The HSSTP protocol (HSSTP_PROTOCOL_ARM_HSSTP, HSSTP_PROTOCOL_8_BIT_SETM, HSSTP_PROTOCOL_16_BIT_SETM, HSSTP_PROTOCOL_32_BIT_SETM)
+ | HSSTP_NDALT | Reverse byte bit-ordering (HSSTP_NDALT_Disabled/HSSTP_NDALT_Enabled) |
+ | HSSTP_CONNECTOR | The physical connector type (HSSTP_CONNECTOR_HSSTP/HSSTP_CONNECTOR_SMA) |
+ | HSSTP_RX_EQUALIZATION | The RX equalization type (RX_EQUALIZATION_DFE/RX_EQUALIZATION_LPM) |
+ | HSSTP_CRC | The type of CRC to use (HSSTP_CRC_Enabled, HSSTP_CRC_Disabled, HSSTP_CRC_Reversed, HSSTP_CRC_Ignored) |
+
+\b Example
+
+\code
+...
+
+
+ 3.5
+ true
+
+
+ 0xE0041000
+ 0
+
+
+...
+\endcode
+\delim
+
+\section element_trace /system_description/debug_and_trace_config/trace
+
+Describes the recommended trace configuration for the device.
+
+
Lists all DAPs/Devices in the order that they appear on the scanchain (Note - order is reverse to DAP references in PDSC files). The first device in the scanchain is one closest to target's TDI pin.
+
complexType
+
0..*
+
+
+
\refelem{topology}
+
Describes the system topology
+
complexType
+
0..1
+
+
+
\refelem{clusters}
+
Describes the cluster arrangement
+
complexType
+
0..1
+
+
+
+\delim
+
+\section element_scanchain /system_description/platform/scanchain
+
+Lists all DAPs/devices in the order that they appear on the scanchain.
+
+\note The order is reverse to the DAP references in PDSC files. The first device in the scanchain is the one closest to the
+target's TDI pin.
+
+
Contains implementation details for the DAP. Applicable items for a DAP are "JTAG_IDCODE" (the JTAG ID code for the
+ DAP) or "DPIDR" (the Debug Port Identification Register contents).
+
complexType
+
0..*
+
+
+
\refelem{config_items}
+
Configuration items specific to a DAP type.
+
complexType
+
0..*
+
+
+
Attributes
+
Description
+
Type
+
Use
+
+
+
name
+
Unique name of the DAP.
+
xs:string
+
required
+
+
+
type
+
Specifies the type of the DAP (e.g. ARMCS-DP).
+
xs:string
+
required
+
+
+
irLength
+
Specifies the IR length of the DAP (default value: 4).
+
xs:string
+
optional
+
+
+
protocol
+
Colon delimited list of protocols via which the DAP can be use. Possible values are SWD, JTAG, and cJTAG.
+
xs:string
+
optional
+
+
+
targetsel
+
Specifies the SW-DPv2 TARGETSEL register value that selects this DAP in a serial-wire debug multi-drop system.
Describes a single nested device associated with this device.
+
complexType
+
0..*
+
+
+
\refelem{device_info_items}
+
Describes a sequence of device information items.
+
complexType
+
0..*
+
+
+
\refelem{config_items}
+
Configuration items specific to this device.
+
complexType
+
0..*
+
+
+
Attributes
+
Description
+
Type
+
Use
+
+
+
name
+
Unique name of the device.
+
xs:string
+
required
+
+
+
type
+
Specifies the device type (see below).
+
xs:string
+
required
+
+
+
irLength
+
Specifies the IR length of the device (default value: 4).
+
xs:string
+
optional
+
+
+
+Depending on the context, a device type can be one of the following types:
+
+-# A core device, where the type is usually specified as "Cortex-xx" (such as Cortex-A72,Cortex-M0+, Cortex-R5). It can also
+ be a vendor-specific core type, or an older JTAG ARM core. Current cores are: \n
+ "Cortex-A5", "Cortex-A7", "Cortex-A8", "Cortex-A9", "Cortex-A12", "Cortex-A15", "Cortex-A17", "Cortex-A32", "Cortex-A35",
+ "Cortex-A53", "Cortex-A57", "Cortex-A72", "Cortex-A73", "Cortex-M0", "Cortex-M0+", "Cortex-M0+_JTAG-AP", "Cortex-M1",
+ "Cortex-M23", "Cortex-M3", "Cortex-M33", "Cortex-M3_JTAG-AP", "Cortex-M4", "Cortex-M7", "Cortex-R4", "Cortex-R5",
+ "Cortex-R7", "Cortex-R8", "Cortex-R52", "SC000", "SC100D", "SC200D", "SC300", "ThunderX", "ThunderX-r2", "ARMV8MBL",
+ "ARMV8MML", "88FR101", "88FR111", "88FR331", "88SV581x-v7_PJ4", "88SV581x-v7_PJ4_TZ", "ARM1136JF-S",
+ "ARM1136JF-S_JTAG-AP", "ARM1156T2F-S", "ARM1156T2F-S_JTAG-AP", "ARM1176JZF-S", "ARM1176JZF-S_JTAG-AP", "ARM11MPCore",
+ "ARM11MPCore_JTAG-AP", "ARM710T", "ARM720T", "ARM720T_r4", "ARM740T", "ARM7EJ-S", "ARM7EJ-S_JTAG-AP", "ARM7TDMI",
+ "ARM7TDMI_JTAG-AP", "ARM7TDMI_r4", "ARM7TDMI_r4_JTAG-AP", "ARM920T", "ARM922T", "ARM925T", "ARM926EJ-S",
+ "ARM926EJ-S_JTAG-AP", "ARM940T", "ARM946E-S", "ARM946E-S_JTAG-AP", "ARM966E-S", "ARM966E-S_JTAG-AP", "ARM968E-S",
+ "ARM968E-S_JTAG-AP", "ARM968E-Srd", "ARM996HS", "ARM9E-S", "ARM9EJ-S", "ARM9EJ-S_JTAG-AP", "ARM9TDMI", "V7A-Generic",
+ "V8-Generic", "V8M-Generic", "V8R-Generic", "V8_1-Generic", "V8_2-Generic".
+-# An Access Port (AP) type such as "CSAUTHAP", "CSJTAGAP" or "CSMEMAP".
+-# A CoreSight device type that can be one of "CSCTI", "CSETM", "CSITM", "CSMTB", "CSPMU", "CSPTM", "CSTFunnel", "CSTMC",
+ "CSTPIU","CSSTM", "CSSWO", "CSELA", "CSATBReplicator", "CSGPR", "CSETB", "CSDWT", "CSETB", "CSTSGEN", "CSHTM", "CSFPB"
+-# A JTAG device, which is directly on the scanchain (e.g. ARM11).
+
+\b Example:
+
+\code
+
+
+
+
+
+
+
+
+
+
+
+ 0x04560014
+
+
+ ...
+
+\endcode
+
+\delim
+
+\section element_config_items /system_description/platform/scanchain/../../config_items
+
+The configuration items are specific to the device type or DAP. Refer to \ref element_config_item for a list of applicable
+device information items and a code example.
+
+
+
+\delim
+
+\section element_device_info_items /system_description/platform/scanchain/../../device_info_items
+
+The device information items are specific to the type of device or DAP and describe implementation specific details. Refer to
+\ref element_device_info_item for a list of applicable device information items and a code example.
+
+
+
+\delim
+
+\section element_device_info_item /system_description/platform/scanchain/../../device_info_items/device_info_item
+
+Describes implementation specific details of the specified device or DAP.
+
+
Unique name for the cluster (for example Cortex-A15_SMP_0).
+
xs:string
+
required
+
+
+
devices
+
Colon separated list of named devices in the cluster, for example "Cortex-A15_0:Cortex-A15_1:Cortex-A15_2:Cortex-A15_3".
+
xs:string
+
required
+
+
+
+\delim
+*/
diff --git a/CMSIS/DoxyGen/Pack/src/xml_types.txt b/CMSIS/DoxyGen/Pack/src/xml_types.txt
index 9db27ef62f..426b03e76d 100644
--- a/CMSIS/DoxyGen/Pack/src/xml_types.txt
+++ b/CMSIS/DoxyGen/Pack/src/xml_types.txt
@@ -1,11 +1,27 @@
/**************************************************************************************************/
/**
-\page coresight_setup Simplifying debug setup using debug descriptions
+\page coresight_setup Debug Setup with CMSIS-Pack
+
+CMSIS-Pack offers two ways to simplify the debug setup:
+- A \subpage debug_description declares a set of standardized debug and trace methods are automatically executed by the
+ debugger. Implementation-specific steps can be described using an XML syntax. This concept is easy to implement for basic
+ chip configurations that mostly rely on a standard implementation of the CoreSight architecture. Most single-core devices
+ should be able to be specified completely with debug descriptions.
+- For more complex topologies and multi-core devices, a \ref sdf_pg "System Description File" helps debuggers to connect to
+ the target and access all available cores via trace. An SDF file is more complex (although also specified in XML), but is
+ also more flexible with regards to the underlying debug architecture.
+*/
+
+
+/******************************************************************************************************************/
+/**
+\page debug_description Debug Description
Debug descriptions allow silicon vendors to create tool-agnostic debug and trace configurations so that the development
environment settings can be reduced to simple checkboxes for selecting for example either standard run/stop debugging or
complex instruction tracing.
+
\section das_concept Concept
A set of standardized debug and trace methods are automatically executed by the debugger:
@@ -34,13 +50,8 @@ A complete debug description for a device consists of the following elements:
- \refelem{trace} with the child elements \refelem{trace_serialwire}, \refelem{trace_traceport}, and
\refelem{trace_tracebuffer} sets up the trace connection.
-For more information, refer to the \subpage pdsc_SequenceNameEnum_pg.
-*/
-
-
-/******************************************************************************************************************/
-/**
-\page pdsc_SequenceNameEnum_pg Debug access sequences
+
+\section pdsc_SequenceNameEnum_pg Debug access sequences
Debug access sequences define the activities of development tools to connect to a device using the debug channel for
debugging, tracing, or flash programming. Several debug access sequences are pre-defined and executed in specific context.
@@ -475,7 +486,7 @@ Execute a system-wide reset via software mechanisms.
Execute a processor reset via software mechanisms.
-\note This Default Debug Access Sequence is empty for ARMv6-M based processors.
+\note This Default Debug Access Sequence is empty for ARMv6-M and ARMv8-M based processors.
\code
@@ -638,6 +649,159 @@ Free hardware resources allocated by ResetCatchSet.
\endcode
+\section nonstdExamples Examples of non-standard debug access sequences
+
+
+\subsection traceStart TraceStart
+
+\code
+
+
+ __var value = 0;
+
+ //Enable SWO
+ value = Read8(0x40004D2A);
+ Write8(0x40004D2A, (value | 0x20)); // Set the register
+ value = Read8(0x40004D2C);
+ Write8(0x40004D2C, (value & (~0x20))); // Clear the register
+
+
+\endcode
+
+
+\subsection debugDeviceUnlock DebugDeviceUnlock
+
+\code
+
+
+ __var DAuthUserInput = 0;
+ __var DAUTHSTATUS_Val = 0;
+ __var DHCSR_Val = 0;
+ __var SecureDebugEna = 0;
+ __var SecureDebugAvail = 0;
+ __var DAuthVal = 0;
+ __var Status = 0; // AP Status value
+
+ DAUTHSTATUS_Val = Read32(0xE000EFB8);
+ DHCSR_Val = Read32(0xE000EDF0);
+ DAP_Delay(100000);
+ SecureDebugAvail = (DAUTHSTATUS_Val & 0x00000020) ? 1 : 0; // SID: Secure Invasive Debug Implemented
+ Status = ReadAP(0x0); // Read Status register
+
+
+
+
+ SecureDebugEna = ((DHCSR_Val & 0x00100000) || ((DAUTHSTATUS_Val & 0x00000030) == 0x00000030)) ? 1 : 0;
+
+
+
+
+ // Debug Authentication as per Debug Configuration File
+ DAuthVal = DAuthConfig;
+
+
+
+
+ DAuthUserInput = Query(1, "Enable Secure Debug?", 3);
+
+
+
+ // Enable Secure Debug
+ DAuthVal = 0xF;
+
+
+
+
+ // Disable Secure Debug
+ DAuthVal = 0x3;
+
+
+
+
+
+
+ // Setup Secure Debug
+ Write32(0x50007000, DAuthVal);
+
+
+
+
+
+ Query(0, "Cannot configure Debug Authentication, secure debug disabled! Please reboot FPGA!", 1);
+
+
+
+
+
+\endcode
+
+
+\subsection hwReset User-defined hardware reset sequence
+
+\code
+
+
+ __var protType = __protocol & 0x0000FFFF;
+
+
+
+
+
+ // HW Reset Pulse
+ DAP_SWJ_Pins(0x00, 0x80, 0);
+ DAP_Delay(50000);
+ DAP_SWJ_Pins(0x80, 0x80, 0);
+
+ // Wait at least 200us
+ DAP_Delay(200);
+
+ // Register to SSW (Start-up Software) within 2ms
+
+ // JTAG Reset
+ DAP_JTAG_Sequence(6, 1, 0x7F);
+ DAP_JTAG_Sequence(1, 0, 0x01);
+
+ // Request Debug and System Power-Up
+ WriteDP(0x4, 0x50000F00);
+
+ // Init DP SELECT register
+ WriteDP(0x8, 0x00000000);
+
+ // Init AP CSW register
+ WriteAP(0x00, 0x23000052);
+
+ // Set TAR register to DHCSR address
+ WriteAP(0x4, 0xE000EDF0);
+
+ // Enable core debug (finishes tool register process)
+ WriteAP(0xC, 0xA05F0001);
+
+ // SSW will configure a HW BP0 at User Code start
+
+
+
+ ...
+
+
+\endcode
+
+
+\subsection sequenceExample Calling sequences in a control block
+
+\code
+...
+
+
+ Sequence("SecurityUnlock"); // Execute TAP Sequence according to SiliconRevision
+ Sequence("Set_JTAG_CTL");
+ Sequence("WaitIdleState");
+ Sequence("SetIDCODES");
+
+
+...
+\endcode
+
+
\section writing_sequences Writing debug access sequences
To override a default sequence or to create a custom (default) sequence, you need to write \refelem{sequence} elements. The
@@ -762,6 +926,9 @@ debug access variables which are evaluated for the function call.
Return Value:
Always returns \token{0}.
+
+ Code Example:
+ Refer to \ref sequenceExample
@@ -779,6 +946,9 @@ debug access variables which are evaluated for the function call.
Return Value:
The 8-bit value as read from target memory.
+
+ Code Example:
+ Refer to \ref traceStart
@@ -850,6 +1020,9 @@ debug access variables which are evaluated for the function call.
Return Value:
The 32-bit value as read from the AP register.
+
+ Code Example:
+ Refer to \ref debugDeviceUnlock
@@ -886,6 +1059,9 @@ debug access variables which are evaluated for the function call.
Return Value:
Always returns \token{0}.
+
+ Code Example:
+ Refer to \ref traceStart
@@ -961,6 +1137,9 @@ debug access variables which are evaluated for the function call.
Return Value:
Always returns \token{0}.
+
+ Code Example:
+ Refer to \ref hwReset
@@ -992,6 +1171,9 @@ debug access variables which are evaluated for the function call.
Return Value:
Always returns \token{0}.
+
+ Code Example:
+ Refer to \ref debugDeviceUnlock
diff --git a/CMSIS/DoxyGen/RTOS/rtos.dxy b/CMSIS/DoxyGen/RTOS/rtos.dxy
index b7fdfee909..2181308b5b 100644
--- a/CMSIS/DoxyGen/RTOS/rtos.dxy
+++ b/CMSIS/DoxyGen/RTOS/rtos.dxy
@@ -370,7 +370,7 @@ INLINE_GROUPED_CLASSES = YES
# Man pages) or section (for LaTeX and RTF).
# The default value is: NO.
-INLINE_SIMPLE_STRUCTS = NO
+INLINE_SIMPLE_STRUCTS = YES
# When TYPEDEF_HIDES_STRUCT tag is enabled, a typedef of a struct, union, or
# enum is documented as struct, union, or enum with the name of the typedef. So
diff --git a/CMSIS/DoxyGen/RTOS/src/cmsis_os.txt b/CMSIS/DoxyGen/RTOS/src/cmsis_os.txt
index 5a7060f673..35f70063b2 100644
--- a/CMSIS/DoxyGen/RTOS/src/cmsis_os.txt
+++ b/CMSIS/DoxyGen/RTOS/src/cmsis_os.txt
@@ -601,7 +601,7 @@ This RTX implementation gives therefore serious benefits to the users and the so
- The unified feature set of the CMSIS-RTOS API simplifies sharing of software components and reduces learning efforts.
- Middleware components that use the CMSIS-RTOS API are RTOS agnostic and CMSIS-RTOS compliant middleware is easier to
adapt.
- - This RTX implementation is available under the BSD license and can be freely distributed with project templates.
+ - This RTX implementation is available under the Apache-2.0 license and can be freely distributed with project templates.
The CMSIS-RTOS RTX manages the resources of the microcontroller system and implements the concept of parallel threads that
run concurrently. There are many advantages of using the CMSIS-RTOS RTX kernel.
@@ -1135,7 +1135,7 @@ The file \ref RTX_Conf_CM "RTX_Conf_CM.c" is used to define the configuration pa
part of every project that is using the CMSIS-RTOS RTX kernel.
The configuration file uses
-Configuration Wizard Annotations.
+Configuration Wizard Annotations. Refer to Pack - Configuration Wizard Annotations for details.
Depending on the development tool that is used, this might lead to a more user friendly graphical representation of the
settings. The following is a screenshot of the same configuration file using µVision's Configuration Wizard view:
@@ -2278,6 +2278,7 @@ Remove the thread function from the active thread list. If the thread is current
- \em osErrorISR: \ref osThreadTerminate cannot be called from interrupt service routines.
\note Cannot be called from \ref CMSIS_RTOS_ISR_Calls "Interrupt Service Routines".
+\note Avoid calling the function with a \em thread_id that does not exist or has been terminated already.
Code Example
\code{.c}
@@ -2884,7 +2885,7 @@ When these signal flags are already set, the function returns instantly. Otherwi
Signal flags that are reported as event are automatically cleared.
The argument \a millisec specifies how long the system waits for the specified signal flags.
-While the system waits the tread calling this function is put into the state \b WAITING.
+While the system waits the thread calling this function is put into the state \b WAITING.
The timeout value can have the following values:
- when \a millisec is 0, the function returns instantly.
- when \a millisec is set to \b osWaitForever the function will wait for an infinite time until a specified signal is set.
@@ -3506,7 +3507,7 @@ Allocate a memory block from the mail queue that is filled with the mail informa
The argument \a queue_id specifies a mail queue identifier that is obtain with \ref osMailCreate.
The argument \a millisec specifies how long the system waits for a mail slot to become available.
-While the system waits the tread calling this function is put into the state \b WAITING.
+While the system waits the thread calling this function is put into the state \b WAITING.
The \a millisec timeout can have the following values:
- when \a millisec is 0, the function returns instantly.
- when \a millisec is set to \b osWaitForever the function will wait for an infinite time until a mail slot can be allocated.
diff --git a/CMSIS/DoxyGen/RTOS2/rtos.dxy b/CMSIS/DoxyGen/RTOS2/rtos.dxy
index 424fd7a119..e83d0b6325 100644
--- a/CMSIS/DoxyGen/RTOS2/rtos.dxy
+++ b/CMSIS/DoxyGen/RTOS2/rtos.dxy
@@ -38,7 +38,7 @@ PROJECT_NAME = CMSIS-RTOS2
# could be handy for archiving the generated documentation or if some version
# control system is used.
-PROJECT_NUMBER = "Version 2.1.0"
+PROJECT_NUMBER = "Version 2.1.1"
# Using the PROJECT_BRIEF tag one can provide an optional one line description
# for a project that appears at the top of each page and should give viewer a
@@ -752,6 +752,8 @@ WARN_LOGFILE =
INPUT = . \
../../RTOS2/Include/cmsis_os2.h \
+ ../../RTOS2/Include/os_tick.h \
+ ../../RTOS2/Source/os_systick.c \
./src/cmsis_os2.txt \
./src/cmsis_os2_Kernel.txt \
./src/cmsis_os2_Thread.txt \
@@ -766,6 +768,7 @@ INPUT = . \
./src/cmsis_os2_Status.txt \
./src/cmsis_os2_Migration.txt \
./src/cmsis_os2_MigrationGuide.txt \
+ ./src/cmsis_os2_tick.txt \
../../RTOS2/RTX/Include/rtx_os.h \
../../RTOS2/RTX/Include/rtx_evr.h \
./src/rtx_evr.txt
diff --git a/CMSIS/DoxyGen/RTOS2/src/cmsis_os2.txt b/CMSIS/DoxyGen/RTOS2/src/cmsis_os2.txt
index 343699dbb5..728bb2964a 100644
--- a/CMSIS/DoxyGen/RTOS2/src/cmsis_os2.txt
+++ b/CMSIS/DoxyGen/RTOS2/src/cmsis_os2.txt
@@ -77,12 +77,19 @@ File/Folder | Content
Version
Description
+
+
V2.1.1
+
+ Additional functions allowed to be called from Interrupt Service Routines:
+ - \ref osKernelGetTickCount, \ref osKernelGetTickFreq
+
+ Changed Kernel Tick type to uint32_t:
+ - updated: \ref osKernelGetTickCount, \ref osDelayUntil
+
+
V2.1.0
- Updated configuration files: RTX_Config.h for the configuration settings and RTX_config.c for
- implementing the \ref rtx5_specific.
-
Support for critical and uncritical sections (nesting safe):
- updated: \ref osKernelLock, \ref osKernelUnlock
- added: \ref osKernelRestoreLock
@@ -112,7 +119,7 @@ File/Folder | Content
\b osKernelSysTickFrequency, \b osKernelSysTickMicroSec.\n
Removed: osSignalGet.
-
+
fv
V1.01
Added capabilities for C++, kernel initialization and object deletion.\n
@@ -146,13 +153,25 @@ File/Folder | Content
Version
Description
+
+
V5.2.0
+
+ - Based on CMSIS-RTOS API V2.1.1.
+ - Added support for for Cortex-A.
+ - Using OS Tick API for RTX Kernel Timer Tick.
+ - Fixed potential corruption of terminated threads list.
+ - Corrected MessageQueue to use actual message length (before padding).
+ - Corrected parameters for ThreadEnumerate and MessageQueueInserted events.
+ - Timer Thread creation moved to osKernelStart.
+
+
V5.1.0
- - Based on CMSIS-RTOS API V2.1.
+ - Based on CMSIS-RTOS API V2.1.0.
- Added support for Event recording.
- Added support for IAR compiler.
- - Configuration file split into .h and .c file.
+ - Updated configuration files: RTX_Config.h for the configuration settings and RTX_config.c for implementing the \ref rtx5_specific.
- osRtx name-space for RTX specific symbols.
@@ -313,7 +332,8 @@ The steps to create a microcontroller application using RTX5 are:
\b %RTX_Config.h, \b %RTX_Config.c, the library or the source code files, as well as the system and startup files:
\image html project_window.png
-
+
+- If using the Variant: \b Source as statet above, you have to assure to use at least C99 compiler mode (Project Options -> C/C++ -> C99 Mode).
- You can add template files to the project by right-clicking on Source Group 1 and selecting
Add New Item to 'Source Group 1'. In the new window, click on User Code Template. On the right-hand side
you will see all available template files for CMSIS-RTOS RTX:
@@ -322,11 +342,27 @@ The steps to create a microcontroller application using RTX5 are:
- \ref config_rtx5 "Configure" RTX5 to the application's needs using the \b %RTX_Config.h file.
+\section cre_rtx_cortexa Additional requirements for RTX on Cortex-A
+
+Cortex-A based microcontrollers are less unified with respect to the interrupt and timer implementations used compared to
+M-class devices. Thus RTX requires additional components when an A-class device is used, namely
+IRQ Controller (API) and \ref CMSIS_RTOS_TickAPI "OS Tick (API)"
+implementations.
+
+\image html manage_rte_cortex-a.png
+
+The default implementations provided along with CMSIS are
+- ARM Generic Interrupt Controller (GIC)
+- ARM Cortex-A5, Cortex-A9 Private Timer (PTIM)
+- ARM Cortex-A7 Generic Physical Timer (GTIM)
+
+For devices not implementing GIC, PTIM nor GTIM please refer to the according device family pack and select the
+proper implementations.
+
\section cre_rtx_proj_specifics Add support for RTX specific functions
If you require some of the \ref rtx5_specific "RTX specific functions" in your application code, \#include the
\ref rtx_os_h "header file rtx_os.h". This enables \ref lowPower "low-power" and \ref TickLess "tick-less" operation modes.
-
-
+
\section cre_rtx_proj_er Add Event Recorder Visibility
- To use the Event Recorder together with RTX5, select the software component Compiler:Event Recorder.
- Select the \b Source variant of the software component CMSIS:RTOS2 (API):Keil RTX5.
@@ -354,7 +390,7 @@ also reflected in the user code template file "CMSIS-RTOS2 'main' function" supp
Your application's \c main() should implement at least the following in the given order:
-# Initialization and configuration of hardware including peripherals, memory, pins, clocks and the interrupt system.
-# Update the system core clock using the respective
- CMSIS-CORE function.
+ CMSIS-Core (Cortex-M) function.
-# Initialize the CMSIS-RTOS kernel using \ref osKernelInitialize.
-# Optionally, create a new thread \c app_main, which is used as a main thread using \ref osThreadNew. Alternatively, threads
can be created in \c main() directly.
@@ -365,10 +401,40 @@ Your application's \c main() should implement at least the following in the give
groupings in the NVIC are altered by the application after the above sequence it might be necessary to call
\ref osKernelInitialize again.
+\section Scheduler
+
+RTX5 implements a low-latency preemtive scheduler. Major parts of RTX5 are executed in handler mode such as
+ - \ref SysTick_Handler used for time-based scheduling.
+ - \ref SVC_Handler used for lock-based scheduling.
+ - \ref PendSV_Handler used for interrupt-based scheduling.
+
+In order to be low-latency with respect to ISR execution those system exceptions are configured to use the
+lowest priority groups available. The priorities are configured such that no preemption happens between them. Thus
+no interrupt critical sections (i.e. interrupt locks) are needed to protect the scheduler.
+
+\image html scheduling.png "Thread scheduling and interrupt execution"
+
+The scheduler combines priority and round-robin based context switches. The example depicted in the image above contains
+four threads (1, 2, 3, and 4). Threads 1 and 2 share the same priority, thread 3 has a higher one and thread 4 the highest
+(\ref osThreadAttr_t::priority). As long as threads 3 and 4 are blocked the scheduler switches between thread 1 and 2 on
+a time-slice basis (round-robin). The time-slice for round-robin scheduling can be configured, see Round-Robin Timeout in \ref systemConfig.
+
+Thread 2 unblocks thread 3 by an arbitrary RTOS-call (executed in SVC handler mode) at time index 2. The scheduler switches to
+thread 3 immidiately because thread 3 has the highest priority. Thread 4 is still blocked.
+
+At time index 4 an interrupt (ISR) occurs and preempts the SysTick_Handler. RTX does not add any latency to the interrupt
+service execution. The ISR routine uses an RTOS-call that unblocks thread 4. Instead of switching to thread 4 immediately
+the PendSV flag is set to defer the context switching. The PendSV_Handler is executed right after the SysTick_Handler returns
+and the defered context switch to thread 4 is carried out. As soon as highest priority thread 4 blocks again by using
+a blocking RTOS-call execution is switched back to thread 3 immidiately during time index 5.
+
+At time index 5 thread 3 uses a blocking RTOS-call as well. Thus the scheduler switches back to thread 2 for time index 6.
+At time index 7 the scheduler uses the round-robin mechanism to switch to thread 1 and so on.
+
\section MemoryAllocation Memory Allocation
RTX5 objects (thread, mutex, semaphore, timer, message queue, thread and event flags, as well as memory pool) require
-dedicated RAM memory. Objects can be created using osobjectNew() calls and deleted using osobjectDelete()
+dedicated RAM memory. Objects can be created using osObjectNew() calls and deleted using osObjectDelete()
calls. The related object memory needs to be available during the lifetime of the object.
RTX5 offers three different memory allocation methods for objects:
@@ -389,7 +455,7 @@ configuration setting of RTX5.
\image html MemAllocGlob.png "Global Memory Pool for all objects"
When the memory pool does not provide sufficient memory, the creation of the object fails and the related
-osobjectNew() function returns \token{NULL}.
+osObjectNew() function returns \token{NULL}.
Enabled in \ref systemConfig.
@@ -413,7 +479,7 @@ file:
- Enabled in \ref msgQueueConfig for message objects.
When the memory pool does not provide sufficient memory, the creation of the object fails and the related
-osobjectNew() function returns \token{NULL}.
+osObjectNew() function returns \token{NULL}.
\subsection StaticObjectMemory Static Object Memory
In contrast to the dynamic memory allocations, the static memory allocation requires compile-time allocation of object memory.
@@ -530,62 +596,18 @@ void osRtxIdleThread (void) {
\c __WFE() is not available in every Cortex-M implementation. Check device manuals for availability.
-\section kernelTimer RTX kernel Timer Tick
-
-By default, RTX5 uses the Cortex-M
-SysTick timer to generate
-periodic interrupts for the RTX kernel timer tick. CMSIS-RTOS provides \ref CMSIS_RTOS_TimerMgmt functions and several
-CMSIS-RTOS functions have a \a timeout parameter. This periodic RTX kernel timer tick interrupt is used to derive the
-required time interval. RTX5 also provides configuration options for an alternative timer and tick-less operation.
+\section kernelTimer RTX Kernel Timer Tick
-To handle timeout and time delays for threads, the RTX5 thread management is controlled by the RTX kernel timer tick
-interrupt. The thread context contains all CPU registers (R0 - R12), the return address (LR), the program counter (PC), and
-the processor status register (xPSR). For the Cortex-M4/M7 FPU the floating point status and registers (S0 - S32, FPSCR) are
-also part of the thread context.
+RTX uses the generic \ref CMSIS_RTOS_TickAPI to configure and control its periodic Kernel Tick.
-When a thread switch occurs:
- - the thread context of the current running thread is stored on the local stack of this thread.
- - the stack pointer is switched to the next running thread.
- - the thread context of this next running thread is restored and this thread starts to run.
+To use an alternative timer as the Kernel Tick Timer one simply needs to implement a custom version
+of the \ref CMSIS_RTOS_TickAPI.
+\note The OS Tick implementation provided must asure that the used timer interrupt uses the same (low) priority group
+as the service interrupts, i.e. interrupts used by RTX must not preempt each other. Refer to the \ref Scheduler section
+for more details.
-\section CMSIS_RTOS_TimeOutValue Timeout Value
-
-Timeout values are an argument to several \b osXxx functions to allow time for resolving a request. A timeout value of \b 0
-means that the RTOS does not wait and the function returns instantly, even when no resource is available. A timeout value of
-\ref osWaitForever means that the RTOS waits infinitely until a resource becomes available.
-
-The timeout value specifies the number of timer ticks until the time delay elapses. The value is an upper bound and
-depends on the actual time elapsed since the last timer tick.
-
-Examples:
- - timeout value \b 0 : the system does not wait, even when no resource is available the RTOS function returns instantly.
- - timeout value \b 1 : the system waits until the next timer tick occurs; depending on the previous timer tick, it may be a
- very short wait time.
- - timeout value \b 2 : actual wait time is between 1 and 2 timer ticks.
- - timeout value \ref osWaitForever : system waits infinite until a resource becomes available.
-
-\image html TimerValues.png "Example of timeout using osDelay()"
-
-
-\section CMSIS_RTOS_ISR_Calls Calls from Interrupt Service Routines
-
-The following CMSIS-RTOS2 functions can be called from threads and Interrupt Service Routines (ISR):
- - \ref osKernelGetSysTimerCount, \ref osKernelGetSysTimerFreq
- - \ref osThreadFlagsSet
- - \ref osEventFlagsSet, \ref osEventFlagsClear, \ref osEventFlagsGet, \ref osEventFlagsWait
- - \ref osSemaphoreAcquire, \ref osSemaphoreRelease, \ref osSemaphoreGetCount
- - \ref osMemoryPoolAlloc, \ref osMemoryPoolFree, \ref osMemoryPoolGetCapacity, \ref osMemoryPoolGetBlockSize,
- \ref osMemoryPoolGetCount, \ref osMemoryPoolGetSpace
- - \ref osMessageQueuePut, \ref osMessageQueueGet, \ref osMessageQueueGetCapacity, \ref osMessageQueueGetMsgSize,
- \ref osMessageQueueGetCount, \ref osMessageQueueGetSpace
-
-Functions that cannot be called from an ISR are verifying the interrupt status and return the status code \b osErrorISR, in
-case they are called from an ISR context. In some implementations, this condition might be caught using the HARD_FAULT
-vector.
-
-
-\section TickLess Tick-less Low-Power Operation
+\subsection TickLess Tick-less Low-Power Operation
RTX5 provides extension for tick-less operation which is useful for applications that use extensively low-power modes where
the SysTick timer is also disabled. To provide a time-tick in such power-saving modes, a wake-up timer is used to
@@ -657,7 +679,7 @@ void osRtxIdleThread (void) {
tc = 0;
/* Enter the low power state */
MSP432_LP_Entry();
- __WFI();
+ __WFE();
}
/* Adjust the kernel ticks with the amount of ticks slept */
osKernelResume (tc);
@@ -666,8 +688,8 @@ void osRtxIdleThread (void) {
\endcode
\note
-\c __WFI() is not available in every ARM Cortex-M implementation. Check device manuals for availability.
-
+\c __WFE() is not available in every ARM Cortex-M implementation. Check device manuals for availability.
+The alternative using \c __WFI() has other issues, please take note of http://www.keil.com/support/docs/3591.htm as well.
\section rtx_os_h RTX5 Header File
@@ -678,6 +700,43 @@ using macros for control block and memory sizes.
If you require some of the RTX specific functions in your application code, \#include the header file \b %rtx_os.h:
\include rtx_os.h
+
+
+\section CMSIS_RTOS_TimeOutValue Timeout Value
+
+Timeout values are an argument to several \b osXxx functions to allow time for resolving a request. A timeout value of \b 0
+means that the RTOS does not wait and the function returns instantly, even when no resource is available. A timeout value of
+\ref osWaitForever means that the RTOS waits infinitely until a resource becomes available. Or one forces the thread to resume
+using \ref osThreadResume which is discouraged.
+
+The timeout value specifies the number of timer ticks until the time delay elapses. The value is an upper bound and
+depends on the actual time elapsed since the last timer tick.
+
+Examples:
+ - timeout value \b 0 : the system does not wait, even when no resource is available the RTOS function returns instantly.
+ - timeout value \b 1 : the system waits until the next timer tick occurs; depending on the previous timer tick, it may be a
+ very short wait time.
+ - timeout value \b 2 : actual wait time is between 1 and 2 timer ticks.
+ - timeout value \ref osWaitForever : system waits infinite until a resource becomes available.
+
+\image html TimerValues.png "Example of timeout using osDelay()"
+
+
+\section CMSIS_RTOS_ISR_Calls Calls from Interrupt Service Routines
+
+The following CMSIS-RTOS2 functions can be called from threads and Interrupt Service Routines (ISR):
+ - \ref osKernelGetTickCount, \ref osKernelGetTickFreq, \ref osKernelGetSysTimerCount, \ref osKernelGetSysTimerFreq
+ - \ref osThreadFlagsSet
+ - \ref osEventFlagsSet, \ref osEventFlagsClear, \ref osEventFlagsGet, \ref osEventFlagsWait
+ - \ref osSemaphoreAcquire, \ref osSemaphoreRelease, \ref osSemaphoreGetCount
+ - \ref osMemoryPoolAlloc, \ref osMemoryPoolFree, \ref osMemoryPoolGetCapacity, \ref osMemoryPoolGetBlockSize,
+ \ref osMemoryPoolGetCount, \ref osMemoryPoolGetSpace
+ - \ref osMessageQueuePut, \ref osMessageQueueGet, \ref osMessageQueueGetCapacity, \ref osMessageQueueGetMsgSize,
+ \ref osMessageQueueGetCount, \ref osMessageQueueGetSpace
+
+Functions that cannot be called from an ISR are verifying the interrupt status and return the status code \b osErrorISR, in
+case they are called from an ISR context. In some implementations, this condition might be caught using the HARD_FAULT
+vector.
*/
/*=======0=========1=========2=========3=========4=========5=========6=========7=========8=========9=========0=========1====*/
@@ -685,26 +744,31 @@ If you require some of the RTX specific functions in your application code, \#in
\page config_rtx5 Configure RTX v5
The file "RTX_Config.h" defines the configuration parameters of CMSIS-RTOS RTX and must be part of every project that is
-using the CMSIS-RTOS RTX kernel. The file "RTX_Config.c" contains stubs of the functions \b osRtxIdleThread and
-\b osRtxErrorNotify that can be adapted to the application's needs.
-
-The configuration file uses
-Configuration Wizard Annotations.
+using the CMSIS-RTOS RTX kernel. The configuration options are explained in detail in the following sections:
+- \ref systemConfig covers system-wide settings for the global memory pool, tick frequency, ISR event buffer and round-robin thread switching.
+- \ref threadConfig provides several parameters to configure the \ref CMSIS_RTOS_ThreadMgmt functions.
+- \ref timerConfig provides several parameters to configure the \ref CMSIS_RTOS_TimerMgmt functions.
+- \ref eventFlagsConfig provides several parameters to configure the \ref CMSIS_RTOS_EventFlags functions.
+- \ref mutexConfig provides several parameters to configure the \ref CMSIS_RTOS_MutexMgmt functions.
+- \ref semaphoreConfig provides several parameters to configure the \ref CMSIS_RTOS_SemaphoreMgmt functions.
+- \ref memPoolConfig provides several parameters to configure the \ref CMSIS_RTOS_PoolMgmt functions.
+- \ref msgQueueConfig provides several parameters to configure the \ref CMSIS_RTOS_Message functions.
+
+The file "RTX_Config.c" contains default implementations of the functions \ref osRtxIdleThread and \ref osRtxErrorNotify. Both functions
+can simply be overwritten with a custimized behavior by redefining them as part of the user code.
+
+The configuration file uses Configuration Wizard Annotations. Refer to Pack - Configuration Wizard Annotations for details.
Depending on the development tool, the annotations might lead to a more user-friendly graphical representation of the
settings. The screenshot below is a screenshot from the µVision \b Configuration \b Wizard view:
\image html config_wizard.png "RTX_Config.h in Configuration Wizard View"
-The configuration options are explained on these pages:
-- \ref systemConfig
-- \ref threadConfig
-- \ref timerConfig
-- \ref eventFlagsConfig
-- \ref mutexConfig
-- \ref semaphoreConfig
-- \ref memPoolConfig
-- \ref msgQueueConfig
+Alternatively one can provide configuration options using the compiler command line.
+For example one can customize the used tick frequency to 100us by (overwriting) the configuration using
+\code
+cc -DOS_TICK_FREQ=100
+\endcode
\section systemConfig System Configuration
@@ -782,7 +846,7 @@ Processor mode for Thread execution | \c OS_PRIVILEGE_MODE
The RTX5 kernel uses a separate stack space for each thread and provides two methods for defining the stack requirements:
- Static allocation: when \ref osThreadAttr_t::stack_mem and \ref osThreadAttr_t::stack_size specify a memory area
- which is used for the thread stack.
+ which is used for the thread stack. \b Attention: The stack memory provided must be 64-bit aligned, i.e. by using uint64_t for declaration.
- Dynamic allocation: when \ref osThreadAttr_t is NULL or \ref osThreadAttr_t::stack_mem is NULL, the system
allocates the stack memory from:
- Object-specific Memory Pool (default Stack size) when "Object specific Memory allocation" is enabled and "Number of
@@ -954,7 +1018,7 @@ a reference for building the RTX5 libraries using a tool-chain of your choice.
-# Select the project target that matches your device's processor core.
\n The project provides target configuration for all supported Cortex-M targets supported by RTX5.
-# You can find out about the required preprocessor defines in the dialogs Options for Target - C/C++ and
- Options for Target - Asm.
+ Options for Target - Asm. Note the need to use at least the C99 compiler mode when building RTX from source.
-# From the Project window you find the list of source files required for a complete library build.
-# Build the library of your choice using \b Project - \b Build \b Target (or press F7).
@@ -1110,7 +1174,82 @@ processor variants in every configuration, including ARM Cortex-M23 and Cortex-M
/**
\page technicalData5 Technical Data
-This section will list the technical data of CMSIS-RTOS RTX v5. Work in progress.
+\section technicalData_Toolchains Supported Toolchains
+
+Keil RTX5 is developed and tested using the common toolchains and development environments.
+
+\subsection technicalData_Toolchain_ARM ARM Compiler (ARM/Keil MDK, uVision5)
+
+Major parts of RTX5 are developed and optimized using ARM Compiler and ARM/Keil MDK.
+The current release is tested with the following versions:
+
+
ARM Compiler 5.06 Update 5 (Build 528)
+
ARM Compiler 6.6.1 (Long Term Maintenance)
+
ARM Compiler 6.7
+
RTOS-aware debugging with uVision 5.24
+
+
+\subsection technicalData_Toolchain_IAR IAR Embedded Workbench
+
+RTX5 has been ported to fully support IAR Embedded Workbench. The following releases are known to work:
+
+
+\subsection technicalData_Toolchain_GCC GNU Compiler Collection
+
+RTX5 has also been ported to support GCC, maintenance mainly relays on community contribution.
+Active development is currently tested with:
+
public java.util.Map<java.lang.String,java.lang.String> getProperties()
+
Get a hash with associated key-values-properties.
+
+ The hash associates arbitrary property-keys with their
+ values (represented as strings). The properties are
+ extracted directly from the storage data model.
Get a collection of blocks assigned to this process.
+
+ The assigned blocks denotes the memory areas this process
+ is granted/denied access to explicitly. Access permissions
+ to all other areas is undefined.
Project Zone - Generator Data Model Root Element
+
+ Implements the root element for the generator data model.
+ Gives access to the definition of a single project zone.
public java.util.Collection<FmBlock> getVisibleBlocks()
+
Get a collection with all leaf blocks visible to this zone.
+
+ A block is considered to be visible if it is mapped at least once
+ into the logical address space of the zones linked processor.
public java.util.Collection<FmBlock> getVisibleResources()
+
Get a collection with all resources visible to this zone.
+
+ A resource is considered to be visible if it is mapped at least once
+ into the logical address space of the zones linked processor.
This API (Application Programming Interface) document has pages corresponding to the items in the navigation bar, described as follows.
+
+
+
+
+
Package
+
Each package has a page that contains a list of its classes and interfaces, with a summary for each. This page can contain six categories:
+
+
Interfaces (italic)
+
Classes
+
Enums
+
Exceptions
+
Errors
+
Annotation Types
+
+
+
+
Class/Interface
+
Each class, interface, nested class and nested interface has its own separate page. Each of these pages has three sections consisting of a class/interface description, summary tables, and detailed member descriptions:
+
+
Class inheritance diagram
+
Direct Subclasses
+
All Known Subinterfaces
+
All Known Implementing Classes
+
Class/interface declaration
+
Class/interface description
+
+
+
Nested Class Summary
+
Field Summary
+
Constructor Summary
+
Method Summary
+
+
+
Field Detail
+
Constructor Detail
+
Method Detail
+
+
Each summary entry contains the first sentence from the detailed description for that item. The summary entries are alphabetical, while the detailed descriptions are in the order they appear in the source code. This preserves the logical groupings established by the programmer.
+
+
+
Annotation Type
+
Each annotation type has its own separate page with the following sections:
+
+
Annotation Type declaration
+
Annotation Type description
+
Required Element Summary
+
Optional Element Summary
+
Element Detail
+
+
+
+
Enum
+
Each enum has its own separate page with the following sections:
+
+
Enum declaration
+
Enum description
+
Enum Constant Summary
+
Enum Constant Detail
+
+
+
+
Use
+
Each documented package, class and interface has its own Use page. This page describes what packages, classes, methods, constructors and fields use any part of the given class or package. Given a class or interface A, its Use page includes subclasses of A, fields declared as A, methods that return A, and methods and constructors with parameters of type A. You can access this page by first going to the package, class or interface, then clicking on the "Use" link in the navigation bar.
+
+
+
Tree (Class Hierarchy)
+
There is a Class Hierarchy page for all packages, plus a hierarchy for each package. Each hierarchy page contains a list of classes and a list of interfaces. The classes are organized by inheritance structure starting with java.lang.Object. The interfaces do not inherit from java.lang.Object.
+
+
When viewing the Overview page, clicking on "Tree" displays the hierarchy for all packages.
+
When viewing a particular package, class or interface page, clicking "Tree" displays the hierarchy for only that package.
+
+
+
+
Deprecated API
+
The Deprecated API page lists all of the API that have been deprecated. A deprecated API is not recommended for use, generally due to improvements, and a replacement API is usually given. Deprecated APIs may be removed in future implementations.
+
+
+
Index
+
The Index contains an alphabetic list of all classes, interfaces, constructors, methods, and fields.
+
+
+
Prev/Next
+
These links take you to the next or previous class, interface, package, or related page.
+
+
+
Frames/No Frames
+
These links show and hide the HTML frames. All pages are available with or without frames.
+
+
+
All Classes
+
The All Classes link shows all classes and interfaces except non-static nested types.
+
+
+
Serialized Form
+
Each serializable or externalizable class has a description of its serialization fields and methods. This information is of interest to re-implementors, not to developers using the API. While there is no link in the navigation bar, you can get to this information by going to any serialized class and clicking "Serialized Form" in the "See also" section of the class description.
+\endcode
+
+*/
diff --git a/CMSIS/DoxyGen/Zone/src/Overview.txt b/CMSIS/DoxyGen/Zone/src/Overview.txt
new file mode 100644
index 0000000000..986ba5d12b
--- /dev/null
+++ b/CMSIS/DoxyGen/Zone/src/Overview.txt
@@ -0,0 +1,76 @@
+/*=======0=========1=========2=========3=========4=========5=========6=========7=========8=========9=========0=========1====*/
+/**
+\mainpage
+
+This is a preview of \b CMSIS-Zone which is scheduled for release in Q1'2018. The final release of CMSIS-Zone will provide:
+ - \ref XML_Format (XML based) which stores consistent system setup information.
+ - CMSIS-Zone configuration utility for system partitioning. The \ref GenDataModel "data" captured can be exported to various project and configuration files using file templates.
+
+\b CMSIS-Zone defines methods to describe system resources and to partition these resources into multiple projects and execution areas.
+The system resources may include multiple processors, memory areas, and peripherals. The system resource and partitioning information is stored in \ref XML_Format (XML based).
+
+\b CMSIS-Zone includes an interactive tool that manages files in the \ref XML_Format which allows to:
+ - create system resource information from existing CMSIS-SVD and CMSIS-Pack descriptions.
+ - partition system resources into various project zones.
+ - partition a project zone into multiple execution zones.
+ - generate various configuration files for tool set-up and hardware initialization.
+
+The following diagram explains the development flow when using the \b CMSIS-Zone management tool.
+
+\image html DevelopmentFlow.png "CMSIS-Zone Development Flow"
+
+The following sections explain:
+- \ref XML_Format (XML based) that stores system resource information and the configuration of project zones and execution zones.
+- \ref GenDataModel which is used to create tool set-up files and hardware configuration files.
+
+
+\section UseCases CMSIS-Zone Use Cases
+
+\b CMSIS-Zone simplifies to manage the complexity and the configuration of modern embedded systems that frequently include multiple processors and/or memory protection hardware.
+It helps to split the embedded application various projects which creates the need to partition system resources.
+And it simplifies the consistent configuration of access rights across the system, for example when using an MPU (memory protection unit).
+
+The following section describes several uses cases that benefit from \b CMSIS-Zone.
+
+\subsection UseCase_MPU MPU Protection
+
+Focused on a single core microcontroller one might want to utilize the memory protection unit (MPU) capabilities
+to segregate parts of an application. Thus the need to partition the system resources accordingly arises.
+
+\image html mpu.png "MPU Protection"
+
+\subsection UseCase_TrustZone TrustZone Partitioning
+
+TrustZone extensions add another degree of segregation which must be handled consistently.
+In this case one has to handle MPU settings per security context and SAU configuration.
+
+\image html trustzone.png "TrustZone Partitioning and MPU Protection"
+
+\subsection UseCase_MultiCore Multi-Core Partitioning
+
+Beside traditional single cores asymetric and hybrid multi-core devices contribute to increasing development complexity
+for embedded systems. Having multiple cores running different parts of an application concurrently needs a well defined
+resource assignment to prevent undesired misbehaviour.
+
+\image html multicore.png "Multi-Core Partitioning"
+
+
+*/
+
+/*=======0=========1=========2=========3=========4=========5=========6=========7=========8=========9=========0=========1====*/
+/**
+\page zone_revisionHistory Revision History of CMSIS-Zone
+
+
+
+
Version
+
Description
+
+
+
0.0.1 (Preview)
+
Initial specification draft
+
+
+
+
+*/
\ No newline at end of file
diff --git a/CMSIS/DoxyGen/Zone/src/XML_Format.txt b/CMSIS/DoxyGen/Zone/src/XML_Format.txt
new file mode 100644
index 0000000000..9ff2c06340
--- /dev/null
+++ b/CMSIS/DoxyGen/Zone/src/XML_Format.txt
@@ -0,0 +1,1589 @@
+/*=======0=========1=========2=========3=========4=========5=========6=========7=========8=========9=========0=========1====*/
+/**
+\page XML_Format Zone Description Format
+
+The Zone Description Format uses standard XML annotations and is defined in the schema file \b ZONE.xsd.
+It is intended to provide a tool vendor agnostic storage format for
+
+- describing embedded system resource capabilities
+ - specific \ref format_device "device" and \ref format_processor "processor" properties
+ - available \ref format_memory "memory" and \ref format_peripheral "peripheral" resources
+- specifying resource partitioning across
+ - \ref format_pzone "project zones", e.g. for secure and non-secure firmware parts
+ - \ref format_xzone "execution zones", e.g. for functional segregation
+
+\section XML_Format_Model Storage Data Model
+
+In the following diagram the overall structure of the Storage Data Model is depicted.
+The \ref XML_Format_Schema "storage format" is derived from the model.
+
+\image html storagemodel.png "Storage Data Model Class Diagram"
+
+The storage model is developed based on the domain and can be seen as the domain model as well.
+Its main purpose is to capture all information about presumable embedded systems and microcontroller devices.
+
+\subsection XML_Format_Model_Decomp Embedded Microcontroller System Decomposition
+
+Todays available system-on-modules (SoM) and system-on-chips (SoC) already physically outlines the overall composition.
+It seems to be viable to stick with todays system structures. It's not likely that this structure will change drastically.
+
+A detailed view on the decomposition of an arbitrary SoM is given in the diagram below.
+
+\image html som-decomposition.png "System-on-Module Decomposition"
+
+The SoM itself (System) can be seen as a composition of one or more SoCs (Device) combined with an arbitrary amount of
+board-level resources, i.e. off-chip memory (Memory) and peripheral (Peripheral). In turn each SoC is a composition of
+one or more processor elements (Processor, PE) with chip-level resources, i.e. on-chip memory and peripheral.
+
+Private memory and peripheral resources local to a dedicated PE has been simplified. These can also be seen as chip-level resources.
+
+The grouping (ResourceGroup) is intended to allow structural grouping of resources elements, i.e. by type or bus structure.
+
+\note The names (i.e. `name` attributes) are typically used as references and hence must be unique per class. Duplicate names are
+allowed if object hierarchies do not overlap. I.e. resources contained on two separate SoCs may have the same name but the name of
+a SoM level resource must not be reused on SoC level.
+
+\subsection XML_Format_Model_MemMap Microcontroller Memory Map Specification
+
+Most of the Multi-Core-SoCs available today show uniform memory maps. But in principle the logical memory address used
+to address a certain resource may vary between multiple PEs on the same SoC. Taking this into account leads to memory
+map specification on both SoC and PE level, see diagram below.
+
+\image html soc-memorymap.png "System-on-Chip Memory Map Specification"
+
+The memory maps specified on SoC and PE level are additive, i.e. the PEs actual memory map is the combination of both.
+This split allow the specification of uniform memory maps without duplication. Only the non-uniform parts need to be
+specified on PE level.
+
+Each resource can be mapped as often as needed, i.e. to reflect multiple memory aliases. By default the `name` attribute
+is used to identify the resource to be mapped. In order to map the same resource multiple times into a PEs memory space
+the `alias` attribute must be given to identify the resource instead. The mapping names must be unique per PE because they
+are used as references later.
+
+The attributes of the mapping are merged with those of the resource mapped. This allows the mapping of an individual PE
+to enhance the basic attributes of a resource. For example a memory resource that is basically readable/writeable/executable
+might be mapped to a PE as readonly memory.
+
+\subsection XML_Format_Model_Assign Zone Resource Assignments
+
+A system can be split into an arbitrary amount of project zones (PZone). And each PZone can be further split into execution
+zones (XZone). Resources used by an individual zone are represented using assignments (Assignment). Refer to the diagram
+below.
+
+\image html zone-assignment.png "Zone Resource Assignments"
+
+Each PZone is assigned to a dedicated PE which is selected to execute the resulting software part. The PE is referenced by
+the unique combination of `Dname` and `Pname` attributes. The XZones are contained in the PZone they belong to.
+
+Both PZones and XZones can have arbitrary assignments to available resources visible to the assigned PE. Assignments to
+SoC level resources not part of the SoC the PE is located on are illegal. Such assignments cannot be represented because
+the unique reference is built from `PZone::Dname` and `Assignment::name`.
+
+As a resource may be visible to the enclosing PE using multiple mappings the `as` attribute can be used to distinguish
+which alias is used for access. Selecting the correct alias is significant because of the effective access attributes
+resulting from merging `Resource.access`, `MemoryMapping.access`/`PeripheralMapping.access` and `Assignment.access`.
+
+Whilst peripheral resources can be assigned directly memory resources need to be split into blocks (MemoryBlock). A
+block can be seen as an arbitrary part of the physical memory. Individual blocks can be defined using modified
+access attributes, e.g. for having dedicated executable or readonly regions in RAM.
+
+\section XML_Format_Schema Zone Schema
+
+The XML schema is defined hierarchically with the following top-level elements:
+
+\subpage format_system
+- \ref format_device
+- \ref format_resources
+- \ref format_zones
+
+\code
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+\endcode
+
+\section Example
+
+
+*/
+
+/*=======0=========1=========2=========3=========4=========5=========6=========7=========8=========9=========0=========1====*/
+/**
+\page format_system /system element
+
+The system element is the root element of a CMSIS-Zone system definition.
+
+Example
+\code
+
+
+
+
+
+ :
+
+ :
+
+
+
+
+
+
+ :
+
+
+
+
+
+
+ :
+
+ :
+
+
+\endcode
+
+Schema Description
+
+
+
+
Parent Element
+
Element Chain
+
+
+
root
+
Document root
+
+
+
Attributes
+
Description
+
Type
+
Use
+
+
+
xmlns:xs
+
Is set to: \token{"http://www.w3.org/2001/XMLSchema-instance"} to indicate compliance to the XML format.
+
xs:decimal
+
required
+
+
+
xs:noNamespaceSchemaLocation
+
Path and file name of the XML Schema Definition (XSD).
+
xs:string
+
required
+
+
+
Child Elements
+
Description
+
Type
+
Occurrence
+
+
+
\subpage format_device "device"
+
Specifies available microcontroller devices (i.e. SoCs) that are part of the system. Typically a system contains only a single SoC device.
+
complexType
+
1..*
+
+
+
\subpage format_resources "resources"
+
Specifies the resources (i.e. memory and peripherals) on system level, i.e. those not integral part of an SoC device. Resources defined on system level may be specified as shared between multiple SoCs.
+
complexType
+
0..1
+
+
+
\subpage format_zones "zones"
+
Specifies the system partitioning in terms of project and execution zones.
+
complexType
+
0..1
+
+
+
+*/
+
+/*=======0=========1=========2=========3=========4=========5=========6=========7=========8=========9=========0=========1====*/
+/**
+\page format_device /device element
+
+The device element is used to define one integral System-on-Chip (SoC) device.
+
+Example
+\code
+
+
+
+
+ :
+
+ :
+
+
+
+
+
+ :
+
+
+
+
+
+
+ :
+
+
+
+\endcode
+
+Schema Description
+
+
+
+
Parent Element
+
Element Chain
+
+
+
\ref format_system "system"
+
\ref format_system
+
+
+
Attributes
+
Description
+
Type
+
Use
+
+
+
Dfamily
+
The familiy name the device belongs to.
+
xs:string
+
optional
+
+
+
DsubFamily
+
The sub familiy name the device belongs to.
+
xs:string
+
optional
+
+
+
Dname
+
The device name.
+
xs:string
+
required
+
+
+
Dvendor
+
The devices vendor identifier.
+
xs:string
+
required
+
+
+
info
+
Brief description of the device.
+
xs:string
+
optional
+
+
+
Child Elements
+
Description
+
Type
+
Occurrence
+
+
+
\subpage format_package "package"
+
Optional reference to the Software Pack this device is provided by.
+
complexType
+
0..1
+
+
+
\subpage format_processor "processor"
+
Processing elements and associated features embedded in the device.
+
complexType
+
1..*
+
+
+
\subpage format_resources "resources"
+
Memory and peripheral resources embedded in the device. In contrast to resources defined on system level those at device level are only accessible from processors located on the same enclosing device.
+
complexType
+
0..1
+
+
+
\subpage format_memory_map "memory_map"
+
All \em physical resources are accessible using \em logical memory addresses, i.e. typically called memory map.
+ Common logical addresses valid for all processing elements can be defined at device level memory map, i.e. devices
+ with an uniform memory map. Refer to the individual processor memory map for devices with non-uniform memory maps.
+
complexType
+
0..1
+
+
+
+*/
+
+/*=======0=========1=========2=========3=========4=========5=========6=========7=========8=========9=========0=========1====*/
+/**
+\page format_package /package element
+
+
+The package element can optinally be used to refer to the Software Pack providing a certain \ref format_device "device".
+
+Example
+\code
+
+
+ :
+
+\endcode
+
+Schema Description
+
+
+
+
Parent Element
+
Element Chain
+
+
+
\ref format_device "device"
+
\ref format_device
+
+
+
Attributes
+
Description
+
Type
+
Use
+
+
+
name
+
The unique pack name.
+
xs:string
+
required
+
+
+
url
+
The URL the pack can be obtained from.
+
xs:string
+
required
+
+
+
vendor
+
The pack vendor name.
+
xs:string
+
required
+
+
+
version
+
The pack version.
+
xs:string
+
optional
+
+
+
info
+
Brief description of the Software Pack.
+
xs:string
+
optional
+
+
+
+*/
+
+/*=======0=========1=========2=========3=========4=========5=========6=========7=========8=========9=========0=========1====*/
+/**
+\page format_processor /processor element
+
+The processor element is used to define the processing elements integration on a \ref format_device "device".
+
+Example
+\code
+
+
+
+
+ :
+
+ :
+
+\endcode
+
+Schema Description
+
+
+
+
Parent Element
+
Element Chain
+
+
+
\ref format_device "device"
+
\ref format_device
+
+
+
Attributes
+
Description
+
Type
+
Use
+
+
+
Pname
+
Processor identifier. This attribute is mandatory for devices that embed multiple processors.
+ Each processor needs a per device unique identifier and must be used consistently in the Pname attribute.
+ Only alphabetical characters, decimal digits, '-' and '_' are allowed.
+
+
RestrictedString
+
optional
+
+
+
Dcore
+
Specifies the processor core.
+
DcoreEnum
+
optional
+
+
+
Dfpu
+
Specifies whether a hardware Floating Point Unit is present in the processor.
+
DfpuEnum
+
optional
+
+
+
Dmpu
+
Specifies whether a Memory Protection Unit is present in the processor.
+
DmpuEnum
+
optional
+
+
+
Dtz
+
Specifies whether an ARMv8M based device implements TrustZone.
+
DtzEnum
+
optional
+
+
+
Ddsp
+
Specifies whether an ARMv8M based device supports the DSP instructions set.
+
DdspEnum
+
optional
+
+
+
Dendian
+
Specifies the endianess of the processor.
+
DendianEnum
+
optional
+
+
+
Dclock
+
Specifies the max clock frequency of the processor subsystem
+
xs:unsignedInt
+
optional
+
+
+
DcoreVersion
+
Hardware revision of the processor core
+
xs:string
+
required
+
+
+
info
+
Brief description of the processor.
+
xs:string
+
optional
+
+
+
Child Elements
+
Description
+
Type
+
Occurrence
+
+
+
\subpage format_memory_map "memory_map"
+
Processor specific (non-uniform) memory map. The effective memory map of the processor is derived as
+ the union of device and processor level mappings.
+
complexType
+
0..1
+
+
+
+*/
+
+/*=======0=========1=========2=========3=========4=========5=========6=========7=========8=========9=========0=========1====*/
+/**
+\page format_memory_map /memory_map element
+
+The memory_map element is used to to define the logical address mappings (i.e. the \em "memory map").
+
+Example
+\code
+
+
+
+ :
+
+
+ :
+
+\endcode
+
+Schema Description
+
+
+
+
Parent Element
+
Element Chain
+
+
+
\ref format_device "device"
+
\ref format_device
+
+
+
\ref format_processor "processor"
+
\ref format_processor
+
+
+
Child Elements
+
Description
+
Type
+
Occurrence
+
+
+
\subpage format_map_memory "memory"
+
One memory entry per memory region mapped into the logical address space.
+
complexType
+
0..*
+
+
+
\subpage format_map_peripheral "peripheral"
+
One peripheral entry per peripheral mapped into the logical address space.
+
complexType
+
0..*
+
+
+
+*/
+
+/*=======0=========1=========2=========3=========4=========5=========6=========7=========8=========9=========0=========1====*/
+/**
+\page format_map_memory /memory element
+
+The memory element is used to define an address mapping for one \ref format_region "memory/region".
+
+Example
+\code
+
+
+
+
+
+
+ :
+
+\endcode
+
+Schema Description
+
+
+
+
Parent Element
+
Element Chain
+
+
+
\ref format_memory_map "memory_map"
+
\ref format_memory_map
+
+
+
Attributes
+
Description
+
Type
+
Use
+
+
+
name
+
The name this address mapping can be referenced by. Must be unique within a single processors memory map.
+
xs:string
+
required
+
+
+
alias
+
Reference to the (physical) memory region mapped. If the alias is ommitted the name is used.
+
xs:string
+
optional
+
+
+
start
+
The logical start address the memory region is accessible at.
+
xs:string
+
required
+
+
+
size
+
The amount of memory that is accessible. If ommitted the size is taken over from the memory region.
+
xs:string
+
optional
+
+
+
info
+
Brief description of the memory mapping.
+
xs:string
+
optional
+
+
+
Child Elements
+
Description
+
Type
+
Occurrence
+
+
+
+
+
complexType
+
0..1
+
+
+
+*/
+
+/*=======0=========1=========2=========3=========4=========5=========6=========7=========8=========9=========0=========1====*/
+/**
+\page format_map_peripheral /peripheral element
+
+The peripheral element is used to define an address mapping for one \ref format_peripheral "peripheral".
+
+Example
+\code
+
+
+
+ :
+
+\endcode
+
+Schema Description
+
+
+
+
Parent Element
+
Element Chain
+
+
+
\ref format_memory_map "memory_map"
+
\ref format_memory_map
+
+
+
Attributes
+
Description
+
Type
+
Use
+
+
+
name
+
The name this address mapping can be referenced by. Must be unique within a single processors memory map.
+
xs:string
+
required
+
+
+
alias
+
Reference to the (physical) peripheral mapped. If the alias is ommitted the name is used.
+
xs:string
+
optional
+
+
+
start
+
The logical start address the peripheral registers are accessible at.
+
+*/
+
+
+/*=======0=========1=========2=========3=========4=========5=========6=========7=========8=========9=========0=========1====*/
+/**
+\page format_group /group element
+
+The group element can be used to logically group peripherals together, e.g. according to functionality or bus topology.
+
+Example
+\code
+
+ :
+
+
+ :
+
+
+
+ :
+
+
+
+\endcode
+
+Schema Description
+
+
The name of the device this project zone is assigned to.
+
xs:string
+
required
+
+
+
Pname
+
The name of the processor (on the device) this project is assigned to.
+
xs:string
+
required
+
+
+
info
+
Brief description of the project zone.
+
xs:string
+
optional
+
+
+
Child Elements
+
Description
+
Type
+
Occurrence
+
+
+
\subpage format_assign
+
Resource Assignments
+
complexType
+
0..*
+
+
+
\subpage format_xzone
+
Execution Zones
+
complexType
+
0..*
+
+
+
+*/
+
+/*=======0=========1=========2=========3=========4=========5=========6=========7=========8=========9=========0=========1====*/
+/**
+\page format_xzone /xzone element
+
+The xzone element defines an execution zone, i.e. a process grouping threads sharing common resource access attributes.
+
+Example
+\code
+
+
+
+
+ :
+
+
+
+ :
+
+ :
+
+\endcode
+
+Schema Description
+
+
+
+
Parent Element
+
Element Chain
+
+
+
\ref format_pzone "pzone"
+
\ref format_pzone
+
+
+
Attributes
+
Description
+
Type
+
Use
+
+
+
name
+
The name of a resource (mapped to the processor) to be used by this zone.
+
xs:string
+
required
+
+
+
info
+
Brief description of the resource assignment.
+
xs:string
+
optional
+
+
+
Child Elements
+
Description
+
Type
+
Occurrence
+
+
+
\subpage format_assign
+
Resource assignments
+
complexType
+
0..*
+
+
+
+*/
+
+/*=======0=========1=========2=========3=========4=========5=========6=========7=========8=========9=========0=========1====*/
+/**
+\page format_assign /assign element
+
+The assign element defines the resources used by a zone.
+
+Example
+\code
+
+
+
+
+
+ :
+
+
+ :
+
+ :
+
+\endcode
+
+Schema Description
+
+
+
+
Parent Element
+
Element Chain
+
+
+
\ref format_pzone "pzone"
+
\ref format_pzone
+
+
+
Attributes
+
Description
+
Type
+
Use
+
+
+
name
+
The name of a resource (mapped to the processor) to be used by this zone.
+
xs:string
+
required
+
+
+
as
+
The name of the mapping (alias) to be used to address the referenced resource.
+
xs:string
+
optional
+
+
+
access
+
Additional access attributes to be used.
+
xs:string
+
optional
+
+
+
info
+
Brief description of the resource assignment.
+
xs:string
+
optional
+
+
+
Child Elements
+
Description
+
Type
+
Occurrence
+
+
+
\subpage format_capture
+
Linker usage
+
complexType
+
0..*
+
+
+
+*/
+
+/*=======0=========1=========2=========3=========4=========5=========6=========7=========8=========9=========0=========1====*/
+/**
+\page format_capture /capture element
+
+The capture element can be used to specify linker symbol patterns to be placed into the enclosing
+memory assignment.
+
+Example
+\code
+
+
+
+
+
+ :
+
+ :
+
+ :
+
+\endcode
+
+Schema Description
+
+
+
+
Parent Element
+
Element Chain
+
+
+
\ref format_assign "assign"
+
\ref format_assign
+
+
+
Attributes
+
Description
+
Type
+
Use
+
+
+
cunit
+
Pattern selecting the compilation unit(s) to be placed into this assignment.
+
xs:string
+
optional
+
+
+
symbol
+
Pattern selecting the symbols to be placed into this assignment.
+
xs:string
+
optional
+
+
+
Child Elements
+
Description
+
Type
+
Occurrence
+
+
+
+
+
complexType
+
0..*
+
+
+
+*/
+
diff --git a/CMSIS/DoxyGen/Zone/src/images/CMSIS_Zone.pptx b/CMSIS/DoxyGen/Zone/src/images/CMSIS_Zone.pptx
new file mode 100644
index 0000000000..7912b7b65b
Binary files /dev/null and b/CMSIS/DoxyGen/Zone/src/images/CMSIS_Zone.pptx differ
diff --git a/CMSIS/DoxyGen/Zone/src/images/DevelopmentFlow.png b/CMSIS/DoxyGen/Zone/src/images/DevelopmentFlow.png
new file mode 100644
index 0000000000..ccf2462335
Binary files /dev/null and b/CMSIS/DoxyGen/Zone/src/images/DevelopmentFlow.png differ
diff --git a/CMSIS/DoxyGen/Zone/src/images/generator.png b/CMSIS/DoxyGen/Zone/src/images/generator.png
new file mode 100644
index 0000000000..5b9a1af7c5
Binary files /dev/null and b/CMSIS/DoxyGen/Zone/src/images/generator.png differ
diff --git a/CMSIS/DoxyGen/Zone/src/images/genmodel.graphml b/CMSIS/DoxyGen/Zone/src/images/genmodel.graphml
new file mode 100644
index 0000000000..9a55e088eb
--- /dev/null
+++ b/CMSIS/DoxyGen/Zone/src/images/genmodel.graphml
@@ -0,0 +1,418 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Zone
+
+
+
+
+
+
+
+ name : String
+
+
+
+
+
+
+
+
+
+
+
+
+ Block
+
+
+
+
+
+
+
+ info : String
+name : String
+start : Number
+size : Number
+callable : Boolean
+executable : Boolean
+nonSecure : Boolean
+peripheral : Boolean
+privileged : Boolean
+readable : Boolean
+secure : Boolean
+unprivileged : Boolean
+writeable : Boolean
+
+
+
+
+
+
+
+
+
+
+
+
+ Device
+
+
+
+
+
+
+
+ name : String
+packageName : String
+packageVendor : String
+vendor : String
+
+
+
+
+
+
+
+
+
+
+
+
+ Processor
+
+
+
+
+
+
+
+ name : String
+
+
+
+
+
+
+
+
+
+
+
+
+ Process
+
+
+
+
+
+
+
+ name : String
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ processes
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ device
+
+
+
+
+
+
+
+ 1
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ processor
+
+
+
+
+
+
+
+ 1
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ processor
+
+
+
+
+
+
+
+ 1
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ device
+
+
+
+
+
+
+
+ 1
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ blocks
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ visibleBlocks
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ visibleResources
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ blocks
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ blocks
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/CMSIS/DoxyGen/Zone/src/images/genmodel.png b/CMSIS/DoxyGen/Zone/src/images/genmodel.png
new file mode 100644
index 0000000000..c2596eb81b
Binary files /dev/null and b/CMSIS/DoxyGen/Zone/src/images/genmodel.png differ
diff --git a/CMSIS/DoxyGen/Zone/src/images/images.odp b/CMSIS/DoxyGen/Zone/src/images/images.odp
new file mode 100644
index 0000000000..f0fb449ec6
Binary files /dev/null and b/CMSIS/DoxyGen/Zone/src/images/images.odp differ
diff --git a/CMSIS/DoxyGen/Zone/src/images/mpu.png b/CMSIS/DoxyGen/Zone/src/images/mpu.png
new file mode 100644
index 0000000000..ed81a585e4
Binary files /dev/null and b/CMSIS/DoxyGen/Zone/src/images/mpu.png differ
diff --git a/CMSIS/DoxyGen/Zone/src/images/multicore.png b/CMSIS/DoxyGen/Zone/src/images/multicore.png
new file mode 100644
index 0000000000..df58db345b
Binary files /dev/null and b/CMSIS/DoxyGen/Zone/src/images/multicore.png differ
diff --git a/CMSIS/DoxyGen/Zone/src/images/soc-memorymap.graphml b/CMSIS/DoxyGen/Zone/src/images/soc-memorymap.graphml
new file mode 100644
index 0000000000..31e7142c71
--- /dev/null
+++ b/CMSIS/DoxyGen/Zone/src/images/soc-memorymap.graphml
@@ -0,0 +1,485 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Device
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ MemoryMap
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ ResourceGroup
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ MemoryMapping
+
+
+
+
+
+
+
+ name : String
+alias : String
+start : Number
+size : Number
+access : String
+
+
+
+
+
+
+
+
+
+
+
+
+ PeripheralMapping
+
+
+
+
+
+
+
+ name : String
+alias : String
+start : Number
+access : String
+
+
+
+
+
+
+
+
+
+
+
+
+ Processor
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ MemoryRegion
+
+
+
+
+
+
+
+ name : String
+size : Number
+access : String
+
+
+
+
+
+
+
+
+
+
+
+
+ Peripheral
+
+
+
+
+
+
+
+ name : String
+size : Number
+access : String
+
+
+
+
+
+
+
+
+
+
+
+
+ processors
+
+
+
+
+
+
+
+ 1..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ memMap
+
+
+
+
+
+
+
+ 0..1
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ memMap
+
+
+
+
+
+
+
+ 0..1
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ resources
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 1
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+ 1
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/CMSIS/DoxyGen/Zone/src/images/soc-memorymap.png b/CMSIS/DoxyGen/Zone/src/images/soc-memorymap.png
new file mode 100644
index 0000000000..211c986ad5
Binary files /dev/null and b/CMSIS/DoxyGen/Zone/src/images/soc-memorymap.png differ
diff --git a/CMSIS/DoxyGen/Zone/src/images/som-decomposition.graphml b/CMSIS/DoxyGen/Zone/src/images/som-decomposition.graphml
new file mode 100644
index 0000000000..6428240ae1
--- /dev/null
+++ b/CMSIS/DoxyGen/Zone/src/images/som-decomposition.graphml
@@ -0,0 +1,358 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ System
+
+
+
+
+
+
+ <systeem
+
+
+
+
+
+
+ <system>
+
+
+
+
+
+
+ system
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Device
+
+
+
+
+
+
+
+ name : String
+
+
+
+
+
+
+
+
+
+
+
+
+ MemoryRegion
+
+
+
+
+
+
+
+ name : String
+size : Number
+access : String
+
+
+
+
+
+
+
+
+
+
+
+
+ Peripheral
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ name : String
+size : Number
+access : String
+
+
+
+
+
+
+
+
+
+
+
+
+ ResourceGroup
+
+
+
+
+
+
+
+ name : String
+
+
+
+
+
+
+
+
+
+
+
+
+ Processor
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ name : String
+
+
+
+
+
+
+
+
+
+
+
+
+ devices
+
+
+
+
+
+
+
+ 1..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ processors
+
+
+
+
+
+
+
+ 1..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ resources
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ resources
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/CMSIS/DoxyGen/Zone/src/images/som-decomposition.png b/CMSIS/DoxyGen/Zone/src/images/som-decomposition.png
new file mode 100644
index 0000000000..23607167c5
Binary files /dev/null and b/CMSIS/DoxyGen/Zone/src/images/som-decomposition.png differ
diff --git a/CMSIS/DoxyGen/Zone/src/images/storagemodel.graphml b/CMSIS/DoxyGen/Zone/src/images/storagemodel.graphml
new file mode 100644
index 0000000000..a945ff420f
--- /dev/null
+++ b/CMSIS/DoxyGen/Zone/src/images/storagemodel.graphml
@@ -0,0 +1,867 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ System
+
+
+
+
+
+
+ <systeem
+
+
+
+
+
+
+ <system>
+
+
+
+
+
+
+ system
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Device
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ PZone
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ MemoryMap
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ MemoryRegion
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Peripheral
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ MemoryBlock
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ ResourceGroup
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ MemoryMapping
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ PeripheralMapping
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Processor
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Assignment
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ XZone
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ devices
+
+
+
+
+
+
+
+ 1..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ processors
+
+
+
+
+
+
+
+ 1..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ memMap
+
+
+
+
+
+
+
+ 0..1
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ memMap
+
+
+
+
+
+
+
+ 0..1
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ resources
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ resources
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 1
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+ 1
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ zones
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 0..1
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 0..1
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ target
+
+
+
+
+
+
+
+ 1
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/CMSIS/DoxyGen/Zone/src/images/storagemodel.png b/CMSIS/DoxyGen/Zone/src/images/storagemodel.png
new file mode 100644
index 0000000000..7f845d670c
Binary files /dev/null and b/CMSIS/DoxyGen/Zone/src/images/storagemodel.png differ
diff --git a/CMSIS/DoxyGen/Zone/src/images/trustzone.png b/CMSIS/DoxyGen/Zone/src/images/trustzone.png
new file mode 100644
index 0000000000..9ea01dc788
Binary files /dev/null and b/CMSIS/DoxyGen/Zone/src/images/trustzone.png differ
diff --git a/CMSIS/DoxyGen/Zone/src/images/zone-assignment.graphml b/CMSIS/DoxyGen/Zone/src/images/zone-assignment.graphml
new file mode 100644
index 0000000000..7e8180bb2b
--- /dev/null
+++ b/CMSIS/DoxyGen/Zone/src/images/zone-assignment.graphml
@@ -0,0 +1,644 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ System
+
+
+
+
+
+
+ <systeem
+
+
+
+
+
+
+ <system>
+
+
+
+
+
+
+ system
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Device
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ PZone
+
+
+
+
+
+
+
+ name : String
+Dname : String
+Pname : String
+
+
+
+
+
+
+
+
+
+
+
+
+ MemoryRegion
+
+
+
+
+
+
+
+ name : String
+size : Number
+access : String
+
+
+
+
+
+
+
+
+
+
+
+
+ Peripheral
+
+
+
+
+
+
+
+ name : String
+size : Number
+access : String
+
+
+
+
+
+
+
+
+
+
+
+
+ MemoryBlock
+
+
+
+
+
+
+
+ name : String
+offset : Number
+size : Number
+access : String
+
+
+
+
+
+
+
+
+
+
+
+
+ ResourceGroup
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Processor
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Assignment
+
+
+
+
+
+
+
+ name : String
+as : String
+access : String
+
+
+
+
+
+
+
+
+
+
+
+
+ XZone
+
+
+
+
+
+
+
+ name : String
+
+
+
+
+
+
+
+
+
+
+
+
+ devices
+
+
+
+
+
+
+
+ 1..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ processors
+
+
+
+
+
+
+
+ 1..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ resources
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ resources
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ zones
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 0..1
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 0..1
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ target
+
+
+
+
+
+
+
+ 1
+
+
+
+
+
+
+
+ 0..*
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/CMSIS/DoxyGen/Zone/src/images/zone-assignment.png b/CMSIS/DoxyGen/Zone/src/images/zone-assignment.png
new file mode 100644
index 0000000000..30d373badb
Binary files /dev/null and b/CMSIS/DoxyGen/Zone/src/images/zone-assignment.png differ
diff --git a/CMSIS/DoxyGen/Zone/zone.dxy b/CMSIS/DoxyGen/Zone/zone.dxy
new file mode 100644
index 0000000000..6fe8c3e13b
--- /dev/null
+++ b/CMSIS/DoxyGen/Zone/zone.dxy
@@ -0,0 +1,2336 @@
+# Doxyfile 1.8.6
+
+# This file describes the settings to be used by the documentation system
+# doxygen (www.doxygen.org) for a project.
+#
+# All text after a double hash (##) is considered a comment and is placed in
+# front of the TAG it is preceding.
+#
+# All text after a single hash (#) is considered a comment and will be ignored.
+# The format is:
+# TAG = value [value, ...]
+# For lists, items can also be appended using:
+# TAG += value [value, ...]
+# Values that contain spaces should be placed between quotes (\" \").
+
+#---------------------------------------------------------------------------
+# Project related configuration options
+#---------------------------------------------------------------------------
+
+# This tag specifies the encoding used for all characters in the config file
+# that follow. The default is UTF-8 which is also the encoding used for all text
+# before the first occurrence of this tag. Doxygen uses libiconv (or the iconv
+# built into libc) for the transcoding. See http://www.gnu.org/software/libiconv
+# for the list of possible encodings.
+# The default value is: UTF-8.
+
+DOXYFILE_ENCODING = UTF-8
+
+# The PROJECT_NAME tag is a single word (or a sequence of words surrounded by
+# double-quotes, unless you are using Doxywizard) that should identify the
+# project for which the documentation is generated. This name is used in the
+# title of most generated pages and in a few other places.
+# The default value is: My Project.
+
+PROJECT_NAME = "CMSIS-Zone (Preview)"
+
+# The PROJECT_NUMBER tag can be used to enter a project or revision number. This
+# could be handy for archiving the generated documentation or if some version
+# control system is used.
+
+PROJECT_NUMBER = "Version 0.0.1"
+
+# Using the PROJECT_BRIEF tag one can provide an optional one line description
+# for a project that appears at the top of each page and should give viewer a
+# quick idea about the purpose of the project. Keep the description short.
+
+PROJECT_BRIEF = "System Resource Management"
+
+# With the PROJECT_LOGO tag one can specify an logo or icon that is included in
+# the documentation. The maximum height of the logo should not exceed 55 pixels
+# and the maximum width should not exceed 200 pixels. Doxygen will copy the logo
+# to the output directory.
+
+PROJECT_LOGO = ../Doxygen_Templates/CMSIS_Logo_Final.png
+
+# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) path
+# into which the generated documentation will be written. If a relative path is
+# entered, it will be relative to the location where doxygen was started. If
+# left blank the current directory will be used.
+
+OUTPUT_DIRECTORY = ../../Documentation/Zone
+
+# If the CREATE_SUBDIRS tag is set to YES, then doxygen will create 4096 sub-
+# directories (in 2 levels) under the output directory of each output format and
+# will distribute the generated files over these directories. Enabling this
+# option can be useful when feeding doxygen a huge amount of source files, where
+# putting all generated files in the same directory would otherwise causes
+# performance problems for the file system.
+# The default value is: NO.
+
+CREATE_SUBDIRS = NO
+
+# The OUTPUT_LANGUAGE tag is used to specify the language in which all
+# documentation generated by doxygen is written. Doxygen will use this
+# information to generate all constant output in the proper language.
+# Possible values are: Afrikaans, Arabic, Armenian, Brazilian, Catalan, Chinese,
+# Chinese-Traditional, Croatian, Czech, Danish, Dutch, English (United States),
+# Esperanto, Farsi (Persian), Finnish, French, German, Greek, Hungarian,
+# Indonesian, Italian, Japanese, Japanese-en (Japanese with English messages),
+# Korean, Korean-en (Korean with English messages), Latvian, Lithuanian,
+# Macedonian, Norwegian, Persian (Farsi), Polish, Portuguese, Romanian, Russian,
+# Serbian, Serbian-Cyrillic, Slovak, Slovene, Spanish, Swedish, Turkish,
+# Ukrainian and Vietnamese.
+# The default value is: English.
+
+OUTPUT_LANGUAGE = English
+
+# If the BRIEF_MEMBER_DESC tag is set to YES doxygen will include brief member
+# descriptions after the members that are listed in the file and class
+# documentation (similar to Javadoc). Set to NO to disable this.
+# The default value is: YES.
+
+BRIEF_MEMBER_DESC = YES
+
+# If the REPEAT_BRIEF tag is set to YES doxygen will prepend the brief
+# description of a member or function before the detailed description
+#
+# Note: If both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the
+# brief descriptions will be completely suppressed.
+# The default value is: YES.
+
+REPEAT_BRIEF = NO
+
+# This tag implements a quasi-intelligent brief description abbreviator that is
+# used to form the text in various listings. Each string in this list, if found
+# as the leading text of the brief description, will be stripped from the text
+# and the result, after processing the whole list, is used as the annotated
+# text. Otherwise, the brief description is used as-is. If left blank, the
+# following values are used ($name is automatically replaced with the name of
+# the entity):The $name class, The $name widget, The $name file, is, provides,
+# specifies, contains, represents, a, an and the.
+
+ABBREVIATE_BRIEF = "The $name class" \
+ "The $name widget" \
+ "The $name file" \
+ is \
+ provides \
+ specifies \
+ contains \
+ represents \
+ a \
+ an \
+ the
+
+# If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then
+# doxygen will generate a detailed section even if there is only a brief
+# description.
+# The default value is: NO.
+
+ALWAYS_DETAILED_SEC = NO
+
+# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all
+# inherited members of a class in the documentation of that class as if those
+# members were ordinary class members. Constructors, destructors and assignment
+# operators of the base classes will not be shown.
+# The default value is: NO.
+
+INLINE_INHERITED_MEMB = NO
+
+# If the FULL_PATH_NAMES tag is set to YES doxygen will prepend the full path
+# before files name in the file list and in the header files. If set to NO the
+# shortest path that makes the file name unique will be used
+# The default value is: YES.
+
+FULL_PATH_NAMES = NO
+
+# The STRIP_FROM_PATH tag can be used to strip a user-defined part of the path.
+# Stripping is only done if one of the specified strings matches the left-hand
+# part of the path. The tag can be used to show relative paths in the file list.
+# If left blank the directory from which doxygen is run is used as the path to
+# strip.
+#
+# Note that you can specify absolute paths here, but also relative paths, which
+# will be relative from the directory where doxygen is started.
+# This tag requires that the tag FULL_PATH_NAMES is set to YES.
+
+STRIP_FROM_PATH =
+
+# The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of the
+# path mentioned in the documentation of a class, which tells the reader which
+# header file to include in order to use a class. If left blank only the name of
+# the header file containing the class definition is used. Otherwise one should
+# specify the list of include paths that are normally passed to the compiler
+# using the -I flag.
+
+STRIP_FROM_INC_PATH =
+
+# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter (but
+# less readable) file names. This can be useful is your file systems doesn't
+# support long names like on DOS, Mac, or CD-ROM.
+# The default value is: NO.
+
+SHORT_NAMES = NO
+
+# If the JAVADOC_AUTOBRIEF tag is set to YES then doxygen will interpret the
+# first line (until the first dot) of a Javadoc-style comment as the brief
+# description. If set to NO, the Javadoc-style will behave just like regular Qt-
+# style comments (thus requiring an explicit @brief command for a brief
+# description.)
+# The default value is: NO.
+
+JAVADOC_AUTOBRIEF = NO
+
+# If the QT_AUTOBRIEF tag is set to YES then doxygen will interpret the first
+# line (until the first dot) of a Qt-style comment as the brief description. If
+# set to NO, the Qt-style will behave just like regular Qt-style comments (thus
+# requiring an explicit \brief command for a brief description.)
+# The default value is: NO.
+
+QT_AUTOBRIEF = NO
+
+# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make doxygen treat a
+# multi-line C++ special comment block (i.e. a block of //! or /// comments) as
+# a brief description. This used to be the default behavior. The new default is
+# to treat a multi-line C++ comment block as a detailed description. Set this
+# tag to YES if you prefer the old behavior instead.
+#
+# Note that setting this tag to YES also means that rational rose comments are
+# not recognized any more.
+# The default value is: NO.
+
+MULTILINE_CPP_IS_BRIEF = YES
+
+# If the INHERIT_DOCS tag is set to YES then an undocumented member inherits the
+# documentation from any documented member that it re-implements.
+# The default value is: YES.
+
+INHERIT_DOCS = NO
+
+# If the SEPARATE_MEMBER_PAGES tag is set to YES, then doxygen will produce a
+# new page for each member. If set to NO, the documentation of a member will be
+# part of the file/class/namespace that contains it.
+# The default value is: NO.
+
+SEPARATE_MEMBER_PAGES = NO
+
+# The TAB_SIZE tag can be used to set the number of spaces in a tab. Doxygen
+# uses this value to replace tabs by spaces in code fragments.
+# Minimum value: 1, maximum value: 16, default value: 4.
+
+TAB_SIZE = 8
+
+# This tag can be used to specify a number of aliases that act as commands in
+# the documentation. An alias has the form:
+# name=value
+# For example adding
+# "sideeffect=@par Side Effects:\n"
+# will allow you to put the command \sideeffect (or @sideeffect) in the
+# documentation, which will result in a user-defined paragraph with heading
+# "Side Effects:". You can put \n's in the value part of an alias to insert
+# newlines.
+
+ALIASES = "token{1}=\1"
+
+# This tag can be used to specify a number of word-keyword mappings (TCL only).
+# A mapping has the form "name=value". For example adding "class=itcl::class"
+# will allow you to use the command class in the itcl::class meaning.
+
+TCL_SUBST =
+
+# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C sources
+# only. Doxygen will then generate output that is more tailored for C. For
+# instance, some of the names that are used will be different. The list of all
+# members will be omitted, etc.
+# The default value is: NO.
+
+OPTIMIZE_OUTPUT_FOR_C = YES
+
+# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java or
+# Python sources only. Doxygen will then generate output that is more tailored
+# for that language. For instance, namespaces will be presented as packages,
+# qualified scopes will look different, etc.
+# The default value is: NO.
+
+OPTIMIZE_OUTPUT_JAVA = NO
+
+# Set the OPTIMIZE_FOR_FORTRAN tag to YES if your project consists of Fortran
+# sources. Doxygen will then generate output that is tailored for Fortran.
+# The default value is: NO.
+
+OPTIMIZE_FOR_FORTRAN = NO
+
+# Set the OPTIMIZE_OUTPUT_VHDL tag to YES if your project consists of VHDL
+# sources. Doxygen will then generate output that is tailored for VHDL.
+# The default value is: NO.
+
+OPTIMIZE_OUTPUT_VHDL = NO
+
+# Doxygen selects the parser to use depending on the extension of the files it
+# parses. With this tag you can assign which parser to use for a given
+# extension. Doxygen has a built-in mapping, but you can override or extend it
+# using this tag. The format is ext=language, where ext is a file extension, and
+# language is one of the parsers supported by doxygen: IDL, Java, Javascript,
+# C#, C, C++, D, PHP, Objective-C, Python, Fortran, VHDL. For instance to make
+# doxygen treat .inc files as Fortran files (default is PHP), and .f files as C
+# (default is Fortran), use: inc=Fortran f=C.
+#
+# Note For files without extension you can use no_extension as a placeholder.
+#
+# Note that for custom extensions you also need to set FILE_PATTERNS otherwise
+# the files are not read by doxygen.
+
+EXTENSION_MAPPING =
+
+# If the MARKDOWN_SUPPORT tag is enabled then doxygen pre-processes all comments
+# according to the Markdown format, which allows for more readable
+# documentation. See http://daringfireball.net/projects/markdown/ for details.
+# The output of markdown processing is further processed by doxygen, so you can
+# mix doxygen, HTML, and XML commands with Markdown formatting. Disable only in
+# case of backward compatibilities issues.
+# The default value is: YES.
+
+MARKDOWN_SUPPORT = YES
+
+# When enabled doxygen tries to link words that correspond to documented
+# classes, or namespaces to their corresponding documentation. Such a link can
+# be prevented in individual cases by by putting a % sign in front of the word
+# or globally by setting AUTOLINK_SUPPORT to NO.
+# The default value is: YES.
+
+AUTOLINK_SUPPORT = YES
+
+# If you use STL classes (i.e. std::string, std::vector, etc.) but do not want
+# to include (a tag file for) the STL sources as input, then you should set this
+# tag to YES in order to let doxygen match functions declarations and
+# definitions whose arguments contain STL classes (e.g. func(std::string);
+# versus func(std::string) {}). This also make the inheritance and collaboration
+# diagrams that involve STL classes more complete and accurate.
+# The default value is: NO.
+
+BUILTIN_STL_SUPPORT = NO
+
+# If you use Microsoft's C++/CLI language, you should set this option to YES to
+# enable parsing support.
+# The default value is: NO.
+
+CPP_CLI_SUPPORT = NO
+
+# Set the SIP_SUPPORT tag to YES if your project consists of sip (see:
+# http://www.riverbankcomputing.co.uk/software/sip/intro) sources only. Doxygen
+# will parse them like normal C++ but will assume all classes use public instead
+# of private inheritance when no explicit protection keyword is present.
+# The default value is: NO.
+
+SIP_SUPPORT = NO
+
+# For Microsoft's IDL there are propget and propput attributes to indicate
+# getter and setter methods for a property. Setting this option to YES will make
+# doxygen to replace the get and set methods by a property in the documentation.
+# This will only work if the methods are indeed getting or setting a simple
+# type. If this is not the case, or you want to show the methods anyway, you
+# should set this option to NO.
+# The default value is: YES.
+
+IDL_PROPERTY_SUPPORT = YES
+
+# If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC
+# tag is set to YES, then doxygen will reuse the documentation of the first
+# member in the group (if any) for the other members of the group. By default
+# all members of a group must be documented explicitly.
+# The default value is: NO.
+
+DISTRIBUTE_GROUP_DOC = NO
+
+# Set the SUBGROUPING tag to YES to allow class member groups of the same type
+# (for instance a group of public functions) to be put as a subgroup of that
+# type (e.g. under the Public Functions section). Set it to NO to prevent
+# subgrouping. Alternatively, this can be done per class using the
+# \nosubgrouping command.
+# The default value is: YES.
+
+SUBGROUPING = YES
+
+# When the INLINE_GROUPED_CLASSES tag is set to YES, classes, structs and unions
+# are shown inside the group in which they are included (e.g. using \ingroup)
+# instead of on a separate page (for HTML and Man pages) or section (for LaTeX
+# and RTF).
+#
+# Note that this feature does not work in combination with
+# SEPARATE_MEMBER_PAGES.
+# The default value is: NO.
+
+INLINE_GROUPED_CLASSES = NO
+
+# When the INLINE_SIMPLE_STRUCTS tag is set to YES, structs, classes, and unions
+# with only public data fields or simple typedef fields will be shown inline in
+# the documentation of the scope in which they are defined (i.e. file,
+# namespace, or group documentation), provided this scope is documented. If set
+# to NO, structs, classes, and unions are shown on a separate page (for HTML and
+# Man pages) or section (for LaTeX and RTF).
+# The default value is: NO.
+
+INLINE_SIMPLE_STRUCTS = NO
+
+# When TYPEDEF_HIDES_STRUCT tag is enabled, a typedef of a struct, union, or
+# enum is documented as struct, union, or enum with the name of the typedef. So
+# typedef struct TypeS {} TypeT, will appear in the documentation as a struct
+# with name TypeT. When disabled the typedef will appear as a member of a file,
+# namespace, or class. And the struct will be named TypeS. This can typically be
+# useful for C code in case the coding convention dictates that all compound
+# types are typedef'ed and only the typedef is referenced, never the tag name.
+# The default value is: NO.
+
+TYPEDEF_HIDES_STRUCT = YES
+
+# The size of the symbol lookup cache can be set using LOOKUP_CACHE_SIZE. This
+# cache is used to resolve symbols given their name and scope. Since this can be
+# an expensive process and often the same symbol appears multiple times in the
+# code, doxygen keeps a cache of pre-resolved symbols. If the cache is too small
+# doxygen will become slower. If the cache is too large, memory is wasted. The
+# cache size is given by this formula: 2^(16+LOOKUP_CACHE_SIZE). The valid range
+# is 0..9, the default is 0, corresponding to a cache size of 2^16=65536
+# symbols. At the end of a run doxygen will report the cache usage and suggest
+# the optimal cache size from a speed point of view.
+# Minimum value: 0, maximum value: 9, default value: 0.
+
+LOOKUP_CACHE_SIZE = 0
+
+#---------------------------------------------------------------------------
+# Build related configuration options
+#---------------------------------------------------------------------------
+
+# If the EXTRACT_ALL tag is set to YES doxygen will assume all entities in
+# documentation are documented, even if no documentation was available. Private
+# class members and static file members will be hidden unless the
+# EXTRACT_PRIVATE respectively EXTRACT_STATIC tags are set to YES.
+# Note: This will also disable the warnings about undocumented members that are
+# normally produced when WARNINGS is set to YES.
+# The default value is: NO.
+
+EXTRACT_ALL = YES
+
+# If the EXTRACT_PRIVATE tag is set to YES all private members of a class will
+# be included in the documentation.
+# The default value is: NO.
+
+EXTRACT_PRIVATE = YES
+
+# If the EXTRACT_PACKAGE tag is set to YES all members with package or internal
+# scope will be included in the documentation.
+# The default value is: NO.
+
+EXTRACT_PACKAGE = NO
+
+# If the EXTRACT_STATIC tag is set to YES all static members of a file will be
+# included in the documentation.
+# The default value is: NO.
+
+EXTRACT_STATIC = YES
+
+# If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs) defined
+# locally in source files will be included in the documentation. If set to NO
+# only classes defined in header files are included. Does not have any effect
+# for Java sources.
+# The default value is: YES.
+
+EXTRACT_LOCAL_CLASSES = YES
+
+# This flag is only useful for Objective-C code. When set to YES local methods,
+# which are defined in the implementation section but not in the interface are
+# included in the documentation. If set to NO only methods in the interface are
+# included.
+# The default value is: NO.
+
+EXTRACT_LOCAL_METHODS = NO
+
+# If this flag is set to YES, the members of anonymous namespaces will be
+# extracted and appear in the documentation as a namespace called
+# 'anonymous_namespace{file}', where file will be replaced with the base name of
+# the file that contains the anonymous namespace. By default anonymous namespace
+# are hidden.
+# The default value is: NO.
+
+EXTRACT_ANON_NSPACES = NO
+
+# If the HIDE_UNDOC_MEMBERS tag is set to YES, doxygen will hide all
+# undocumented members inside documented classes or files. If set to NO these
+# members will be included in the various overviews, but no documentation
+# section is generated. This option has no effect if EXTRACT_ALL is enabled.
+# The default value is: NO.
+
+HIDE_UNDOC_MEMBERS = NO
+
+# If the HIDE_UNDOC_CLASSES tag is set to YES, doxygen will hide all
+# undocumented classes that are normally visible in the class hierarchy. If set
+# to NO these classes will be included in the various overviews. This option has
+# no effect if EXTRACT_ALL is enabled.
+# The default value is: NO.
+
+HIDE_UNDOC_CLASSES = NO
+
+# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, doxygen will hide all friend
+# (class|struct|union) declarations. If set to NO these declarations will be
+# included in the documentation.
+# The default value is: NO.
+
+HIDE_FRIEND_COMPOUNDS = NO
+
+# If the HIDE_IN_BODY_DOCS tag is set to YES, doxygen will hide any
+# documentation blocks found inside the body of a function. If set to NO these
+# blocks will be appended to the function's detailed documentation block.
+# The default value is: NO.
+
+HIDE_IN_BODY_DOCS = NO
+
+# The INTERNAL_DOCS tag determines if documentation that is typed after a
+# \internal command is included. If the tag is set to NO then the documentation
+# will be excluded. Set it to YES to include the internal documentation.
+# The default value is: NO.
+
+INTERNAL_DOCS = NO
+
+# If the CASE_SENSE_NAMES tag is set to NO then doxygen will only generate file
+# names in lower-case letters. If set to YES upper-case letters are also
+# allowed. This is useful if you have classes or files whose names only differ
+# in case and if your file system supports case sensitive file names. Windows
+# and Mac users are advised to set this option to NO.
+# The default value is: system dependent.
+
+CASE_SENSE_NAMES = YES
+
+# If the HIDE_SCOPE_NAMES tag is set to NO then doxygen will show members with
+# their full class and namespace scopes in the documentation. If set to YES the
+# scope will be hidden.
+# The default value is: NO.
+
+HIDE_SCOPE_NAMES = NO
+
+# If the SHOW_INCLUDE_FILES tag is set to YES then doxygen will put a list of
+# the files that are included by a file in the documentation of that file.
+# The default value is: YES.
+
+SHOW_INCLUDE_FILES = NO
+
+
+SHOW_GROUPED_MEMB_INC = NO
+
+# If the FORCE_LOCAL_INCLUDES tag is set to YES then doxygen will list include
+# files with double quotes in the documentation rather than with sharp brackets.
+# The default value is: NO.
+
+FORCE_LOCAL_INCLUDES = NO
+
+# If the INLINE_INFO tag is set to YES then a tag [inline] is inserted in the
+# documentation for inline members.
+# The default value is: YES.
+
+INLINE_INFO = YES
+
+# If the SORT_MEMBER_DOCS tag is set to YES then doxygen will sort the
+# (detailed) documentation of file and class members alphabetically by member
+# name. If set to NO the members will appear in declaration order.
+# The default value is: YES.
+
+SORT_MEMBER_DOCS = YES
+
+# If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the brief
+# descriptions of file, namespace and class members alphabetically by member
+# name. If set to NO the members will appear in declaration order. Note that
+# this will also influence the order of the classes in the class list.
+# The default value is: NO.
+
+SORT_BRIEF_DOCS = NO
+
+# If the SORT_MEMBERS_CTORS_1ST tag is set to YES then doxygen will sort the
+# (brief and detailed) documentation of class members so that constructors and
+# destructors are listed first. If set to NO the constructors will appear in the
+# respective orders defined by SORT_BRIEF_DOCS and SORT_MEMBER_DOCS.
+# Note: If SORT_BRIEF_DOCS is set to NO this option is ignored for sorting brief
+# member documentation.
+# Note: If SORT_MEMBER_DOCS is set to NO this option is ignored for sorting
+# detailed member documentation.
+# The default value is: NO.
+
+SORT_MEMBERS_CTORS_1ST = NO
+
+# If the SORT_GROUP_NAMES tag is set to YES then doxygen will sort the hierarchy
+# of group names into alphabetical order. If set to NO the group names will
+# appear in their defined order.
+# The default value is: NO.
+
+SORT_GROUP_NAMES = NO
+
+# If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be sorted by
+# fully-qualified names, including namespaces. If set to NO, the class list will
+# be sorted only by class name, not including the namespace part.
+# Note: This option is not very useful if HIDE_SCOPE_NAMES is set to YES.
+# Note: This option applies only to the class list, not to the alphabetical
+# list.
+# The default value is: NO.
+
+SORT_BY_SCOPE_NAME = NO
+
+# If the STRICT_PROTO_MATCHING option is enabled and doxygen fails to do proper
+# type resolution of all parameters of a function it will reject a match between
+# the prototype and the implementation of a member function even if there is
+# only one candidate or it is obvious which candidate to choose by doing a
+# simple string match. By disabling STRICT_PROTO_MATCHING doxygen will still
+# accept a match between prototype and implementation in such cases.
+# The default value is: NO.
+
+STRICT_PROTO_MATCHING = NO
+
+# The GENERATE_TODOLIST tag can be used to enable ( YES) or disable ( NO) the
+# todo list. This list is created by putting \todo commands in the
+# documentation.
+# The default value is: YES.
+
+GENERATE_TODOLIST = YES
+
+# The GENERATE_TESTLIST tag can be used to enable ( YES) or disable ( NO) the
+# test list. This list is created by putting \test commands in the
+# documentation.
+# The default value is: YES.
+
+GENERATE_TESTLIST = NO
+
+# The GENERATE_BUGLIST tag can be used to enable ( YES) or disable ( NO) the bug
+# list. This list is created by putting \bug commands in the documentation.
+# The default value is: YES.
+
+GENERATE_BUGLIST = NO
+
+# The GENERATE_DEPRECATEDLIST tag can be used to enable ( YES) or disable ( NO)
+# the deprecated list. This list is created by putting \deprecated commands in
+# the documentation.
+# The default value is: YES.
+
+GENERATE_DEPRECATEDLIST= YES
+
+# The ENABLED_SECTIONS tag can be used to enable conditional documentation
+# sections, marked by \if ... \endif and \cond
+# ... \endcond blocks.
+
+ENABLED_SECTIONS =
+
+# The MAX_INITIALIZER_LINES tag determines the maximum number of lines that the
+# initial value of a variable or macro / define can have for it to appear in the
+# documentation. If the initializer consists of more lines than specified here
+# it will be hidden. Use a value of 0 to hide initializers completely. The
+# appearance of the value of individual variables and macros / defines can be
+# controlled using \showinitializer or \hideinitializer command in the
+# documentation regardless of this setting.
+# Minimum value: 0, maximum value: 10000, default value: 30.
+
+MAX_INITIALIZER_LINES = 1
+
+# Set the SHOW_USED_FILES tag to NO to disable the list of files generated at
+# the bottom of the documentation of classes and structs. If set to YES the list
+# will mention the files that were used to generate the documentation.
+# The default value is: YES.
+
+SHOW_USED_FILES = NO
+
+# Set the SHOW_FILES tag to NO to disable the generation of the Files page. This
+# will remove the Files entry from the Quick Index and from the Folder Tree View
+# (if specified).
+# The default value is: YES.
+
+SHOW_FILES = YES
+
+# Set the SHOW_NAMESPACES tag to NO to disable the generation of the Namespaces
+# page. This will remove the Namespaces entry from the Quick Index and from the
+# Folder Tree View (if specified).
+# The default value is: YES.
+
+SHOW_NAMESPACES = YES
+
+# The FILE_VERSION_FILTER tag can be used to specify a program or script that
+# doxygen should invoke to get the current version for each file (typically from
+# the version control system). Doxygen will invoke the program by executing (via
+# popen()) the command command input-file, where command is the value of the
+# FILE_VERSION_FILTER tag, and input-file is the name of an input file provided
+# by doxygen. Whatever the program writes to standard output is used as the file
+# version. For an example see the documentation.
+
+FILE_VERSION_FILTER =
+
+# The LAYOUT_FILE tag can be used to specify a layout file which will be parsed
+# by doxygen. The layout file controls the global structure of the generated
+# output files in an output format independent way. To create the layout file
+# that represents doxygen's defaults, run doxygen with the -l option. You can
+# optionally specify a file name after the option, if omitted DoxygenLayout.xml
+# will be used as the name of the layout file.
+#
+# Note that if you run doxygen from a directory containing a file called
+# DoxygenLayout.xml, doxygen will parse it automatically even if the LAYOUT_FILE
+# tag is left empty.
+
+LAYOUT_FILE = ../Doxygen_Templates/DoxygenLayout_forUser.xml
+
+# The CITE_BIB_FILES tag can be used to specify one or more bib files containing
+# the reference definitions. This must be a list of .bib files. The .bib
+# extension is automatically appended if omitted. This requires the bibtex tool
+# to be installed. See also http://en.wikipedia.org/wiki/BibTeX for more info.
+# For LaTeX the style of the bibliography can be controlled using
+# LATEX_BIB_STYLE. To use this feature you need bibtex and perl available in the
+# search path. Do not use file names with spaces, bibtex cannot handle them. See
+# also \cite for info how to create references.
+
+CITE_BIB_FILES =
+
+#---------------------------------------------------------------------------
+# Configuration options related to warning and progress messages
+#---------------------------------------------------------------------------
+
+# The QUIET tag can be used to turn on/off the messages that are generated to
+# standard output by doxygen. If QUIET is set to YES this implies that the
+# messages are off.
+# The default value is: NO.
+
+QUIET = YES
+
+# The WARNINGS tag can be used to turn on/off the warning messages that are
+# generated to standard error ( stderr) by doxygen. If WARNINGS is set to YES
+# this implies that the warnings are on.
+#
+# Tip: Turn warnings on while writing the documentation.
+# The default value is: YES.
+
+WARNINGS = YES
+
+# If the WARN_IF_UNDOCUMENTED tag is set to YES, then doxygen will generate
+# warnings for undocumented members. If EXTRACT_ALL is set to YES then this flag
+# will automatically be disabled.
+# The default value is: YES.
+
+WARN_IF_UNDOCUMENTED = YES
+
+# If the WARN_IF_DOC_ERROR tag is set to YES, doxygen will generate warnings for
+# potential errors in the documentation, such as not documenting some parameters
+# in a documented function, or documenting parameters that don't exist or using
+# markup commands wrongly.
+# The default value is: YES.
+
+WARN_IF_DOC_ERROR = YES
+
+# This WARN_NO_PARAMDOC option can be enabled to get warnings for functions that
+# are documented, but have no documentation for their parameters or return
+# value. If set to NO doxygen will only warn about wrong or incomplete parameter
+# documentation, but not about the absence of documentation.
+# The default value is: NO.
+
+WARN_NO_PARAMDOC = YES
+
+# The WARN_FORMAT tag determines the format of the warning messages that doxygen
+# can produce. The string should contain the $file, $line, and $text tags, which
+# will be replaced by the file and line number from which the warning originated
+# and the warning text. Optionally the format may contain $version, which will
+# be replaced by the version of the file (if it could be obtained via
+# FILE_VERSION_FILTER)
+# The default value is: $file:$line: $text.
+
+WARN_FORMAT = "$file:$line: $text"
+
+# The WARN_LOGFILE tag can be used to specify a file to which warning and error
+# messages should be written. If left blank the output is written to standard
+# error (stderr).
+
+WARN_LOGFILE =
+
+#---------------------------------------------------------------------------
+# Configuration options related to the input files
+#---------------------------------------------------------------------------
+
+# The INPUT tag is used to specify the files and/or directories that contain
+# documented source files. You may enter file names like myfile.cpp or
+# directories like /usr/src/myproject. Separate the files or directories with
+# spaces.
+# Note: If this tag is empty the current directory is searched.
+
+INPUT = src/Overview.txt \
+ src/XML_Format.txt \
+ src/GenDataModel.txt \
+
+# This tag can be used to specify the character encoding of the source files
+# that doxygen parses. Internally doxygen uses the UTF-8 encoding. Doxygen uses
+# libiconv (or the iconv built into libc) for the transcoding. See the libiconv
+# documentation (see: http://www.gnu.org/software/libiconv) for the list of
+# possible encodings.
+# The default value is: UTF-8.
+
+INPUT_ENCODING = UTF-8
+
+# If the value of the INPUT tag contains directories, you can use the
+# FILE_PATTERNS tag to specify one or more wildcard patterns (like *.cpp and
+# *.h) to filter out the source-files in the directories. If left blank the
+# following patterns are tested:*.c, *.cc, *.cxx, *.cpp, *.c++, *.java, *.ii,
+# *.ixx, *.ipp, *.i++, *.inl, *.idl, *.ddl, *.odl, *.h, *.hh, *.hxx, *.hpp,
+# *.h++, *.cs, *.d, *.php, *.php4, *.php5, *.phtml, *.inc, *.m, *.markdown,
+# *.md, *.mm, *.dox, *.py, *.f90, *.f, *.for, *.tcl, *.vhd, *.vhdl, *.ucf,
+# *.qsf, *.as and *.js.
+
+FILE_PATTERNS =
+
+# The RECURSIVE tag can be used to specify whether or not subdirectories should
+# be searched for input files as well.
+# The default value is: NO.
+
+RECURSIVE = NO
+
+# The EXCLUDE tag can be used to specify files and/or directories that should be
+# excluded from the INPUT source files. This way you can easily exclude a
+# subdirectory from a directory tree whose root is specified with the INPUT tag.
+#
+# Note that relative paths are relative to the directory from which doxygen is
+# run.
+
+EXCLUDE = system*.c \
+ startup*.s \
+ src/exclude/
+
+# The EXCLUDE_SYMLINKS tag can be used to select whether or not files or
+# directories that are symbolic links (a Unix file system feature) are excluded
+# from the input.
+# The default value is: NO.
+
+EXCLUDE_SYMLINKS = NO
+
+# If the value of the INPUT tag contains directories, you can use the
+# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude
+# certain files from those directories.
+#
+# Note that the wildcards are matched against the file with absolute path, so to
+# exclude all test directories for example use the pattern */test/*
+
+EXCLUDE_PATTERNS =
+
+# The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names
+# (namespaces, classes, functions, etc.) that should be excluded from the
+# output. The symbol name can be a fully qualified name, a word, or if the
+# wildcard * is used, a substring. Examples: ANamespace, AClass,
+# AClass::ANamespace, ANamespace::*Test
+#
+# Note that the wildcards are matched against the file with absolute path, so to
+# exclude all test directories use the pattern */test/*
+
+EXCLUDE_SYMBOLS =
+
+# The EXAMPLE_PATH tag can be used to specify one or more files or directories
+# that contain example code fragments that are included (see the \include
+# command).
+
+EXAMPLE_PATH =
+
+# If the value of the EXAMPLE_PATH tag contains directories, you can use the
+# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp and
+# *.h) to filter out the source-files in the directories. If left blank all
+# files are included.
+
+EXAMPLE_PATTERNS = *
+
+# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be
+# searched for input files to be used with the \include or \dontinclude commands
+# irrespective of the value of the RECURSIVE tag.
+# The default value is: NO.
+
+EXAMPLE_RECURSIVE = NO
+
+# The IMAGE_PATH tag can be used to specify one or more files or directories
+# that contain images that are to be included in the documentation (see the
+# \image command).
+
+IMAGE_PATH = src/images
+
+# The INPUT_FILTER tag can be used to specify a program that doxygen should
+# invoke to filter for each input file. Doxygen will invoke the filter program
+# by executing (via popen()) the command:
+#
+#
+#
+# where is the value of the INPUT_FILTER tag, and is the
+# name of an input file. Doxygen will then use the output that the filter
+# program writes to standard output. If FILTER_PATTERNS is specified, this tag
+# will be ignored.
+#
+# Note that the filter must not add or remove lines; it is applied before the
+# code is scanned, but not when the output code is generated. If lines are added
+# or removed, the anchors will not be placed correctly.
+
+INPUT_FILTER =
+
+# The FILTER_PATTERNS tag can be used to specify filters on a per file pattern
+# basis. Doxygen will compare the file name with each pattern and apply the
+# filter if there is a match. The filters are a list of the form: pattern=filter
+# (like *.cpp=my_cpp_filter). See INPUT_FILTER for further information on how
+# filters are used. If the FILTER_PATTERNS tag is empty or if none of the
+# patterns match the file name, INPUT_FILTER is applied.
+
+FILTER_PATTERNS =
+
+# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using
+# INPUT_FILTER ) will also be used to filter the input files that are used for
+# producing the source files to browse (i.e. when SOURCE_BROWSER is set to YES).
+# The default value is: NO.
+
+FILTER_SOURCE_FILES = NO
+
+# The FILTER_SOURCE_PATTERNS tag can be used to specify source filters per file
+# pattern. A pattern will override the setting for FILTER_PATTERN (if any) and
+# it is also possible to disable source filtering for a specific pattern using
+# *.ext= (so without naming a filter).
+# This tag requires that the tag FILTER_SOURCE_FILES is set to YES.
+
+FILTER_SOURCE_PATTERNS =
+
+# If the USE_MDFILE_AS_MAINPAGE tag refers to the name of a markdown file that
+# is part of the input, its contents will be placed on the main page
+# (index.html). This can be useful if you have a project on for instance GitHub
+# and want to reuse the introduction page also for the doxygen output.
+
+USE_MDFILE_AS_MAINPAGE =
+
+#---------------------------------------------------------------------------
+# Configuration options related to source browsing
+#---------------------------------------------------------------------------
+
+# If the SOURCE_BROWSER tag is set to YES then a list of source files will be
+# generated. Documented entities will be cross-referenced with these sources.
+#
+# Note: To get rid of all source code in the generated output, make sure that
+# also VERBATIM_HEADERS is set to NO.
+# The default value is: NO.
+
+SOURCE_BROWSER = NO
+
+# Setting the INLINE_SOURCES tag to YES will include the body of functions,
+# classes and enums directly into the documentation.
+# The default value is: NO.
+
+INLINE_SOURCES = NO
+
+# Setting the STRIP_CODE_COMMENTS tag to YES will instruct doxygen to hide any
+# special comment blocks from generated source code fragments. Normal C, C++ and
+# Fortran comments will always remain visible.
+# The default value is: YES.
+
+STRIP_CODE_COMMENTS = YES
+
+# If the REFERENCED_BY_RELATION tag is set to YES then for each documented
+# function all documented functions referencing it will be listed.
+# The default value is: NO.
+
+REFERENCED_BY_RELATION = YES
+
+# If the REFERENCES_RELATION tag is set to YES then for each documented function
+# all documented entities called/used by that function will be listed.
+# The default value is: NO.
+
+REFERENCES_RELATION = YES
+
+# If the REFERENCES_LINK_SOURCE tag is set to YES and SOURCE_BROWSER tag is set
+# to YES, then the hyperlinks from functions in REFERENCES_RELATION and
+# REFERENCED_BY_RELATION lists will link to the source code. Otherwise they will
+# link to the documentation.
+# The default value is: YES.
+
+REFERENCES_LINK_SOURCE = NO
+
+# If SOURCE_TOOLTIPS is enabled (the default) then hovering a hyperlink in the
+# source code will show a tooltip with additional information such as prototype,
+# brief description and links to the definition and documentation. Since this
+# will make the HTML file larger and loading of large files a bit slower, you
+# can opt to disable this feature.
+# The default value is: YES.
+# This tag requires that the tag SOURCE_BROWSER is set to YES.
+
+SOURCE_TOOLTIPS = YES
+
+# If the USE_HTAGS tag is set to YES then the references to source code will
+# point to the HTML generated by the htags(1) tool instead of doxygen built-in
+# source browser. The htags tool is part of GNU's global source tagging system
+# (see http://www.gnu.org/software/global/global.html). You will need version
+# 4.8.6 or higher.
+#
+# To use it do the following:
+# - Install the latest version of global
+# - Enable SOURCE_BROWSER and USE_HTAGS in the config file
+# - Make sure the INPUT points to the root of the source tree
+# - Run doxygen as normal
+#
+# Doxygen will invoke htags (and that will in turn invoke gtags), so these
+# tools must be available from the command line (i.e. in the search path).
+#
+# The result: instead of the source browser generated by doxygen, the links to
+# source code will now point to the output of htags.
+# The default value is: NO.
+# This tag requires that the tag SOURCE_BROWSER is set to YES.
+
+USE_HTAGS = NO
+
+# If the VERBATIM_HEADERS tag is set the YES then doxygen will generate a
+# verbatim copy of the header file for each class for which an include is
+# specified. Set to NO to disable this.
+# See also: Section \class.
+# The default value is: YES.
+
+VERBATIM_HEADERS = NO
+
+# If the CLANG_ASSISTED_PARSING tag is set to YES, then doxygen will use the
+# clang parser (see: http://clang.llvm.org/) for more acurate parsing at the
+# cost of reduced performance. This can be particularly helpful with template
+# rich C++ code for which doxygen's built-in parser lacks the necessary type
+# information.
+# Note: The availability of this option depends on whether or not doxygen was
+# compiled with the --with-libclang option.
+# The default value is: NO.
+
+CLANG_ASSISTED_PARSING = NO
+
+# If clang assisted parsing is enabled you can provide the compiler with command
+# line options that you would normally use when invoking the compiler. Note that
+# the include paths will already be set by doxygen for the files and directories
+# specified with INPUT and INCLUDE_PATH.
+# This tag requires that the tag CLANG_ASSISTED_PARSING is set to YES.
+
+CLANG_OPTIONS =
+
+#---------------------------------------------------------------------------
+# Configuration options related to the alphabetical class index
+#---------------------------------------------------------------------------
+
+# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index of all
+# compounds will be generated. Enable this if the project contains a lot of
+# classes, structs, unions or interfaces.
+# The default value is: YES.
+
+ALPHABETICAL_INDEX = NO
+
+# The COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns in
+# which the alphabetical index list will be split.
+# Minimum value: 1, maximum value: 20, default value: 5.
+# This tag requires that the tag ALPHABETICAL_INDEX is set to YES.
+
+COLS_IN_ALPHA_INDEX = 5
+
+# In case all classes in a project start with a common prefix, all classes will
+# be put under the same header in the alphabetical index. The IGNORE_PREFIX tag
+# can be used to specify a prefix (or a list of prefixes) that should be ignored
+# while generating the index headers.
+# This tag requires that the tag ALPHABETICAL_INDEX is set to YES.
+
+IGNORE_PREFIX =
+
+#---------------------------------------------------------------------------
+# Configuration options related to the HTML output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_HTML tag is set to YES doxygen will generate HTML output
+# The default value is: YES.
+
+GENERATE_HTML = YES
+
+# The HTML_OUTPUT tag is used to specify where the HTML docs will be put. If a
+# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of
+# it.
+# The default directory is: html.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_OUTPUT = html
+
+# The HTML_FILE_EXTENSION tag can be used to specify the file extension for each
+# generated HTML page (for example: .htm, .php, .asp).
+# The default value is: .html.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_FILE_EXTENSION = .html
+
+# The HTML_HEADER tag can be used to specify a user-defined HTML header file for
+# each generated HTML page. If the tag is left blank doxygen will generate a
+# standard header.
+#
+# To get valid HTML the header file that includes any scripts and style sheets
+# that doxygen needs, which is dependent on the configuration options used (e.g.
+# the setting GENERATE_TREEVIEW). It is highly recommended to start with a
+# default header using
+# doxygen -w html new_header.html new_footer.html new_stylesheet.css
+# YourConfigFile
+# and then modify the file new_header.html. See also section "Doxygen usage"
+# for information on how to generate the default header that doxygen normally
+# uses.
+# Note: The header is subject to change so you typically have to regenerate the
+# default header when upgrading to a newer version of doxygen. For a description
+# of the possible markers and block names see the documentation.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_HEADER = ../Doxygen_Templates/cmsis_header.html
+
+# The HTML_FOOTER tag can be used to specify a user-defined HTML footer for each
+# generated HTML page. If the tag is left blank doxygen will generate a standard
+# footer. See HTML_HEADER for more information on how to generate a default
+# footer and what special commands can be used inside the footer. See also
+# section "Doxygen usage" for information on how to generate the default footer
+# that doxygen normally uses.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_FOOTER = ../Doxygen_Templates/cmsis_footer.html
+
+# The HTML_STYLESHEET tag can be used to specify a user-defined cascading style
+# sheet that is used by each HTML page. It can be used to fine-tune the look of
+# the HTML output. If left blank doxygen will generate a default style sheet.
+# See also section "Doxygen usage" for information on how to generate the style
+# sheet that doxygen normally uses.
+# Note: It is recommended to use HTML_EXTRA_STYLESHEET instead of this tag, as
+# it is more robust and this tag (HTML_STYLESHEET) will in the future become
+# obsolete.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_STYLESHEET =
+
+# The HTML_EXTRA_STYLESHEET tag can be used to specify an additional user-
+# defined cascading style sheet that is included after the standard style sheets
+# created by doxygen. Using this option one can overrule certain style aspects.
+# This is preferred over using HTML_STYLESHEET since it does not replace the
+# standard style sheet and is therefor more robust against future updates.
+# Doxygen will copy the style sheet file to the output directory. For an example
+# see the documentation.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_EXTRA_STYLESHEET = ../Doxygen_Templates/cmsis.css
+
+# The HTML_EXTRA_FILES tag can be used to specify one or more extra images or
+# other source files which should be copied to the HTML output directory. Note
+# that these files will be copied to the base HTML output directory. Use the
+# $relpath^ marker in the HTML_HEADER and/or HTML_FOOTER files to load these
+# files. In the HTML_STYLESHEET file, use the file name only. Also note that the
+# files will be copied as-is; there are no commands or markers available.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_EXTRA_FILES = ../Doxygen_Templates/tabs.css \
+ ../Doxygen_Templates/tab_topnav.png \
+ ../Doxygen_Templates/search.css \
+ ../Doxygen_Templates/check.png \
+ ../Doxygen_Templates/printComponentTabs.js
+
+# The HTML_COLORSTYLE_HUE tag controls the color of the HTML output. Doxygen
+# will adjust the colors in the stylesheet and background images according to
+# this color. Hue is specified as an angle on a colorwheel, see
+# http://en.wikipedia.org/wiki/Hue for more information. For instance the value
+# 0 represents red, 60 is yellow, 120 is green, 180 is cyan, 240 is blue, 300
+# purple, and 360 is red again.
+# Minimum value: 0, maximum value: 359, default value: 220.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_COLORSTYLE_HUE = 220
+
+# The HTML_COLORSTYLE_SAT tag controls the purity (or saturation) of the colors
+# in the HTML output. For a value of 0 the output will use grayscales only. A
+# value of 255 will produce the most vivid colors.
+# Minimum value: 0, maximum value: 255, default value: 100.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_COLORSTYLE_SAT = 100
+
+# The HTML_COLORSTYLE_GAMMA tag controls the gamma correction applied to the
+# luminance component of the colors in the HTML output. Values below 100
+# gradually make the output lighter, whereas values above 100 make the output
+# darker. The value divided by 100 is the actual gamma applied, so 80 represents
+# a gamma of 0.8, The value 220 represents a gamma of 2.2, and 100 does not
+# change the gamma.
+# Minimum value: 40, maximum value: 240, default value: 80.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_COLORSTYLE_GAMMA = 80
+
+# If the HTML_TIMESTAMP tag is set to YES then the footer of each generated HTML
+# page will contain the date and time when the page was generated. Setting this
+# to NO can help when comparing the output of multiple runs.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_TIMESTAMP = YES
+
+# If the HTML_DYNAMIC_SECTIONS tag is set to YES then the generated HTML
+# documentation will contain sections that can be hidden and shown after the
+# page has loaded.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_DYNAMIC_SECTIONS = NO
+
+# With HTML_INDEX_NUM_ENTRIES one can control the preferred number of entries
+# shown in the various tree structured indices initially; the user can expand
+# and collapse entries dynamically later on. Doxygen will expand the tree to
+# such a level that at most the specified number of entries are visible (unless
+# a fully collapsed tree already exceeds this amount). So setting the number of
+# entries 1 will produce a full collapsed tree by default. 0 is a special value
+# representing an infinite number of entries and will result in a full expanded
+# tree by default.
+# Minimum value: 0, maximum value: 9999, default value: 100.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_INDEX_NUM_ENTRIES = 100
+
+# If the GENERATE_DOCSET tag is set to YES, additional index files will be
+# generated that can be used as input for Apple's Xcode 3 integrated development
+# environment (see: http://developer.apple.com/tools/xcode/), introduced with
+# OSX 10.5 (Leopard). To create a documentation set, doxygen will generate a
+# Makefile in the HTML output directory. Running make will produce the docset in
+# that directory and running make install will install the docset in
+# ~/Library/Developer/Shared/Documentation/DocSets so that Xcode will find it at
+# startup. See http://developer.apple.com/tools/creatingdocsetswithdoxygen.html
+# for more information.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+GENERATE_DOCSET = NO
+
+# This tag determines the name of the docset feed. A documentation feed provides
+# an umbrella under which multiple documentation sets from a single provider
+# (such as a company or product suite) can be grouped.
+# The default value is: Doxygen generated docs.
+# This tag requires that the tag GENERATE_DOCSET is set to YES.
+
+DOCSET_FEEDNAME = "Doxygen generated docs"
+
+# This tag specifies a string that should uniquely identify the documentation
+# set bundle. This should be a reverse domain-name style string, e.g.
+# com.mycompany.MyDocSet. Doxygen will append .docset to the name.
+# The default value is: org.doxygen.Project.
+# This tag requires that the tag GENERATE_DOCSET is set to YES.
+
+DOCSET_BUNDLE_ID = org.doxygen.Project
+
+# The DOCSET_PUBLISHER_ID tag specifies a string that should uniquely identify
+# the documentation publisher. This should be a reverse domain-name style
+# string, e.g. com.mycompany.MyDocSet.documentation.
+# The default value is: org.doxygen.Publisher.
+# This tag requires that the tag GENERATE_DOCSET is set to YES.
+
+DOCSET_PUBLISHER_ID = org.doxygen.Publisher
+
+# The DOCSET_PUBLISHER_NAME tag identifies the documentation publisher.
+# The default value is: Publisher.
+# This tag requires that the tag GENERATE_DOCSET is set to YES.
+
+DOCSET_PUBLISHER_NAME = Publisher
+
+# If the GENERATE_HTMLHELP tag is set to YES then doxygen generates three
+# additional HTML index files: index.hhp, index.hhc, and index.hhk. The
+# index.hhp is a project file that can be read by Microsoft's HTML Help Workshop
+# (see: http://www.microsoft.com/en-us/download/details.aspx?id=21138) on
+# Windows.
+#
+# The HTML Help Workshop contains a compiler that can convert all HTML output
+# generated by doxygen into a single compiled HTML file (.chm). Compiled HTML
+# files are now used as the Windows 98 help format, and will replace the old
+# Windows help format (.hlp) on all Windows platforms in the future. Compressed
+# HTML files also contain an index, a table of contents, and you can search for
+# words in the documentation. The HTML workshop also contains a viewer for
+# compressed HTML files.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+GENERATE_HTMLHELP = NO
+
+# The CHM_FILE tag can be used to specify the file name of the resulting .chm
+# file. You can add a path in front of the file if the result should not be
+# written to the html output directory.
+# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
+
+CHM_FILE = CMSIS_Core.chm
+
+# The HHC_LOCATION tag can be used to specify the location (absolute path
+# including file name) of the HTML help compiler ( hhc.exe). If non-empty
+# doxygen will try to run the HTML help compiler on the generated index.hhp.
+# The file has to be specified with full path.
+# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
+
+HHC_LOCATION = "C:/Program Files/HTML Help Workshop/hhc.exe"
+
+# The GENERATE_CHI flag controls if a separate .chi index file is generated (
+# YES) or that it should be included in the master .chm file ( NO).
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
+
+GENERATE_CHI = NO
+
+# The CHM_INDEX_ENCODING is used to encode HtmlHelp index ( hhk), content ( hhc)
+# and project file content.
+# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
+
+CHM_INDEX_ENCODING =
+
+# The BINARY_TOC flag controls whether a binary table of contents is generated (
+# YES) or a normal table of contents ( NO) in the .chm file.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
+
+BINARY_TOC = NO
+
+# The TOC_EXPAND flag can be set to YES to add extra items for group members to
+# the table of contents of the HTML help documentation and to the tree view.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
+
+TOC_EXPAND = NO
+
+# If the GENERATE_QHP tag is set to YES and both QHP_NAMESPACE and
+# QHP_VIRTUAL_FOLDER are set, an additional index file will be generated that
+# can be used as input for Qt's qhelpgenerator to generate a Qt Compressed Help
+# (.qch) of the generated HTML documentation.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+GENERATE_QHP = NO
+
+# If the QHG_LOCATION tag is specified, the QCH_FILE tag can be used to specify
+# the file name of the resulting .qch file. The path specified is relative to
+# the HTML output folder.
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QCH_FILE =
+
+# The QHP_NAMESPACE tag specifies the namespace to use when generating Qt Help
+# Project output. For more information please see Qt Help Project / Namespace
+# (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#namespace).
+# The default value is: org.doxygen.Project.
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QHP_NAMESPACE = org.doxygen.Project
+
+# The QHP_VIRTUAL_FOLDER tag specifies the namespace to use when generating Qt
+# Help Project output. For more information please see Qt Help Project / Virtual
+# Folders (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#virtual-
+# folders).
+# The default value is: doc.
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QHP_VIRTUAL_FOLDER = doc
+
+# If the QHP_CUST_FILTER_NAME tag is set, it specifies the name of a custom
+# filter to add. For more information please see Qt Help Project / Custom
+# Filters (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#custom-
+# filters).
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QHP_CUST_FILTER_NAME =
+
+# The QHP_CUST_FILTER_ATTRS tag specifies the list of the attributes of the
+# custom filter to add. For more information please see Qt Help Project / Custom
+# Filters (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#custom-
+# filters).
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QHP_CUST_FILTER_ATTRS =
+
+# The QHP_SECT_FILTER_ATTRS tag specifies the list of the attributes this
+# project's filter section matches. Qt Help Project / Filter Attributes (see:
+# http://qt-project.org/doc/qt-4.8/qthelpproject.html#filter-attributes).
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QHP_SECT_FILTER_ATTRS =
+
+# The QHG_LOCATION tag can be used to specify the location of Qt's
+# qhelpgenerator. If non-empty doxygen will try to run qhelpgenerator on the
+# generated .qhp file.
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QHG_LOCATION =
+
+# If the GENERATE_ECLIPSEHELP tag is set to YES, additional index files will be
+# generated, together with the HTML files, they form an Eclipse help plugin. To
+# install this plugin and make it available under the help contents menu in
+# Eclipse, the contents of the directory containing the HTML and XML files needs
+# to be copied into the plugins directory of eclipse. The name of the directory
+# within the plugins directory should be the same as the ECLIPSE_DOC_ID value.
+# After copying Eclipse needs to be restarted before the help appears.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+GENERATE_ECLIPSEHELP = NO
+
+# A unique identifier for the Eclipse help plugin. When installing the plugin
+# the directory name containing the HTML and XML files should also have this
+# name. Each documentation set should have its own identifier.
+# The default value is: org.doxygen.Project.
+# This tag requires that the tag GENERATE_ECLIPSEHELP is set to YES.
+
+ECLIPSE_DOC_ID = org.doxygen.Project
+
+# If you want full control over the layout of the generated HTML pages it might
+# be necessary to disable the index and replace it with your own. The
+# DISABLE_INDEX tag can be used to turn on/off the condensed index (tabs) at top
+# of each HTML page. A value of NO enables the index and the value YES disables
+# it. Since the tabs in the index contain the same information as the navigation
+# tree, you can set this option to YES if you also set GENERATE_TREEVIEW to YES.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+DISABLE_INDEX = NO
+
+# The GENERATE_TREEVIEW tag is used to specify whether a tree-like index
+# structure should be generated to display hierarchical information. If the tag
+# value is set to YES, a side panel will be generated containing a tree-like
+# index structure (just like the one that is generated for HTML Help). For this
+# to work a browser that supports JavaScript, DHTML, CSS and frames is required
+# (i.e. any modern browser). Windows users are probably better off using the
+# HTML help feature. Via custom stylesheets (see HTML_EXTRA_STYLESHEET) one can
+# further fine-tune the look of the index. As an example, the default style
+# sheet generated by doxygen has an example that shows how to put an image at
+# the root of the tree instead of the PROJECT_NAME. Since the tree basically has
+# the same information as the tab index, you could consider setting
+# DISABLE_INDEX to YES when enabling this option.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+GENERATE_TREEVIEW = YES
+
+# The ENUM_VALUES_PER_LINE tag can be used to set the number of enum values that
+# doxygen will group on one line in the generated HTML documentation.
+#
+# Note that a value of 0 will completely suppress the enum values from appearing
+# in the overview section.
+# Minimum value: 0, maximum value: 20, default value: 4.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+ENUM_VALUES_PER_LINE = 1
+
+# If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be used
+# to set the initial width (in pixels) of the frame in which the tree is shown.
+# Minimum value: 0, maximum value: 1500, default value: 250.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+TREEVIEW_WIDTH = 250
+
+# When the EXT_LINKS_IN_WINDOW option is set to YES doxygen will open links to
+# external symbols imported via tag files in a separate window.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+EXT_LINKS_IN_WINDOW = NO
+
+# Use this tag to change the font size of LaTeX formulas included as images in
+# the HTML documentation. When you change the font size after a successful
+# doxygen run you need to manually remove any form_*.png images from the HTML
+# output directory to force them to be regenerated.
+# Minimum value: 8, maximum value: 50, default value: 10.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+FORMULA_FONTSIZE = 10
+
+# Use the FORMULA_TRANPARENT tag to determine whether or not the images
+# generated for formulas are transparent PNGs. Transparent PNGs are not
+# supported properly for IE 6.0, but are supported on all modern browsers.
+#
+# Note that when changing this option you need to delete any form_*.png files in
+# the HTML output directory before the changes have effect.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+FORMULA_TRANSPARENT = YES
+
+# Enable the USE_MATHJAX option to render LaTeX formulas using MathJax (see
+# http://www.mathjax.org) which uses client side Javascript for the rendering
+# instead of using prerendered bitmaps. Use this if you do not have LaTeX
+# installed or if you want to formulas look prettier in the HTML output. When
+# enabled you may also need to install MathJax separately and configure the path
+# to it using the MATHJAX_RELPATH option.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+USE_MATHJAX = NO
+
+# When MathJax is enabled you can set the default output format to be used for
+# the MathJax output. See the MathJax site (see:
+# http://docs.mathjax.org/en/latest/output.html) for more details.
+# Possible values are: HTML-CSS (which is slower, but has the best
+# compatibility), NativeMML (i.e. MathML) and SVG.
+# The default value is: HTML-CSS.
+# This tag requires that the tag USE_MATHJAX is set to YES.
+
+MATHJAX_FORMAT = HTML-CSS
+
+# When MathJax is enabled you need to specify the location relative to the HTML
+# output directory using the MATHJAX_RELPATH option. The destination directory
+# should contain the MathJax.js script. For instance, if the mathjax directory
+# is located at the same level as the HTML output directory, then
+# MATHJAX_RELPATH should be ../mathjax. The default value points to the MathJax
+# Content Delivery Network so you can quickly see the result without installing
+# MathJax. However, it is strongly recommended to install a local copy of
+# MathJax from http://www.mathjax.org before deployment.
+# The default value is: http://cdn.mathjax.org/mathjax/latest.
+# This tag requires that the tag USE_MATHJAX is set to YES.
+
+MATHJAX_RELPATH = http://www.mathjax.org/mathjax
+
+# The MATHJAX_EXTENSIONS tag can be used to specify one or more MathJax
+# extension names that should be enabled during MathJax rendering. For example
+# MATHJAX_EXTENSIONS = TeX/AMSmath TeX/AMSsymbols
+# This tag requires that the tag USE_MATHJAX is set to YES.
+
+MATHJAX_EXTENSIONS =
+
+# The MATHJAX_CODEFILE tag can be used to specify a file with javascript pieces
+# of code that will be used on startup of the MathJax code. See the MathJax site
+# (see: http://docs.mathjax.org/en/latest/output.html) for more details. For an
+# example see the documentation.
+# This tag requires that the tag USE_MATHJAX is set to YES.
+
+MATHJAX_CODEFILE =
+
+# When the SEARCHENGINE tag is enabled doxygen will generate a search box for
+# the HTML output. The underlying search engine uses javascript and DHTML and
+# should work on any modern browser. Note that when using HTML help
+# (GENERATE_HTMLHELP), Qt help (GENERATE_QHP), or docsets (GENERATE_DOCSET)
+# there is already a search function so this one should typically be disabled.
+# For large projects the javascript based search engine can be slow, then
+# enabling SERVER_BASED_SEARCH may provide a better solution. It is possible to
+# search using the keyboard; to jump to the search box use + S
+# (what the is depends on the OS and browser, but it is typically
+# , /