KIT_PSE84_AI BSP

| KIT_PSE84_AI BSP

API Reference
Startup/System

## General Description

Provides device startup, system configuration, and linker script files.

The system startup provides the followings features:

- Device Memory Definition
- Device Initialization
- Heap and Stack Configuration
- Default Interrupt Handlers Definition
- Vectors Table Copy from Flash to RAM

# Configuration Considerations

## Device Memory Definition

Allocation of different types of memory such as the RRAM and RAM etc. for the CPU is defined by the linker scripts.

Note
  The linker files provided with the templates are generic and handle all common use cases. Your project may not use every section defined in the linker files. In that case you may see warnings during the build process. To eliminate build warnings in your project, you can simply comment out or remove the relevant section in the linker file.
  If the start of the Cortex-M33 non-secure application image is changed, the value of the CY_CORTEX_M33_NS_APPL_ADDR should also be changed. The CY_CORTEX_M33_NS_APPL_ADDR macro should be used as the parameter fo the __TZ_set_MSP_NS function call.
  If the start of the Cortex-M55 application image is changed, the value of the CY_CORTEX_M55_APPL_ADDR should also be changed. The CY_CORTEX_M55_APPL_ADDR macro should be used as the parameter for the Cy_SysCM55Enable() function call.

## Device Initialization

After a power-on-reset (POR), the boot process is handled by the boot code from the on-chip ROM that is always executed by the Cortex-M0+ core. The boot code passes the control to the Cortex-M33 startup code and Cortex-M33 boots the Cortex-M55 core.

CM33 Boot
CM33 always boots in secure mode after reset. Then, the secure code switches execution to non-secure mode. Each execution environment has its own application image. Each application image contains its startup code. So, there are two separate startup codes. One is for secure execution environment, part of secure application image and other one is for non-secure execution environment, part of non-secure application image. Execution of startup code is triggered by the secure code after it completes the initialization during boot process. It switches control to non-secure startup code by switching processor execution state to non-secure state.
The secure code is programmed in RRAM NVM MAIN region. This code executes in place (XIP) from RRAM. First secure code to execute on CM33 is CM33_L1_BOOTLOADER. The CM33_L1_BOOTLOADER, SE_RRAM_BOOT code is launched by the code executing on CM0P core in secure enclave by setting the address of the image entry point in the CM33_S_VECTOR_TABLE_BASE (S_VTOR) register and setting the CM33_CTL.CPUWAIT to LOW to allow execution of reset handler of secure image. Address of CM33_L1_BOOTLOADER image entry point is obtained from the TOC2 table entry CM33_L1_BOOTLOADER_ADDR.

CM55 Boot
The CM55 CPUSS is OFF by default upon POR. CM55 application is launched from CM33 non-secure application depending on the use case requirements. CM55 Application is programmed executed in place from the external flash. The C runtime code will copy necessary code to SOCMEM and other memory areas depending on the choice made for the execution region in the linker script. CM55 execution is held by its CM55_CTL.CPU_WAIT (which will be HIGH) till released (made LOW) by CM33 app to launch the CM55 code after programming the CM55 VTOR with the image entry point in the targeted memory.

Below sequence diagram captures the initialization process in the startup code.

## Heap and Stack Configuration

By default, the stack size is set to 0x00001000 for non-secure applications and 0x00000800 for the CM33 secure application. The remaining ram is used for the heap

### ARM GCC

The stack and heap sizes are defined in the linker script file: 'pse84_s_cm33.ld', 'pse84_ns_cm33.ld' and 'pse84_ns_cm55.ld' To set stack size in application add makefile ldflags: -Wl,–defsym=APP_MSP_STACK_SIZE=< CUSTOM_VALUE > Remaining free RAM is used as heap.

Note
  Correct operation of malloc and related functions depends on the working implementation of the 'sbrk' function. Newlib-nano (default C runtime library used by the GNU Arm Embedded toolchain) provides weak 'sbrk' implementation that doesn't check for heap and stack collisions during excessive memory allocations. To ensure the heap always remains within the range defined by __HeapBase and __HeapLimit linker symbols, provide a strong override for the 'sbrk' function:
  void * _sbrk(uint32_t incr)
  {
  extern uint8_t __HeapBase, __HeapLimit;
  static uint8_t *heapBrk = &__HeapBase;
  uint8_t *prevBrk = heapBrk;
  if (incr > (uint32_t)(&__HeapLimit - heapBrk))
  {
  errno = ENOMEM;
  CY_HALT();
  }
  heapBrk += incr;
  return prevBrk;
  }
  For FreeRTOS-enabled multi-threaded applications, it is sufficient to include clib-support library that provides newlib-compatible implementations of 'sbrk', '__malloc_lock' and '__malloc_unlock':
  https://github.com/Infineon/clib-support.

### ARM Compiler

The stack and heap sizes are defined in the linker script file: 'pse84_s_cm33.sct', 'pse84_ns_cm33.sct' and 'pse84_ns_cm55.sct' To set stack size in application add makefile ldflags: –predefine="-DAPP_MSP_STACK_SIZE=< CUSTOM_VALUE >" Remaining free RAM is used as heap.

### IAR

The stack and heap sizes are defined in the linker script file: 'pse84_s_cm33.icf', 'pse84_ns_cm33.icf' and 'pse84_ns_cm55.icf' To set stack size in application add makefile ldflags: –config_def APP_MSP_STACK_SIZE=< CUSTOM_VALUE > Remaining free RAM is used as heap.

### LLVM ARM

The stack and heap sizes are defined in the linker script file: 'pse84_s_cm33.ld', 'pse84_ns_cm33.ld' and 'pse84_ns_cm55.ld' To set stack size in application add makefile ldflags: -Wl,–defsym=APP_MSP_STACK_SIZE=< CUSTOM_VALUE > Remaining free RAM is used as heap.

## Default Interrupt Handlers Definition

The default interrupt handler functions are dummy handler in the startup file.
Below is the default handler for the non-secure interrupts:

interrupt_type void InterruptHandler(void) {
while(1);
}

## Vectors Table Copy from Flash to RAM

This process uses memory sections defined in the linker script. The startup code copies the default vector table contents to the non-secure SRAM region specified by the linker script. APIs are provided in the sysint driver to hook user implemented handler replacing the default handler for the corresponding interrupt.

Following tables provide the address of the default and non-secure SRAM interrupt vector table for different supported compilers. The linker script file is 'pse84_ns_cm33.ld'. For non-secure world, it uses the following variable.
Copy interrupt vectors from ROM/flash to RAM:
From:

__ns_vector_table

To:

__ns_vector_table_rw

The vector table address (and the vector table itself) are defined in the ns_start_<device>.c startup file corresponding to non-secure world. The code in these files copies the vector table from Flash to RAM.

## API Reference
| Macros
| Enumerated Types
| Functions
| Global Variables