ESP32-C3

Technical Reference Manual Version 1.3

www.espressif.com

About This Document

The ESP32-C3 Technical Reference Manual is targeted at developers working on low level software projects that use the ESP32-C3 SoC. It describes the hardware modules listed below for the ESP32-C3 SoC and other products in ESP32-C3 series. The modules detailed in this document provide an overview, list of features, hardware architecture details, any necessary programming procedures, as well as register descriptions.

Navigation in This Document

Here are some tips on navigation through this extensive document:

• • Release Status at a Glance on the very next page is a minimal list of all chapters from where you can directly jump to a specific chapter.
• • Use the Bookmarks on the side bar to jump to any specific chapters or sections from anywhere in the document. Note this PDF d ocument is configured to automatically display Bookmarks when open, which is necessary for an extensive document like this one. However, some PDF viewers or browsers ignore this setting, so if you don't see the Bookmarks by default, try one or more of the following methods:
  • Install a PDF Reader Extension for your browser;
  • Download this document, and view it with your local PDF viewer;
  • Set your PDF viewer to always automatically display the Bookmarks on the left side bar when open.
• • Use the native Navigation function of your PDF viewer to navigate through the documents. Most PDF viewers support to go Up, Down, Previous, Next, Back, Forward and Page with buttons, menu, or hot keys.
• • You can also use the built-in GoBack button on the upper right corner on each and every page to go back to the previous place before you click a link within the document. Note this feature may only work with some Acrobat-specific PDF viewers (for example, Acrobat Reader and Adobe DC) and browsers with built-in Acrobat-specific PDF viewers or extensions (for example, Firefox).

Release Status at a Glance

Note:

Check the link or the QR code to make sure that you use the latest version of this document: https://www.espressif.com/sites/default/files/documentation/esp32-c3_technical_reference_ manual_en.pdf

Contents

27.7 GP-SPI 2 Clock Control 640

28 I2C Contro ller (I2C) ⁶⁷⁶

33 Remote Co ntrol Peripheral (RMT) ⁸⁴³

33.1 Overview 843

32.5 Registers 836

List of Tables

List of Figures

Part I

Microprocessor and Master

This part covers the essential processing elements of the system. Details include controllers for Direct Memory Access (DMA) and RISC-V CPU.

Chapter 1

ESP-RISC-V CPU

1.1 Overview

ESP-RISC-V CPU is a 32-bit core based upon RISC-V ISA comprising base integer (I), multiplication/division (M) and compressed (C) standard extensions. The core has 4-stage, in-order, scalar pipeline optimized for area, power and performance. CPU core complex has an interrupt-controller (INTC), debug module (DM) and system bus (SYS BUS) interfaces for memory and peripheral access.

1.2 Features

• • Operating clock frequency up to 160 MHz
• • Zero wait cycle access to on-chip SRAM and Cache for program and data access over IRAM/DRAM interface
• • Interrupt controller (INTC) with up to 31 vectored interrupts with programmable priority and threshold levels

• • Debug module (DM) compliant with RISC-V debug specification v0.13 with external debugger support over an industry-standard JTAG/USB port
• • Debugger direct system bus access (SBA) to memory and peripherals
• • Hardware trigger compliant to RISC-V debug specification v0.13 with up to 8 breakpoints/watchpoints
• • Physical memory protection (PMP) for up to 16 configurable regions
• • 32-bit AHB system bus for peripheral access
• • Configurable events for core performance metrics

1.3 Address Map

Below table shows address map of various regions accessible by CPU for instruction, data, system bus peripheral and debug.

*default : Address not matching any of the specified ranges (IRAM, DRAM, DM) are accessed using AHB bus.

1.4 Configuration and Status Registers (CSRs)

1.4.1 Register Summary

Below is a list of CSRs available to the CPU. Except for the custom performance counter CSRs and the tcontrol register (which complies with the RISC-V External Debug Support Version 0.13.2), all the implemented CSRs follow the standard mapping of bit fields as described in the RISC-V Instruction Set Manual, Volume II: Privileged Architecture, Version 1.10. It must be noted that even among the standard CSRs, not all bit fi elds have been implemented, limited by the subset of features implemented in the CPU. Refer to the next section for detailed description of the subset of fields implemented under each of these CSRs.

The abbreviations given in Column Access are explained in Section Access Types for Registers .

No te that if write /set/clear operation is attempted on any of the CSRs which are read-only (RO), as indicated in th e above table, t he CPU will generate illegal instruction exception.

¹Although misa is specified as having both read and write access (R/W), its fields are hardwired and thus write has no effect. This is what would be termed WARL (Write Any Read Legal) in RISC-V terminology

²mtvec only provides configuration for trap handling in vectored mode with the base address aligned to 256 bytes

³External interrupt IDs reflected in mcause include even those IDs which have been reserved by RISC-V standard for core internal sources. ⁴These cu stom CSRs have been implemented in the address space reserved by RISC-V standard for custom use

1.4.2 Register Description

Register 1.5. mstatus (0x300)

• MIE Global machine mode interrupt enable. (R/W)
• MPIE Machine previous interrupt enable (before trap). (R/W)
• MPP Machine previous privilege mode (before trap). (R/W)

Possible values:

• • 0x0: User mode
• • 0x3: Machine mode

Note : Only lower bit is writable. Write to the higher bit is ignored as it is directly tied to the lower bit.

TW Timeout wait. (R/W)

If this bit is set, executing WFI (Wait-for-Interrupt) instruction in User mode will cause illegal instruction exception.

A Atomic Extension = 0. (RO)

Espressif Systems 36

Register 1.7. mtvec (0x305)

MODE Only vectored mode 0x1 is available. (RO)

BASE Higher 24 bits of trap vector base address aligned to 256 bytes. (R/W)

MSCRATCH Machine scratch register for custom use. (R/W)

MEPC Machine trap/exception program counter. (R/W)

This is automatically updated with address of the instruction which was about to be executed while CPU encountered the most recent trap.

Register 1.10. mcause (0x342)

Exception Code This field is automatically updated with unique ID of the most recent exception or interrupt due to which CPU entered trap. (R/W)

Possible exception IDs are:

• • 0x1: PMP Instruction access fault
• • 0x2: Illegal Instruction
• • 0x3: Hardware Breakpoint/Watchpoint or EBREAK
• • 0x5: PMP Load access fault
• • 0x7: PMP Store access fault
• • 0x8: ECALL from U mode
• • 0xb: ECALL from M mode

Note : Exception ID 0x0 (instruction access misaligned) is not present because CPU always masks the lowest bit of the address during instruction fetch.

Interrupt Flag This flag is automatically updated when CPU enters trap. (R/W)

If this is found to be set, indicates that the latest trap occurred due to interrupt. For exceptions it remains unset.

Note : The interrupt controller is using up IDs in range 1-31 for all external interrupt sources. This is different from the RISC-V standard which has reserved IDs in range 0-15 for core internal interrupt sources.

Register 1.11. mtval (0x343)

MTVAL Machine trap value. (R/W)

This is automatically updated with an exception dependent data which may be useful for handling that exception.

Data is to be interpreted depending upon exception IDs:

• • 0x1: Faulting virtual address of instruction
• • 0x2: Faulting instruction opcode
• • 0x5: Faulting data address of load operation
• • 0x7: Faulting data address of store operation

Note : The value of this register is not valid for other exception IDs and interrupts.

Register 1.12. mpcer (0x7E0)

INST_COMP Count Compressed Instructions. (R/W)

BRANCH_TAKEN Count Branches Taken. (R/W)

BRANCH Count Branches. (R/W)

JMP_UNCOND Count Unconditional Jumps. (R/W)

STORE Count Stores. (R/W)

LOAD Count Loads. (R/W)

IDLE Count IDLE Cycles. (R/W)

