PSOC E8XXGP Device Support Library

| PSOC E8XXGP Device Support Library

API Reference
SysLib (System Library)
PDL API Reference

## General Description

The system libraries provide APIs that can be called in the user application to handle the timing, logical checking or register.

The functions and other declarations used in this driver are in cy_syslib.h. You can include cy_pdl.h to get access to all functions and declarations in the PDL.

The SysLib driver contains a set of different system functions. These functions can be called in the application routine. Major features of the system library:

- Delay functions
- The register Read/Write macro
- Assert and Halt
- Assert Classes and Levels
- A software reset
- Reading the reset cause
- An API to invalidate the flash cache and buffer
- Data manipulation macro
- A variable type definition from MISRA-C which specifies signedness
- Cross compiler compatible attributes
- Getting a silicon-unique ID API
- Setting wait states API
- Resetting the backup domain API
- APIs to serve Fault handler

# Configuration Considerations

Assertion Usage
Use the CY_ASSERT() macro to check expressions that must be true if the program is running correctly. It is a convenient way to insert sanity checks. The CY_ASSERT() macro is defined in the cy_utils.h file, which is part of the Cypress Core Library (core-lib). The macro behavior is as follows: if the expression passed to the macro is false, the CPU is halted.
Starting from the driver version 2.50, the CY_ASSERT macro was moved to the Cypress Core Library (core-lib). Also, the CY_ASSERT implementation was changed not to call Cy_SysLib_AssertFailed() function, so user application that relied on that should take this change into account.

The PDL source code uses this assert mechanism extensively. It is recommended that you enable asserts when debugging firmware.
Assertion Classes and Levels
The Cypress Core Library defines three assert classes, which correspond to different kinds of parameters. There is a corresponding assert "level" for each class.

Class Macro | Level Macro | Type of check
--- | --- | ---
CY_ASSERT_CLASS_1 | CY_ASSERT_L1 | A parameter that could change between different PSoC devices (e.g. the number of clock paths)
CY_ASSERT_CLASS_2 | CY_ASSERT_L2 | A parameter that has fixed limits such as a counter period
CY_ASSERT_CLASS_3 | CY_ASSERT_L3 | A parameter that is an enum constant

Firmware defines which ASSERT class is enabled by defining CY_ASSERT_LEVEL. This is a compiler command line argument, similar to how the DEBUG / NDEBUG macro is passed.
Enabling any class also enables any lower-numbered class. CY_ASSERT_CLASS_3 is the default level, and it enables asserts for all three classes. The following example shows the command-line option to enable all the assert levels:

-D CY_ASSERT_LEVEL=CY_ASSERT_CLASS_3
CY_ASSERT_CLASS_3
#define CY_ASSERT_CLASS_3
Class 3 - Functions that accept enums as constant parameters.
Definition: cy_syslib.h:644
CY_ASSERT_LEVEL
#define CY_ASSERT_LEVEL
The user-definable assert level from compiler command-line argument (similarly to DEBUG / NDEBUG)
Definition: cy_syslib.h:648

Note
  The use of special characters, such as spaces, parenthesis, etc. must be protected with quotes.

After CY_ASSERT_LEVEL is defined, firmware can use one of the three level macros to make an assertion. For example, if the parameter can vary between devices, firmware uses the L1 macro.

CY_ASSERT_L1(clkPath < SRSS_NUM_CLKPATH);
CY_ASSERT_L1
#define CY_ASSERT_L1(x)
Assert Level 1.
Definition: cy_syslib.h:660

If the parameter has bounds, firmware uses L2.

CY_ASSERT_L2(trim <= CY_CTB_TRIM_VALUE_MAX);
CY_ASSERT_L2
#define CY_ASSERT_L2(x)
Assert Level 2.
Definition: cy_syslib.h:661

If the parameter is an enum, firmware uses L3.

CY_ASSERT_L3(config->LossAction <= CY_SYSCLK_CSV_ERROR_FAULT_RESET);
CY_ASSERT_L3
#define CY_ASSERT_L3(x)
Assert Level 3.
Definition: cy_syslib.h:662

Each check uses the appropriate level macro for the kind of parameter being checked. If a particular assert class/level is not enabled, then the assert does nothing.

Delay Functions
Delay functions are supported with different flavors of delays and are implemented by executing known instructions in a loop considering the CPU cycles consumed by these instructions to execute. The loop count is calculated based on the amount of delay required. Cycles taken for the execution of instructions has a direct impact on the accuracy of the delay. For the best accuracy of delay, these functions need to be executed from the single cycle memory. Devices with CM7, CM33, or CM55 processor have I-Cache which ensures the accuracy of the delay as the loop executes from the I-Cache. However, for the devices without I-Cache, user needs to move these functions to faster memory, such as SRAM using appropriate memory section directive listed in the cy_syslib.h file. On devices with CM33 Core, user must ensure that the code is executed using C-BUS. This ensures the execution of the code happens through I-Cache.

# More Information

Refer to the technical reference manual (TRM).

## API Reference
| Macros
| Functions
| Data Structures
| Enumerated Types