JMP_HAZARD Count Jump Hazards. (R/W)

LD_HAZARD Count Load Hazards. (R/W)

INST Count Instructions. (R/W)

CYCLE Count Clock Cycles. Cycle count does not increment during WFI mode. (R/W)

Note: Each bit selects a specific event for counter to increment. If more than one event is selected and occurs simultaneously, then counter increments by one only.

Register 1.13. mpcmr (0x7E1)

COUNT_SAT Counter Saturation Control. (R/W) Possible values:

• • 0: Overflow on maximum value
• • 1: Halt on maximum value

COUNT_EN Counter Enable Control. (R/W)

Possible values:

• • 0: Disabled
• • 1: Enabled

Register 1.14. mpccr (0x7E2)

MPCCR Machine Performance Counter Value. (R/W)

Register 1.15. cpu_gpio_oen (0x803)

CPU_GPIO_OEN GPIOn (n=0 ~ 21) Output Enable. CPU_GPIO_OEN[7:0] correspond to output enable signals cpu_gpio_out_oen[7:0] in Table 5.11-1 Peripheral Signals via GPIO Matrix . CPU_GPIO_OEN value matches that of cpu_gpio_out_oen. CPU_GPIO_OEN is the enable signal of CPU_GPIO_OUT. (R/W)

• • 0: GPIO output disable
• • 1: GPIO output enable

Register 1.16. cpu_gpio_in (0x804)

CPU_GPIO_IN GPIOn (n=0 ~ 21) Input Value. It is a CPU CSR to read input value (1=high, 0=low) from SoC GPIO pin.

CPU_GPIO_IN[7:0] correspond to input signals cpu_gpio_in[7:0] in Table 5.11-1 Peripheral Signals via GPIO Matrix .

CPU_GPIO_IN[7:0] can only be mapped to GPIO pins through GPIO matrix. For details please refer to Section 5.4 in Chapter IO MUX and GPIO Matrix (GPIO, IO MUX) . (RO)

Register 1.17. cpu_gpio_out (0x805)

CPU_GPIO_OUT GPIOn (n=0 ~ 21) Output Value. It is a CPU CSR to write value (1=high, 0=low) to SoC GPIO pin. The value takes effect only when CPU_GPIO_OEN is set.

CPU_GPIO_OUT[7:0] correspond to output signals cpu_gpio_out[7:0] in Table 5.11-1 Peripheral Signals via GPIO Matrix .

CPU_GPIO_OUT[7:0] can only be mapped to GP IO pins through G PIO matrix. For details please refer to Section 5.5 in Chapter IO MUX and GPIO Matrix (GPIO, IO MUX) . (R/W)

1.5 Interrupt Controller

1.5.1 Features

The interrupt controller allows capturing, masking and dynamic prioritization of interrupt sources routed from peripherals to the RISC-V CPU. It supports:

• • Up to 31 asynchronous interrupts with unique IDs (1-31)
• • Configurable via read/write to memory mapped registers
• • 15 levels of priority, programmable for each interrupt
• • Support for both level and edge type interrupt sources
• • Programmable global threshold for masking interrupts with lower priority
• • Interrupts IDs mapped to trap-vector address offsets

For the complete list of interrupt registers and detailed configuration information, please refer to Chapter 8 Interrupt Matrix (INTERRUPT) , section 8.4, register group "CPU Interrupt Registers".

1.5.2 Functional Description

Each interrupt ID has 5 prope rties ass ocia ted with it:

• 1. Enable State (0-1):
  • • Determines if an interrupt is enabled to be captured and serviced by the CPU.
  • • Programmed by writing the corresponding bit in INTERRUPT_CORE0_CPU_INT_ENABLE_REG.
• 2. Type (0-1):
  • • Enables latching the state of an interrupt signal on its rising edge.
  • • Programmed by writing the corresponding bit in INTERRUPT_CORE0_CPU_INT_TYPE_REG.
  • • An interrupt for which type is kept 0 is referred as a 'level' type interrupt.
  • • An interrupt for which type is set to 1 is referred as an 'edge' type interrupt.
• 3. Priority (1-15):
  • • Determines which interrupt, among multiple pending interrupts, the CPU will service first.
  • • Programmed by writing to the INTERRUPT_CORE0_CPU_INT_PRI_ n _REG for a particular interrupt ID n in range (1-31).
  • • Enabled interrupts with priorities zero or less than the threshold value in INTERRUPT_CORE0_CPU_INT _THRESH_REG are masked.
  • • Priority levels increase from 1 (lowest) to 15 (highest).
  • • Interrupts with same priority are statically prio ritized by their IDs, lowest ID having highest priority.
• 4. Pending State (0-1):
  • • Reflects the captured state of an enabled and unmasked interrupt signal.

• • For each interrupt ID, the corresponding bit in read-only INTERRUPT_CORE0_CPU_INT_EIP_STATUS_REG gives its pending state.
• • A pending interrupt will cause CPU to enter trap if no other pending interrupt has higher priority.
• • A pending interrupt is said to be 'claimed' if it pre empts the CPU and causes it to jump to the corresponding trap vector address.
• • All pending interrupts which are yet to be serviced are termed as 'unclaimed'.
• 5. Clear State (0-1):
  • • Toggling this will clear the pending state of claimed edge-type interrupts only.
  • • Toggled by first setting and then clearing the corresponding bit in INTERRUPT_CORE0_CPU_INT_CLEAR_REG.
  • • Pending state of a level type interrupt is unaffected by this and must be cleared from source.
  • • Pending state of an unclaimed edge type in terrupt can be flushed, if required, by first clearing the corresponding bit in INTERRUPT_CORE0_CPU_INT_ENABLE_REG and then toggling same bit in INTERRUPT_CORE0_CPU_INT_CLEAR_REG.

When CPU services a pending interrupt, it:

• • save s the address of the current un-executed in struction in mepc for resuming execution later.
• • updates the value of mcause with the ID of the interrupt being serviced.
• • copies the state of MIE into MPIE, and subsequently clears MIE, th ereby disabling interrupts globally.
• • enters trap by jumpin g to a wo rd-aligned offset of the address stored in mtvec.

Table 1.5-1 shows the ma ppin g of each interrupt ID with the corre spon ding trap-vector address. In short, the word aligned trap address for an interrupt with a certain ID = i can be calculated as ( mtvec + 4 i ).

Note : ID = 0 is unavailable and therefore cannot be used for capturing inter rupts. This is because the corre spon ding trap vector address (mtvec + 0x00) is reserved for exceptions.

Table 1.5-1. ID wise map of Interrupt Trap-Vector Addresses

After jumping to the trap-vector, the execution flow is dependent on software implementation, although it can be presumed that the interrupt will get handled (and cleared) in some interrupt service routine (ISR) and later the normal execution will resume once the CPU encounters MRET instruction.

Upon execution of MRET instruction, the CPU:

• • copies the state of MPIE back into MIE, and subsequently clears MPIE. This means that if previously MPIE was set, then, after MRET, MIE will be set, thereby enabling interrupts globally.
• • jumps to the address stored in mepc and resumes execution.

It is p ossibl e to perform softwa re assi sted ne sting of interrupts inside a n ISR as explained in 1.5.3.

The below listed points outline the f unction al behavior of the controller:

• • Only if an interrupt has non-zero priority, higher or equal to the value in the threshold r egiste r, will it be reflected in INTERRUPT_CORE0_CPU_INT_EIP_STATUS_REG.
• • If an interrupt is visible in INTERRUPT_CORE0_CPU_INT_EIP_STATUS_REG and has yet to be serviced, then it's possible to mask it (and thereby prevent the CPU from servicing it) by either lowering the value of its priorit y or increasing the global threshold.
• • If an interrupt, visible in I NTERRUPT_CORE0_CPU_INT_EIP_STATUS_REG, is to be flushed (and prevented from being serviced at all), then it must be disabled (and cleared if it is of edge type).

1.5.3 Suggested O peration

1.5.3.1 Latency Aspects

There is latency involved while configuring the Interrupt Controller.

In steady state operation, the Interrupt Controller has a fixed latency of 4 cycles. Steady state means that no changes have been made to the Interrupt Controller registers recently. This implies that any interrupt that is asserted to the controller will take exactly 4 cycles before the CPU starts processing the interrupt. This further implies that CPU may execute up to 5 instructions before the preemption happens.

Whenever any of its registers are modified, the Interrupt Controller enters into transient state, which may take up to 4 cycles for it to settle down into steady state again. During this transient state, the ordering of interrupts may not be predictable, and therefore, a few safety measures need to be taken in software to avoid any synchronization issues.

Also, it must be noted that the Interrupt Controller configuration registers lie in the APB address range, hence any R/W access to these registers may take multiple cycles to complete.

In consideration of above mentioned characteristics, users are advised to follow the sequence described below, whenever modifying any of the Interrupt Controller registers:

• 1. save the state of MIE and clear MIE to 0
• 2. read-modify-write one or more Interrupt Controller registers
• 3. execute FENCE i nstru ction to wait fo r any pending write operations to complete
• 4. finally, restore the state of MIE

Due to its critical nature, it is recommended to disable interrupts globally (MIE=0) beforehand, whenever configuring interrupt controller registers, and then restore MIE right after, as shown in the sequence above.

After execution of the sequence above, the Interrupt Controller will resum e op eration in steady state.

1.5.3.2 Configuration Procedure

By default, interrupts are disabled globally, since the reset value of MIE bit in mstatus is 0. Software must set MIE=1 after initialization of the interrupt stack (including setting mtvec to the interrupt vector address) is done.

During normal execution, if an interrupt n is to be enabled, the bel ow se que nce may be followed:

• 1 . save the state of MIE and clear MIE to 0
• 2. depending upon the type of the interrupt (edge/level), set/unset the n th bit of INTERRUPT_CORE0_CPU_INT_TYPE_REG
• 3. set the priority b y writ ing a valu e to INTERRUPT_CORE0_CPU_INT_PRI_ n _REG in range 1(lowest) to 15 (highest)
• 4. set the n th bit of INTERRUPT_CORE0_CPU _INT_ENABLE_REG
• 5. execute FENCE instruction
• 6. restore the state of MIE

When one or more interrupts become pending, the CPU acknowledges (claims) the interrupt with the highest priority and jumps to the trap vector address corresponding to the interrupt's ID. Software implementation may read mcause to infer the type of trap (mcause(31) is 1 for interrupts and 0 for exceptions) and then the ID of the interrupt (mcause(4-0) gives ID of interrupt or exception). This inference may not be necessary if each entry in the trap vector are jump instructions to different trap handlers. Ultimately, the trap handler(s) will redir ect execu tion to the appropriate I SR for this in terrupt.

Upon enterin g into an ISR, s oftware must toggle the n th bit of INTERRUPT_CORE0_CPU_INT_CLEAR_REG if the interrupt is of edge type, or clear the source of the interrupt if it is of level type.

Software may also update the value of INTERRUPT_CORE0_CPU_INT_THRESH_REG and program MIE=1 for allowing higher priority interrupts to preempt the current ISR ( nesting), however, before doing so, all the s tate CSRs must be saved (mepc, mstatus, mcause, etc.) since they will get overwritten due to occurrence of such an interrupt. Later, when exiting the IS R, the values of these CSRs must be restored .

Finally, after the execution returns from the ISR back to the trap handler, MRET instruction is used to resume normal execution.

Later, if the n interrupt is no longer needed and needs to be disabled, the following sequence may be followed:

• 1. save the state of MIE and clear MIE to 0
• 2. check if the interrupt is pending in INTERRUPT_CORE0_CPU_INT_EIP_STATUS_REG
• 3. set/unset the n t h bit of INTER RUPT_ CORE0_CPU_INT_ENABLE_REG
• 4. if the interrupt is of edge type and was found to be pending in step 2 above, n th bit of INTERRUPT_CORE0_CPU_INT_CLEAR_REG must be toggled, so that its pending status gets flushed
• 5. execute FENCE instructi on
• 6. restore the state of MIE

Above is only a suggested scheme of operation. Actual software implementation may vary.

1.5.4 Register Summary

The addresses in this section are relative to Interrupt Controller base address provided in Table 3.3-3 in Chapter 3 System and Memory .

For the complete list of interrupt registers and detailed configuration information, please refer to Chapter 8 Interrupt Matrix (INTERRUPT) , section 8.4, register group "CPU Interrupt Registers".

1.5.5 Register Description

The addresses in this section are relat ive to Interrupt Controller base address provided in Table 3.3-3 in Chapter 3 System and Memory .

For the complete list of interrupt registers and detailed configuration information, please refer to Chapter 8 Interrupt Matrix (INTERRUPT) , section 8.4, register group "CPU Interrupt Registers".

1.6 Debug

1.6.1 Overview

This section describes how to debug and test software running on CPU core. Debug support is provided through standard JTAG pins and complies to RISC-V External Debug Support Specification version 0.13.

Figure 1.6-1 below shows the main components of External Debug Support.

Figure 1.6-1. Debug System Overview

The user interacts with the Debug Host (eg. laptop), which is running a debugger (eg. gdb). The debugger communicates with a Debug Translator (eg. OpenOCD, which may include a hardware driver) to communicate with Debug Transport Hardware (eg. Olimex USB-JTAG adapter). The Debug Transport Hardware connects the Debug Host to the ESP-RV Core's Debug Transport Module (DTM) through standard JTAG interface. The DTM provides access to the Debug Module (DM) using the Debug Module Interface (DMI).

The DM allows the debugger to halt the core. Abstract commands provide access to its GPRs (general purpose registers). The Program Buffer allows the debugger to execute arbitrary code on the core, which allows access to additional CPU core state. Alternatively, additional abstract commands can provide access to additional CPU core state. ESP-RV core contains Trigger Module supporting 8 triggers. When trigger conditions are met, cores will halt spontaneously and inform the debug module that they have halted.

System bus access block allows memory and peripheral register access without using RISC-V core.

Espressif Systems 47

1.6.2 Features

Basic debug functionality supports below features.

• • Provides necessary information about the implementation to the debugger.
• • Allows the CPU core to be halted and resumed.
• • CPU core registers (including CSR's) can be read/written by debugger.
• • CPU can be debugged from the first instruction executed after reset.
• • CPU core can be reset through debugger.
• • CPU can be halted on software breakpoint (planted breakpoint instruction).
• • Hardware single-stepping.
• • Execute arbitrary instructions in the halted CPU by means of the program buffer. 16-word program buffer is supported.
• • System bus access is supported through word aligned address access.
• • Supports eight Hardware Triggers (can be used as breakpoints/watchpoints) as described in Section 1.7.

1.6.3 Functional Description

As mentioned earlier, Debug Scheme conforms to RISC-V External Debug Support Specification version 0.1 3. Please refer the specs for functional operation details.

1.6.4 Register Summary

Below is the list of Debug CSR's supported by ESP-RV core.

The abbreviations given in Column Access are explained in Section Access Types for Registers .

All the debug module registers are implemented in conformance to RISC-V External Debug Support Sp ecification version 0.13. Please refer it for more details.

1.6.5 Register Description

Below are the details of Debug CSR's supported by ESP-RV core

Register 1.18. dcsr (0x7B0)

xdebugver Debug version. (RO)

• • 4: External debug support exists
• ebreakm When 1, ebreak instructions in Machine Mode enter Debug Mode. (R/W)

ebreaku When 1, ebreak instructions in User/Application Mode enter Debug Mode. (R/W)

stopcount This bit is not implemented. Debugger will always read this bit as 0. (RO)

• stoptime This feature is not implemented. Debugger will always read this bit as 0. (RO)
• cause Explains why Debug Mode was entered. When there are multiple reasons to enter Debug Mode in a single cycle, the cause with the highest priority number is the one written.
  • 1. An ebreak instruction was executed. (priority 3)
  • 2. The Trigger Module caused a halt. (priority 4)
  • 3. haltreq was set. (priority 2)
  • 4. The CPU core single stepped because step was set. (priority 1)

Other values are reserved for future use. (RO)

• step When set and not in Debug Mode, the core will only execute a single instruction and then enter Debug Mode. Interrupts are enabled* when this bit is set. If the instruction does not complete due to an exception, the core will immediately enter Debug Mode before executing the trap handler, with appropriate exception registers set. (R/W)
• prv Contains the privilege level the core was operating in when Debug Mode was entered. A debugger can change this value to change the core's privilege level when exiting Debug Mode. Only 0x3 (machine mode) and 0x0(user mode) are supported.

*Note: Different from RISC-V Debug specification 0.13

Register 1.19. dpc (0x7B1)

dpc Upon entry to debug mode, dpc is written with the virtual address of the instruction that encountered the exception. When resuming, the CPU core's PC is updated to the virtual address stored in dpc. A debugger may write dpc to change where the CPU resumes. (R/W)

Register 1.20. dscratch0 (0x7B2)

dscratch0 Used by Debug Module internally. (R/W)

dscratch1 Used by Debug Module internally. (R/W)

1.7 Hardware Trigger

1.7.1 Features

Hardware Trigger module provides breakpoint and watchpoint capability for debugging. It includes the following features:

• • 8 independent trigger units
• • each unit can be configured for matching the address of program counter or load-store accesses
• • can preempt execution by causing breakpoint exception
• • can halt execution and transfer control to debugger
• • support NAPOT (naturally aligned power of two) address encoding

1.7.2 Functional Description

The Hardware Trigger module provides four CSRs, which are listed under register summary section. Among these, tdata1 and tdata2 are abstract CSRs, which means they are shadow registers for accessing internal registers for each of the eight trigger units, one at a time.

To choose a particular trigger unit write the index (0-7) of that unit into tselect CSR. When t select is written with a valid in dex, the ab stract CSRs tdata1 and tdata2 are automatically mapped to reflect internal registers of that trigger unit. Each trigger unit has two internal registers, namely mcontrol and maddress, which are mapped to tdata1 and tdata2, respectively.

Writing larger than allowed indexes to tselect will clip the written value to the largest valid index, which can be read back. This property may be used for enumerating the number of availab le tri ggers durin g initialization or when using a debugger.

Since software or debugger may need to know the type of the selected trigger to correctly interpret tdata1 and tdata2, the 4 bits (31-28) of tdata1 encodes the type of the selected trigger. This type field is read-only and always provides a value of 0x2 for every trigger, which stands for match type trigger, hence, it is inferred that tdata1 and tdata2 are to be interpreted as mcontrol and maddress. The information regarding other possible values can be found in the RISC-V Debug Specification v0.13, but this trigger module only supports type 0x2.

Once a trigger unit has been chosen by writing its index to tselect, it will become possible to configure it by setting the appropriate bits in mcontrol CSR (tdata1) and writing the target address to maddress CSR (tdata2).

Each trigger unit can be configured to either cause breakpoint exception or enter debug mode, by writing to the action bit of mcontrol. This bit can only be written from debugger, thus by default a trigger, if enabled, will cause breakpoint exception.

mcontrol for each trigger unit has a hit bit which may be read, after CPU halts or enters exception, to find out if this was the trigger unit that fired. This bit is set as soon as the corresponding trigger fires, but it has to be manually cleared before resuming operation. Although, failing to clear it doesn't affect normal execution in any way.

Each trigger unit only supports match on address, although this address could either be that of a load/store access or the virtual address of an instruction. The address and size of a region are specified by writing to maddress (tdata2) CSR for the selected trigger unit. Larger than 1 byte region sizes are specified through NAPOT (naturally aligned power of two) encoding (see Table 1.7-1) and enabled by setting match bit in mcontrol. Note that for NAPOT encoded addresses, by definition, the start address is constrained to be aligned to (i.e. an integer multiple of) the region size.

Table 1.7-1. NAPOT encodin g fo r maddress

tcontrol CSR is common to all trigger units. It is used for preventing triggers from causing repeated exceptions in machine-mode while execution is happening inside a trap handler. This also disables breakpoint exceptions inside ISRs by default, although, it is possible to manually enable this right before entering an ISR, for debugg ing purposes. This CSR is not relevant if a trigger is configured to enter debug mode.

1.7.3 Trigger Execution Flow

When hart is halted and enters debug mode due to the firing of a trigger (action = 1):

• • dpc is set to current PC (in decode stage)
• • cause field in dcsr is set to 2, which means halt due to trigger
• • hit bit is set to 1, corresponding to the trigger(s) which fired

When hart goes int o trap due to the firing of a trigger (action = 0) :

• • me pc is set to current PC (in decode stage)
• • mcause is set to 3, which means breakpoint exc eption
• • mpte is set to the value in mte right before trap
• • mte is set to 0
• • hit bit is set to 1, correspo nding to the trigger(s) which fired

Note : If t wo different triggers fire at the same time, one with action = 0 and another with action = 1, then hart is halted and enters debug mode.

1.7.4 Register Summary

Below is a list of Trigger Module CSRs supported by the CPU. These are only accessible from machine-mode.

The abbreviations given in Column Access are explained in Section Access Types for Registers .

Espressif Systems 52

1. 7.5 Register Description

Register 1.22. tselect (0x7A0)

tselect Index (0-7) of the selected trigger unit. (R/W)

Register 1.23. tdata1 (0x7A1)

type Type of trigger. (RO)

This field is reserved since only match type (0x2) triggers are supported.

dmode This is set to 1 if a trigger is being used by the debugger. (R/W *)

• • 0: Both Debug and M-mode can write the tdata1 and tdata2 registers at the selected tselect.
• • 1: Only Debug Mode can write the tdata1 and tdata2 registers at the selected tselect. Writes from other modes are ignored.

* Note : Only writable from debug mode.

data Abstract tdata1 content. (R/W)

This will always be interpreted as fields of mcontrol since only match type (0x2) triggers are supported.

Register 1.24. tdata2 (0x7A2)

tdata2 Abstract tdata2 content. (R/W)

This will always be interpreted as maddress since only match type (0x2) triggers are supported.

Re gister 1.25. tcontrol (0x7A5)

mpte Machine mode previous trigger enable bit. (R/W)

• • When CPU is taking a machine mode trap, the value of mte is automatically pushed into this.
• • When CPU is executing MRET, its value is popped back into mte, so this becomes 0.

mte Machine mode trigger enable bit. (R/W)

• • When CPU is taking a machine mode trap, its value is auto matic ally pushed into mpte, so this becomes 0 and triggers with action=0 are disabled globally.
• • When CPU is executing MRET, the value of mpte is automatically popped back into this.

Register 1.26. mcontrol (0x7A1)

dmode Same as dmode in tdata1.

• hit This is found to be 1 if the selected trigger had fired previously. (R/W) This bit is to be cleare d manua lly.
• action Write this for configuring the selected trigger to perform one of the available actions when firing. (R/W)

Valid options are:

• • 0x0: cause breakpoint exception.
• • 0x1: enter debug mode (only valid when dmode = 1)

Note : Writing an invalid value will set this to the default value 0x0.

match Write this for configuring the selected trigger to perform one of the available matching operations on a data/instruction address. (R/W) Valid options are:

• • 0x0: exact byte match, i.e. address corresponding to one of the bytes in an access must match the value of maddress exactly.
• • 0x1: NAPOT match, i.e. at least one of the bytes of an access must lie in the NAPOT region specified in maddress.

Note : Writing a larger v alue will cli p it to the largest possible value 0x1.

• m Set this for enabl ing selecte d trigger to operate in machine mode. (R/W)
• u Set this for enabling selected trigger to operate in user mode. (R/W)
• execute Set this for configuring the selected trigger to fire right before an instruction with matching virtual address is executed by the CPU. (R/W)
• store Set this for configuring the selected trigger to fire right before a store operation with matching data address is executed by the CPU. (R/W)
• load Set this for configuring the selected trigger to fire right before a load operation with matching data address is executed by the CPU. (R/W)

Register 1.27. maddress (0x7A2)

maddress Address used by the selected trigger when performing match operation. (R/W) This is decoded as NAPOT when match=1 in mcontrol.

1.8 Memory Protection

1.8.1 Overview

The CPU core includes a physical memory protection unit, which can be used by software to set memory access privileges (read, write and execute permissions) for required memory regions. However it is not fully compliant to the Physical Memory Protection (PMP) description specified in RISC-V Instruction Set Manual, Volume II: Privileged Architecture, Version 1.10. Details of existing non-conformance are provided in next section.

For detailed understanding of the RISC-V PMP concept, please refer to RISC-V Instruction Set Manual, Volume II: Privileged Architecture, Version 1.10.

1.8.2 Features

The PMP unit can be used to restrict access to physical memory. It supports 16 regions and a minimum granularity of 4 bytes. Below are the current non-conformance with PMP description from RISC-V Privilege specifications:

• • Static priority i.e. overlapping regions are not supported
• • Maximum supported NAPOT range is 1 GB

As per RISC-V Privilege specifications, PMP entries should be statically prioritized and the lowest-numbered PMP entry that matches any address byte of an access will determine whether that access succeeds or fails. This means, when any address matches more than one PMP entry i.e. overlapping regions among different PMP entries, lowest number PMP entry will decide whether such address access will succeed or fail.

However, RISC-V CPU PMP unit in ESP32-C3 does not implement static priority. So, software should make sure that all enabled PMP entries are programmed with unique regions i.e. without any region overlap among them. If software still tries to program multiple PMP entries with overlapping region having contradicting permissions, then access will succeed if it matches at least one of enabled PMP entries. An exception will be generated, if access matches none of the enabled PMP entries.

1.8.3 Functional Description

Software can program the PMP unit's configuration and address registers in order to contain faults and support secure execution. PMP CSR's can only be programmed in machine-mode. Once enabled, write, read and execute permission checks are applied to all the accesses in user-mode as per programmed values of enabled 16 pmpcfgX and pmpaddrX registers (refer Register Summary).

By default, PMP grants permission to all accesses in machine-mode and revokes permission of all access in user-mode. This implies that it is mandatory to program address range and valid permissions in pmpcfg and pmpaddr registers (refer Register Summary) for any valid access to pa ss through in user-mode. However, it is not required for machine-mode as PMP permits all accesses to go through by deafult. In cases where PMP checks are also required in machine-mode, software can set the lock bit of required PMP entry to enable permission checks on it. Once lock bit is se t, it can only be cleared through CPU reset.

When any instruction is being fetched from memory region without execute permissions, exception is generated at processor level and exception cause is set as instruction access fault in mcause CSR. Similarly,

any load/store access without valid read/write permissions, will result in exception generation with mcause updated as load access and store access fault respectively. In case of load/store access faults, violating address is captured in mtval CSR.

1.8.4 Register Summary

Below is a list of PMP CSRs supported by the CPU. These are only accessible from machine-mode.

The abbreviations given in Column Access are explained in Section Access Types for Registers .

1.8.5 Reg ister Description

PMP unit implements all pmpcfg0-3 and pmpaddr0-15 CSRs as defined in RISC-V Instruction Set Manual Volume II: Privileged Architecture, Version 1.10.

GDMA Controller (GDMA)

2.1 Overview

General Direct Memory Access (GDMA) is a feature that allows peripheral-to-memory, memory-to-peripheral, and memory-to-memory data transfer at a high speed. The CPU is not involved in the GDMA transfer, and therefore it becomes more efficient with less workload.

The GDMA controller in ESP32-C3 has six independent channels, i.e. three transmit channels and three receive channels. These six channels are shared by peripherals with GDMA feature, namely SPI2, UHCI0 (UART0/UART1), I2S, AES, SHA, and ADC. Users can assign the six channels to any of these peripherals. UART0 and UART1 use UHCI0 together.

The GDMA controller uses fixed-priority and round-robin channel arbitration schemes to manage peripherals' needs for bandwidth.

2.2 Features

The GDMA controller has the following features:

• • AHB bus architecture
• • Programmable length of data to be transferred in bytes
• • Linked list of descriptors
• • INCR burst transfer when accessing internal RAM
• • Access to an address space of 384 KB at most in internal RAM

Espressif Systems 60

• • Three transmit channels and three receive channels
• • Software-configurable selection of peripheral requesting its service
• • Fixed channel priority and round-robin channel arbitration

2.3 Architecture

In ESP32-C3, all modules that need high-speed data transfer support GDMA. The GDMA controller and CPU data bus have access to the same address space in internal RAM. Figure 2.3-1 shows the basic architecture of the GDMA engine.

Figure 2.3-1. GDMA Engine Architecture

The GDMA controller has six independent channels, i.e. three transmit channels and three receive channels. Every channel can be connected to different peripherals. In other words, channels are general-purpose, shared by peripherals.

The GDMA engine reads data from or writes data to internal RAM via the AHB_BUS. Before this, the GDMA controller uses fixed-priority arbitration scheme for channels requesting read or write access. For available address range of Internal RAM, please see Chapter 3 System and Memory .

Software can use the GDMA engine through linked lists. These linked lists, stored in internal RAM, consist of outlink n and inlink n , where n indicates the channel number (ranging from 0 to 2). The GDMA controller reads an outlink n (i.e. a linked list of transmit descriptors) from internal RAM and transmits data in corresponding RAM according to the outlink n , or reads an inlink n (i.e. a linked list of receive descriptors) and stores received data into specific address space in RAM according to the inlink n .

2.4 Functional Description

2.4.1 Linked List

Figure 2.4-1. Structure of a Linked List

Figure 2.4-1 shows the structure of a linked list. An outlink and an inlink have the same structure. A linked list is formed by one or more descriptors, and each descriptor consists of three words. Linked lists should be in internal RAM for the GDMA engine to be able to use them. The meaning of each field is as follows:

• Owner (DW0) [31]: Specifies who is allowed to access the buffer that this descriptor points to. 1'b0: CPU can access the buffer;

1'b1: The GDMA controller can access the buffer.

When the GDMA controller stops using the buffer, this bit in a receive descriptor is automatically cleared by hardware, and this bit in a transmit descriptor is automatically cleared by hardware only if GDMA_OUT_AUTO_WRBACK_CH n is set to 1. Software can disable automatic clearing by hardware by setting GDMA_OUT_LOOP_TEST_CH n or GDMA_IN_LOOP_TEST_CH n bit. When software loads a linked list, this bit should be set to 1.

Note: GDMA_OUT is the prefix of t ransmit channel registers, and GDMA_IN is the prefix of receive chann el registers.

• suc_eof (DW0) [30]: Specifies whether the GDMA_IN_SUC_EOF_CH n _INT or GDMA_OUT_EOF_CH n _INT interrupt will be triggered when the data corresponding to this descriptor has been received or transmitted.

1'b0: No interrupt will be triggered after the current descriptor's successful transfer;

1'b1: An interrupt will be triggered after the current descriptor's successful transfer.

For receive descriptors, software needs to clear this bit to 0, and hardware will set it to 1 after receiving data containing the EOF flag.

For transmit descriptors, software needs to set this bit to 1 as needed.

If software configures this bit to 1 in a descriptor, the GDMA will include the EOF flag in the data sent to the corresponding peripheral, indicating to the peripheral that this data segment marks the end of one transfer phase.

• • Reserved (DW0) [29]: Reserved. Value of this bit does not matter.
• • err_eof (DW0) [28]: Specifies whether the received data has errors. This bit is used only when UHCI0 uses GDMA to receive data. When an error is detected in the received data segment corresponding to a descriptor, this bit in the receive descriptor is set to 1 by hardware.

• • Reserved (DW0) [27:24]: Reserved.
• • Length (DW0) [23:12]: Specifies the number of valid bytes in the buffer that this descriptor points to. This field in a transmit descriptor is written by software and indicates how many bytes can be read from the buffer; this field in a receive descriptor is written by hardware automatically and indicates how many valid bytes have been stored into the buffer.
• • Size (DW0) [11:0]: Specifies the size of the buffer that this descriptor points to.
• • Buffer address pointer (DW1): Address of the buffer. This field can only point to internal RAM.
• • Next descriptor address (DW2): Address of the next descriptor. If the current descriptor is the last one, this value is 0. This field can only point to internal RAM.

If the length of data received is smaller than the size of the buffer, the GDMA controller will not use the available space of the buffer in the next transaction.

2.4.2 Peripheral-to-Memory and Memory-to-Peripheral Data Transfer

The GDMA controller can transfer data from memory to peripheral (transmit) and from peripheral to memory (receive). A transmit channel transfers data in the specified memory location to a peripheral's transmitter via an outlink n , whereas a receive channel transfers data received by a peripheral to the specified memory location via an inlink n .

Every transmit and receive channel can be connected to any peripheral with GDMA feature. Table 2.4-1 illustrates how to select the peripheral to be connected via registers. When a channel is connected to a peripheral, the rest channels can not be connected to that peripheral.

Table 2.4-1. Selecting Peripherals via Register Configuration

2.4.3 Memory-to-Memory Data Transfer

The GDMA controller also allows memory-to-memory data transfer. Such data transfer can be enabled by setting GDMA_MEM_TRANS_EN_CH n , which connects the output of transmit channel n to the input of receive channel n . Note that a transmit channel is only connected to the receive channel with the same number ( n ).

2.4.4 Enabling GDMA

Software uses the GDMA controller through linked lists. When the GDMA controller receives data, software loads an inlink, configures GDMA_INLINK_ADDR_CH n field with address of the first receive descriptor, and sets GDMA_INLINK_START_CH n bit to enable GDMA. When the GDMA controller transmits data, software loads an outlink, prepares data to be transmitted, configures GDMA_OUTLINK_ADDR_CH n field with address of the first transmit descriptor, and sets GDMA_OUTLINK_START_ CH n bit to enable GDMA. GDMA_INLINK_START_CH n bit and GDMA_OUTLINK_STAR T_CH n bit are cleared automatically by hardware.

In some cases, you may want to append more des criptors to a DMA transfer that is already started. Naively, it would seem to be possible t o do this by clearing the EOF b it of the final descri ptor in the existing list and setti ng its next descriptor address pointer field (DW2) to the first descriptor of the to-be-added list. However, this strategy fails if the existing DMA transfer is almost or entirely finished. Instead, the GDMA engine has specialized logic to make sure a DMA transfer can be continued or restarted: if it is still ongoing, it will make sure to take the appended descriptors into account; if the transfer has already finished, it will restart with the new descriptors. This is implemented in the Restart function.

When using the Restart function, software needs to rewrite address of the first descriptor in the new list to DW2 of the last descriptor in the loaded list, and set GDMA_INLINK_RESTART_CH n bit or

GDMA_OUTLINK_RESTART_CH n bit (these two bits are cleared automatically by hardware). As shown in Figure 2.4-2, by doing so hardware can obtain the address of the first descriptor in the new list when reading the last descriptor in the loaded list, and then read the new l ist.

Figure 2.4-2. Relationship among Linked Lists

2.4.5 Linked List Reading Process

Once configured and enabled by software, the GDMA controller starts to read the linked list from internal RAM. The GDMA performs checks on descriptors in the linked list. Only if descriptors pass the checks, will the corresponding GDMA channel transfer data. If the descriptors fail any of the checks, hardware will trigger descriptor error interrupt (either GDMA_IN_DSCR_ERR_CH n _INT or GDMA_OUT_DSCR_ERR_CH n _INT), and the channel will halt.

The checks performed on descriptors are:

• Owner bit check when GDMA_IN_CHECK_OWNER_CH n or GDMA_OUT_CHECK_OWNER_CH n is set to 1.

Espressif Systems 64

If the owner bit is 0, the buffer is accessed by the CPU. In this case, the owner bit fails the check. The owner bit will not be checked if GDMA_IN_CHECK_OWNER_CH n or GDMA_OUT_CHECK_OWNER_CH n is 0;

• Buffer address pointer (DW1) check. If the buffer address pointer points to 0x3FC80000 ~ 0x3FCDFFFF (please refer to Section 2.4.7), i t passes the check.

After software detects a descriptor error interrupt, it must reset the corresponding channel, and enable GDMA by setting GDMA_OUTLINK_START_CH n or GDMA_INLINK_START_CH n bit.

Note: The third word (DW2) i n a de scriptor can only point to a location in internal RAM, given that the third word points to the next descriptor to use and that all descriptors must be in internal memory.

2.4.6 EOF

The GDMA controller uses EOF (end of frame) flags to indicate the end of data segment transfer corresponding to a specific descriptor.

Before the GDMA controller transmits data, GDMA_OUT_TOTAL_EOF_CH n _INT_ENA bit should be set to enable GDMA_OUT_TOTAL_EOF_CH n _INT interrupt. If data in the buffer pointed by the last descriptor (with EOF) has been transmitted, a GDMA_OUT_TOTAL_EOF_CH n _INT interrupt is generated.

Before the GDMA controller receives data, GDMA_IN_SUC_EOF_CH n _INT_ENA bit should be set to enable GDMA_IN_SUC_EOF_CH n _INT interrupt. If a data segment with an EOF flag has been received successfully, a GDMA_IN_SUC_EOF_CH n _INT interrupt is generated. In addition, when GDMA channel is connected to UHCI0, the GDMA controller also supports GDMA_IN_ERR_CH n _EOF_INT interrupt. This interrupt is enabled by setting GDMA_IN_ERR_EOF_CH n _INT_ENA bit, and it indicates that a data segment corresponding to a descriptor has been received with errors.

When detecting a GDMA_OUT_TOTAL_EOF_CH n _INT or a GDMA_IN_SUC_EOF_CH n _INT interrupt, software can record the value of GDMA_OUT_EOF_DES_ ADDR_CH n or GDMA_IN_SUC_EOF_DES_ADDR_CH n field, i.e. address of the last descriptor. Therefore, software can tell which descriptors have been used and reclaim them.

Note: In this chapter, E OF of transmit descriptors refers to s uc _eof, while EOF of receive descriptors r efers to both suc_eof and err_eof.

2.4.7 Accessing Internal RAM

Any transmit and receive channels of GDMA can access 0x3FC80000 ~ 0x3FCDFFFF in internal RAM. To improve data transfer efficiency, GDMA can send data in burst mode, which is disabled by default. This mode is enabled for receive channels by setting GDMA_IN_DATA_BURST_EN_CH n , and enabled for transmit channels by setting GDMA_OUT_DATA_BURST_EN_CH n .

Table 2.4-2 lists the requirements for descriptor field alignment when accessing internal RAM.

When burst mode is disabled, size, length, and buffer address pointer in both transmit and receive descriptors do not need to be word-aligned. That is to say, GDMA can read data of specified length (1 ~ 4095 bytes) from any s tart ad dresses in the accessible address range, or write received data of the specified length (1 ~ 4095 bytes) to any contiguous addresses in the accessible address range.

When burst mode is enabled, size, length, and buffer address pointer in transmit descriptors are also not necessarily word-aligned. However, size and buffer address pointer in receive descriptors except length should be word-aligned.

2.4.8 Arbitration

To ensure timely response to peripherals running at a high speed with low latency (such as SPI), the GDMA controller implements a fixed-priority channel arbitration scheme. That is to say, each channel can be assigned a priority from 0 ~ 9. The larger the number, the higher the priority, and the more timely the response. When several channels are assigned the same priority, the GDMA controller adopts a round-robin arbitration scheme.

Please note that the overall throughput of peripherals with GDMA feature cannot exceed the maximum bandwidth of the GDMA, so that requests from low-priority peripherals can be responded to.

2.5 GDMA Interrupts

• • DMA_INFIFO_OVF_CH n _INT: Triggered when the RX FIFO of GDMA overflows.
• • GDMA_INFIFO_UDF_CH n _INT: Triggered when the RX FIFO of GDMA underflows.
• • GMA_OUTFIFO_OVF_CH n _INT: Triggered when the TX FIFO of GDMA overflows.
• • GDMA_OUTFIFO_UDF_CH n _INT: Triggered when the TX FIFO of GDMA underflows.
• • GDMA_OUT_TOTAL_EOF_CH n _INT: Triggered when all data corresponding to a linked list (including multiple descriptors) has been sent via transmit channel n .
• • GDMA_IN_DSCR_EMPTY_CH n _INT: Triggered when the size of the buffer pointed by receive descriptors is smaller than the length of data to be received via receive channel n .
• • GDMA_OUT_DSCR_ERR_CH n _INT: Triggered when an error is detected in a transmit descriptor on transmit channel n .
• • GDMA_IN_DSCR_ERR_CH n _INT: Triggered when an error is detected in a receive descriptor on receive channel n .
• • GDMA_OUT_EOF_CH n _INT: Triggered when EOF in a transmit descriptor is 1 and data corresponding to this descriptor has been sent via transmit channel n . If GDMA_OUT_EOF_MODE_CH n is 0, this interrupt will be triggered when the last byte of data corresponding to this descriptor enters GDMA's transmit channel; if GDMA_OUT_EOF_MODE_CH n is 1, this interrupt is triggered when the last byte of data is taken from GDMA's transmit channel.

• • GDMA_OUT_DONE_CH n _INT: Triggered when all data corresponding to a transmit descriptor has been sent via transmit channel n .
• • GDMA_IN_ERR_EOF_CH n _INT: Triggered when an error is detected in the data segment corresponding to a descriptor received via receive channel n . This interrupt is used only for UHCI0 peripheral (UART0 or UART1).
• • GDMA_IN_SUC_EOF_CH n _INT: Triggered when the suc_eof bit in a receive descriptor is 1 and the data corresponding to this receive descriptor has been received via receive channel n .
• • GDMA_IN_DONE_CH n _INT: Triggered when all data corresponding to a receive descriptor has been received via receive channel n .

2.6 Programming Procedures

2.6.1 Programming Procedure for GDMA Clock and Reset

GDMA's clock and reset should be configured as follows:

• 1. Set SYSTEM_DMA_CLK_EN to enable GDMA's clock;
• 2. Clear SYSTEM_DMA_RST to reset GDMA.

2.6.2 Programming Pr ocedures for GDMA's Transmit Channel

To transmit data, GDMA's transm it channel should be configured by software as follows:

• 1. Set GDMA_OUT_RST_CH n first to 1 and then to 0, to reset the state machine of GDMA's transmit channel and FIFO pointer;
• 2. Load an outlink, and configure GDMA_OUTLINK_ADDR_CH n with address of the first transmit descriptor;
• 3. Configure GDMA_PERI_OU T_SEL_CH n with the value corresponding to the peripheral to be connected, as shown in Table 2.4-1;
• 4. Set GDMA_OUTLINK_START_CH n to enable GDMA's transmit channel for data transfer;
• 5. Configure and ena ble t he correspondin g peripheral (SPI2, UHCI0 (UART0 or UART1), I2S, AES, SHA, and ADC). See details in individual chapters of these peripherals;
• 6. Wai t for GDMA_OUT_TOTAL_EOF_ CH n _INT interrupt, which indicates the completion of data transfer.

2.6.3 Programming Procedures for GDMA's Receive Channel

To receive data, GDMA's receive channel should be configured by software as follows:

• 1. Set GDMA_IN_RST_CH n first to 1 and then to 0, to reset the state machine of GDMA's receive channel and FIFO pointer;
• 2. Load an inlink, and configure GDMA_INLINK_ADDR_CH n with address of the first receive descriptor;
• 3. Configure GDMA_PERI_I N_SEL_CH n with the value corresponding to the peripheral to be connected, as shown in Table 2.4-1;
• 4. Set GDMA_INLINK_START_CH n to enable GDMA's receive channel for data transfer;

5. Configure and enable the corresponding peripheral (SPI2, UHCI0 (UART0 or UART1), I2S, AES, SHA, and ADC). See details in individual chapters of these peripherals;

2.6.4 Programming Procedures for Memory-to-Memory Transfer

To transfer data from one memory location to another, GDMA should be configured by software as follows:

• 1. Set GDMA_OUT_RST_CH n first to 1 and then to 0, to reset the state machine of GDMA's transmit channel and FIFO pointer;
• 2. Set GDMA_IN_RST_CH n first to 1 and then to 0, to reset the state machine of GDMA's receive channel and FIFO pointer;
• 3. Load an outlink, and configure GDMA_OUTLINK_ADDR_CH n with address of the first transmit descriptor;
• 4. Loa d an inlink, and confi gure GDMA_INLINK_ADDR_CH n with address of the first receive descriptor;
• 5. Set GDMA_MEM_TRANS_EN_CH n to enable memory-to-mem ory transfer;
• 6. Set GDMA_OUTLINK_START_CH n to enable GDMA's trans mit channel for data transfer;
• 7. Set GDMA_INLINK_START_CH n to enable GDMA's receive channel for data transfer;
• 8. If th e suc_eof bit is set in a transm it descriptor, a GDMA_IN_SUC_EOF_CH n _INT interrupt will be triggered when the data segment corresponding to this descriptor has been transmitted.

2.7 Register Summary

The addresses in this section are relative to GDMA base address provided in Table 3.3-3 in Chapter 3 System and Memory .

The abbreviations given in Column Access are explained in Section Access Types for Registers .

2.8 Registers

The addresses in this section are relative to GDMA base address provided in Table 3.3-3 in Chapter 3 System and Memory .

Register 2.1. GDMA_INT_RAW_CH n _REG ( n : 0-2) (0x0000+ 16* n )

• GDMA_IN_DONE_CH n _INT_RAW The raw interrupt bit turns to high level when the last data pointed by one receive descriptor has been received for RX channel 0. (R/WTC/SS)
• GDMA_IN_SUC_EOF_CH n _INT_RAW The raw interrupt bit turns to high level for RX channel 0 when the last data pointed by one receive descriptor has been received and the suc_eof bit in this descriptor is 1. For UHCI0, the raw interrupt bit turns to high level when the last data pointed by one receive descriptor has been received and no data error is detected for RX channel 0. (R/WTC/SS)
• GDMA_IN_ERR_EOF_CH n _INT_RAW The raw interrupt bit turns to high level when data error is detected only in the case that the peripheral is UHCI0 for RX channel 0. For other peripherals, this raw interrupt is reserved. (R/WTC/SS)
• GDMA_OUT_DONE_CH n _INT_RAW The raw interrupt bit turns to high level when the last data pointed by one transmit descriptor has been transmitted to peripherals for TX channel 0. (R/WTC/SS)
• GDMA_OUT_EOF_CH n _INT_RAW The raw interrupt bit turns to high level when the last data pointed by one transmit descriptor has been read from memory for TX channel 0. (R/WTC/SS)
• GDMA_IN_DSCR_ERR_CH n _INT_RAW The raw interrupt bit turns to high level when detecting receive descriptor error, including owner error, the second and third word error of receive descriptor for RX channel 0. (R/WTC/SS)
• GDMA_OUT_DSCR_ERR_CH n _INT_RAW The raw interrupt bit turns to high level when detecting transmit descriptor error, including owner error, the second and third word error of transmit descriptor for TX channel 0. (R/WTC/SS)

Continued on the next page...

Continued from the previous page...

• GDMA_IN_DSCR_EMPTY_CH n _INT_RAW The raw interrupt bit turns to high level when RX buffer pointed by inlink is full and receiving data is not completed, but there is no more inlink for RX channel 0. (R/WTC/SS)
• GDMA_OUT_TOTAL_EOF_CH n _INT_RAW The raw interrupt bit turns to high level when data corresponding a outlink (includes one descriptor or few descriptors) is transmitted out for TX channel 0. (R/WTC/SS)
• GDMA_INFIFO_OVF_CH n _INT_RAW This raw interrupt bit turns to high level when level 1 FIFO of RX channel 0 is overflow. (R/WTC/SS)
• GDMA_INFIFO_UDF_CH n _INT_RAW This raw interrupt bit turns to high level when level 1 FIFO of RX channel 0 is underflow. (R/WTC/SS)
• GDMA_OUTFIFO_OVF_CH n _INT_RAW This raw interrupt bit turns to high level when level 1 FIFO of TX channel 0 is overflow. (R/WTC/SS)
• GDMA_OUTFIFO_UDF_CH n _INT_RAW This raw interrupt bit turns to high level when level 1 FIFO of TX channel 0 is underflow. (R/WTC/SS)

• GDMA_IN_DONE_CH n _INT_ST The raw interrupt status bit for the GDMA_IN_DONE_CH_INT interrupt. (RO)
• GDMA_IN_SUC_EOF_CH n _INT_ST The raw interrupt status bit for the GDMA_IN_SUC_EOF_CH_INT interrupt. (RO)
• GDMA_IN_ERR_EOF_CH n _INT_ST The raw interrupt status bit for the GDMA_IN_ERR_EOF_CH_INT interrupt. (RO)
• GDMA_OUT_DONE_CH n _INT_ST The raw interrupt status bit for the GDMA_OUT_DONE_CH_INT interrupt. (RO)
• GDMA_OUT_EOF_CH n _INT_ST The raw interrupt status bit for the GDMA_OUT_EOF_CH_INT interrupt. (RO)

Register 2.3. GDMA_INT_ENA_CH n _REG ( n : 0-2) (0x0008+16* n )

GDMA_IN_DONE_CH n _INT_ENA The interrupt enable bit for the GDMA_IN_DONE_CH_INT interrupt. (R/W)

• GDMA_IN_SUC_EOF_CH n _INT_ENA The interrupt enable bit for the GDMA_IN_SUC_EOF_CH_INT interrupt. (R/W)
• GDMA_IN_ERR_EOF_CH n _INT_ENA The interrupt enable bit for the GDMA_IN_ERR_EOF_CH_INT interrupt. (R/W)
• GDMA_OUT_DONE_CH n _INT_ENA The interrupt enable bit for the GDMA_OUT_DONE_CH_INT interrupt. (R/W)
• GDMA_OUT_EOF_CH n _INT_ENA The interrupt enable bit for the GDMA_OUT_EOF_CH_INT interrupt. (R/W)
• GDMA_IN_DSCR_ERR_CH n _INT_ENA The interrupt enable bit for the GDMA_IN_DSCR_ERR_CH_INT interrupt. (R/W)
• GDMA_OUT_DSCR_ERR_CH n _INT_ENA The interrupt enable bit for the GDMA_OUT_DSCR_ERR_CH_INT interrupt. (R/W)
• GDMA_IN_DSCR_EMPTY_CH n _INT_ENA The interrupt enable bit for the GDMA_IN_DSCR_EMPTY_CH_INT interrupt. (R/W)
• GDMA_OUT_TOTAL_EOF_CH n _INT_ENA The interrupt enable bit for the GDMA_OUT_TOTAL_EOF_CH_INT interrupt. (R/W)
• GDMA_INFIFO_OVF_CH n _INT_ENA The interrupt enable bit for the GDMA_INFIFO_OVF_L1_CH_INT interrupt. (R/W)
• GDMA_INFIFO_UDF_CH n _INT_ENA The interrupt enable bit for the GDMA_INFIFO_UDF_L1_CH_INT interrupt. (R/W)
• GDMA_OUTFIFO_OVF_CH n _INT_ENA The interrupt enable bit for the GDMA_OUTFIFO_OVF_L1_CH_INT interrupt. (R/W)
• GDMA_OUTFIFO_UDF_CH n _INT_ENA The interrupt enable bit for the GDMA_OUTFIFO_UDF_L1_CH_INT interrupt. (R/W)

Register 2.4. GDMA_INT_CLR_CH n _REG ( n : 0-2) (0x000C+16* n )

GDMA_IN_DONE_CH n _INT_CLR Set this bit to clear the GDMA_IN_DONE_CH_INT interrupt. (WT)

• GDMA_IN_SUC_EOF_CH n _INT_CLR Set this bit to clear the GDMA_IN_SUC_EOF_CH_INT interrupt. (WT)
• GDMA_IN_ERR_EOF_CH n _INT_CLR Set this bit to clear the GDMA_IN_ERR_EOF_CH_INT interrupt. (WT)
• GDMA_OUT_DONE_CH n _INT_CLR Set this bit to clear the GDMA_OUT_DONE_CH_INT interrupt. (WT)
• GDMA_OUT_EOF_CH n _INT_CLR Set this bit to clear the GDMA_OUT_EOF_CH_INT interrupt. (WT)
• GDMA_IN_DSCR_ERR_CH n _INT_CLR Set this bit to clear the GDMA_IN_DSCR_ERR_CH_INT interrupt. (WT)
• GDMA_OUT_DSCR_ERR_CH n _INT_CLR Set this bit to clear the GDMA_OUT_DSCR_ERR_CH_INT interrupt. (WT)
• GDMA_IN_DSCR_EMPTY_CH n _INT_CLR Set this bit to clear the GDMA_IN_DSCR_EMPTY_CH_INT interrupt. (WT)
• GDMA_OUT_TOTAL_EOF_CH n _INT_CLR Set this bit to clear the GDMA_OUT_TOTAL_EOF_CH_INT interrupt. (WT)
• GDMA_INFIFO_OVF_CH n _INT_CLR Set this bit to clear the GDMA_INFIFO_OVF_L1_CH_INT interrupt. (WT)
• GDMA_INFIFO_UDF_CH n _INT_CLR Set this bit to clear the GDMA_INFIFO_UDF_L1_CH_INT interrupt. (WT)
• GDMA_OUTFIFO_OVF_CH n _INT_CLR Set this bit to clear the GDMA_OUTFIFO_OVF_L1_CH_INT interrupt. (WT)
• GDMA_OUTFIFO_UDF_CH n _INT_CLR Set this bit to clear the GDMA_OUTFIFO_UDF_L1_CH_INT interrupt. (WT)