19. Hardware signal processor (HSP)

This section only applies to STM32U3B5/3C5 devices.

19.1 HSP introduction

The hardware signal processor (HSP) is a dedicated signal processor engine. It can offload and speed up operations initially handled by the CPU. It targets the following application areas:

• • Control loops
• • Metering
• • Small convolutional neural networks
• • General-purpose signal processing

The HSP is built around a dedicated high-performance signal processor engine (SPE) working in 32-bit floating point or 8-bit integer. The SPE runs the HSP microcode (also named firmware).

A part of the microcode (firmware) is embedded in a private ROM. This microcode provides optimized signal processing functions, named “processing functions”.

The HSP can perform sequences of operations autonomously. These sequences are called “processing lists”.

As shown in the figure below, the HSP proposes a sequencer to handle the processing lists, and a direct command interface for the accelerator function.

The peripherals connected to the event controller generate events according to their activity. These events are handled by the event controller, and the event having the highest priority activates a task. This task executes the recorded processing list. If other events are pending, the sequence is repeated when the execution of the current processing list is completed.

Each task can host a single processing list.

Figure 67. HSP functional view

The application can record up to 37 processing lists into the HSP during the runtime. A processing list represents an HSP task. The execution of processing lists is triggered by events. The event sources can be:

• • STREAM interface
• • Trigger signals
• • Software triggers

The HSP offers the following bus interfaces:

• • An AHB slave port interface giving access to the HSP control registers (SP0)
• • An AHB slave port interface giving access to the HSP memories (SP1)

When the data to be processed are 16- or 32-bit integers, the HSP converts them into a 32-bit floating-point format before performing the required processing.

If the data are in 8-bit integer or 32-bit floating-point format, the HSP processes them directly.

Data exchange between the HSP and the application can be done in several ways:

• • Using the BRAM as a shared memory
• • Using data registers via the STREAM interface

After each processing task performed in 32-bit floating-point format, the HSP can provide the data either in floating-point or integer format. Processing performed using an 8-bit integer returns results in 8-bit integer format.

See the user manual HSP processing functions on STM32 MCUs (UM3360) .

Finally, the HSP offers an interrupt interface allowing the application to receive interrupts from a wide variety of events.

19.2 HSP main features

• • AHB slave interface for memories (SP1)
• • AHB slave interface for register control (SP0)
• • Rich set of signal processing commands (such as FFT, FIR, or IIR)
• • Support of 2D convolution for neural networks
• • Operations performed in floating-point single precision compliant with the IEEE-754 standard

The HSP FPU is compliant with the IEEE-754 standard with the following limitations:

• – Denormals are flushed to zero.
• – Only round to the nearest is supported.
• • Supported data formats:
  • – Signed/unsigned 16-bit integer format
  • – Signed/unsigned 32-bit integer format
  • – 32-bit floating-point format
  • – 8-bit integer (CNN functions)
• • Trigger inputs
• • Break generation
• • STREAM interface
• • Trigger outputs
• • Interrupt services

Targeted applications:

• • Audio: speech capture
• • Motor control
• • Digital power
• • Metering

19.3 HSP implementation

The table below details the set of features implemented into the product.

Table 143. HSP features ⁽¹⁾

1. 'X' = supported, '-' = not supported.

Table 144. HSP memory mapping

19.4 HSP functional description

19.4.1 HSP block diagram

Figure 68. HSP block diagram

1. 1. The number of trigger inputs depends on the product, see Section 19.3: HSP implementation .
2. 2. These interrupt lines are not always connected, see Section 19.3: HSP implementation .

19.4.2 HSP pins and internal signals

Table 145. HSP external pins

Table 146. HSP internal signals

Table 146. HSP internal signals (continued)

1. 1. This interrupt line is not always connected to the interrupt controller, see Section 19.3: HSP implementation .
2. 2. The number of trigger input signals depends on the product, see Section 19.3: HSP implementation .

The table below shows how HSP trigger inputs are connected in the product.

Table 147. HSP trigger input connections

The table below shows how HSP trigger outputs are connected in the product.

The table below shows how HSP break outputs are connected in the product.

Table 149. HSP break connections (continued)

19.4.3 Floating-point format

The HSP is a powerful and flexible signal processing engine, able to perform operations on data located into its shared memory (BRAM).

The HSP can work by processing data blocks (vector) or sample per sample. The latter mode is particularly helpful for closed-loop control.

The HSP supports several kinds of data input formats: 8-, 16-, 32-bit integers, and 32-bit floating points. For simplification, this document refers to 32-bit floating points as “float32”. In the same way, signed 8-bit integers are named “int8”.

The SPE embedded into the HSP performs its computation in single-precision floating points (float32) or 8-bit integers (int8).

As defined by the IEEE-754 standard, the single-precision floating-point numbers are stored into the memory as shown in the figure below.

Figure 69. Single-precision floating-point format

The single precision floating-point number includes:

• • A sign bit
• • A significand part of 23 bits
• • An exponent of 8 bits (-126 to + 127)

The first leading 1 bit of a normalized significand is “hidden”, or “implicit”, extending the significand to 24-bit precision.

Floating point greatly simplifies working with large numbers, up to about \( \pm 3.4e^{38} \) , and small numbers down to about \( \pm 1.17e^{-38} \) .

The HSP embeds the capability of converting integers into float32 and vice versa.

The HSP also supports integer 8-bit operations. They are dedicated to run convolutional neural networks. In this mode, the internal accumulator size is 32 bits to keep the best accuracy.

19.4.4 Memory management

A memory controller (MMC) manages the SRAM shared with the HSP. This SRAM can be used by the application like any other SRAM or dedicated to HSP activity when the HSP is activated (see Section 19.3: HSP implementation to check which SRAM is shared with the HSP on the product). This SRAM is split into five different sections when the application intends to use the HSP. The different sections are listed below:

• • The code RAM (CRAM) section, containing the HSP firmware program, plug-ins, and processing lists
• • The data RAM (DRAM) section, containing SPE sensitive data and processing list parameters
• • The buffer RAM A (BRAM-A), RAM B (BRAM-B), and RAM-AB sections, containing the working data, filter coefficients, and filter states

In addition, the HSP embeds a code ROM and a data ROM:

• • The code ROM (CROM) contains the generic signal processing functions library.
• • The data ROM (DROM) contains constants, such as FFT coefficients.

Figure 70. MMC overview

Memory protection and sharing

The access to the memory shared with the HSP is controlled by the MMC (memory controller) block. After a system reset, this SRAM is available for the application, and can be used as a general-purpose SRAM.

Note: This SRAM can be enabled or disabled via an RCC control bit. Make sure it is enabled before using it.

The BRAM-A, BRAM-B, and BRAM-AB sections are always shared with the application and are generally used for data exchanges and working buffers.

The application can restrict the access to CRAM and DRAM sections with the CDRLCK[1:0] bitfield in the HSP control register (HSP_CR) . CRAM and DRAM access filtering works as follows:

• • CDRLCK[1:0] = 0: read and write access through the AHB slave of CRAM and DRAM is allowed.
• • CDRLCK[1:0] = 1: write access to CRAM and DRAM is not allowed. Any read access is allowed. Only an HSP reset can restore write access to these memories.
• • CDRLCK[1:0] = 2 or 3: read and write access to CRAM and DRAM is not allowed. Only an HSP reset can restore read and write access to these memories.

An invalid application read access to a RAM protected by CDRLCK[1:0] returns 0. An invalid application write access to a RAM protected by CDRLCK[1:0] is ignored. In both cases, the ACCERRF and SAHBERR flags are set.

Accessing above BRAMAB_END (see Figure 71 ) also generates a bus error. The ACCERRF and SAHBERR flags are set as well.

See Section 19.4.12: HSP interrupt controller (HITC) .

The access restrictions programmed with CDRLCK[1:0] do not affect the SPE.

Note:

The application must first enable the hsp_hclk_core_ck (via the RCC) to change the value of CDRLCK[1:0]. Once CDRLCK[1:0] is updated, the hsp_hclk_core_ck can be disabled.

If the HSP was previously activated, it is recommended to reset the HSP before reusing the shared SRAM. The HSP reset is handled by the RCC.

Table 150 shows the address offset of each memory section. The BRAM is seen as two single ports, or like a dual port (BRAM-AB). Depending on the operations requested from the HSP, the application must use a dual-port BRAM or single-port BRAMs.

Table 150. Memory mapping seen from MMC AHB slave ⁽¹⁾

1. 1. CRAM_SIZE, DRAM_SIZE, and BRAM_SIZE represent the size, in Kbytes, of CRAM, DRAM, and BRAM respectively. Refer to section Section 19.3: HSP implementation for memory size.

As shown in Figure 71 , the application sees the SRAM shared with the HSP as a contiguous memory block, with the capacity to restrict access to CRAM and DRAM blocks. When the HSP is enabled, the CPU can still access this SRAM, but the HSP also uses it.

For the HSP to run safely, it is recommended to write-protect CRAM and DRAM as soon as the application has loaded the main firmware code and its data into CRAM and DRAM.

The CPU can access:

• • BRAM-A, BRAM-B, and DRAM in 8, 16, or 32 bits (and in 64 bits, if the product supports it)
• • CRAM in 8, 16, or 32 bits.

Figure 71. Memory mapping seen from the AHB slave port SP1

Memory resource arbitration

When the HSP is running, the BRAM-AB, BRAM-A, or BRAM-B can be accessed by the SPE or by the application through the AHB slave interface.

To keep the best SPE performances, the MMC arbiter gives the highest priority to the SPE. However, some processing done by the SPE can take 100% of the BRAM resource, preventing the other requesters from accessing the BRAM. To avoid this, the MMC ensures that if the application requests the BRAM resource, the resource is granted in the worst case after 16, 8, or 4 cycles. BARB[1:0] in the HSP control register (HSP_CR) allows the selection of one of these values.

As shown in Figure 72 , a fixed-priority arbiter (FPA) ensures that the request coming from the AHB slave interface is granted at most every 16, 8, or 4 cycles. This mechanism prevents important degradation of SPE performances.

The right part of the figure shows an arbitration example.

• • The SPE occupies 100% of the BRAM bandwidth. After k clock periods, the AHB slave must access the BRAM-AB.
• • After N cycles (k + N), the AHB slave can perform its transaction. N can be either 4, 8, or 16.

When the SPE no longer uses the BRAM, the AHB slave transactions are served immediately using the full bandwidth.

Figure 72. BRAM arbitration

19.4.5 HSP boot

Before running the HSP, the application must copy the HSP firmware code into the code RAM (CRAM) and data RAM (DRAM). Additionally, some applications can also request to copy plug-ins. Plug-ins are extra binary codes provided by STMicroelectronics and used to correct the limitations of existing processing functions, or to add new processing functions not included in the original product.

The binary files must be copied as shown in Figure 73 :

• • If no plug-ins are loaded, the application must write a termination word (0xFFFF FFFF) right after the copied binary code.
• • If plug-ins must be added, they must be copied contiguous to the HSP firmware binary code, and the termination word must be added right after the last plug-in.

Figure 73. HSP code loading

Refer to Section 19.3: HSP implementation to find which SRAM instance contains BRAM, CRAM, and DRAM on the product, as well as the relative address offset.

The application must execute the sequence below to run the HSP properly:

1. 1. Reset the HSP using the reset bit in the RCC.
2. 2. Copy the HSP firmware binary code and the RO data into the CRAM and DRAM sections respectively. Copy plug-in binaries, if any, into the CRAM.
3. 3. Enable the HSP core clock via the RCC.
4. 4. If needed, protect CRAM and DRAM sections against accidental corruption via CDRLCK[1:0].
5. 5. Set the BOOTEN bit to run the HSP. The HSP executes the code starting at the CRAM base address of the CRAM, and enters the HSPCFG state.

1. 1. 6. In HSPCFG state, the HSP firmware performs the following operations:
      1. a) Initialize the internal HSP subblocks. TSKLUT is also initialized to only allow the activation of the supervisor (PLSUP) or Direct Command Accelerator functions (PLDCMD).
      2. b) Copy the firmware versions and SPE into HSP_FWVERR and HSP_SPEVERR.
      3. c) Set BSTAT[3:0] to 1, indicating it is waiting for the FW_INIT command.
   2. 7. The HSP firmware is now ready to accept the FW_INIT command.
   3. 8. When the FW_INIT command is complete, the HSP firmware activates the plugin codes, if any. This phase sets BSTAT[3:0] to 8.
   4. 9. The HSP enters the RUN phase and the WFE state, and sets BSTAT[3:0] to 2. As soon as an enabled event is activated, the HSP exits the WFE state and goes to:
      1. a) PLRUN if the selected event is valid (meaning it is associated with an existing processing list). The HSP firmware executes the processing list corresponding to the selected event, and goes back to WFE.
      2. b) PLSUP if the selected event corresponds to the supervisor. The HSP firmware executes the command sent by the application and goes back to WFE. Processing lists are created in this mode.
      3. c) PLDCMD if a direct command is programmed via the DCMD block.
      4. d) PLFAIL if the selected event is not valid.
2. In PLDCMD mode, the HSP firmware executes the command sent by the application and goes back to WFE.
3. In PLFAIL, the HSP firmware sets the FWERRF bit, sets the firmware error code in FWERRN[9:0], and goes back to WFE.

If an error occurs during this initialization process, the HSP firmware goes to the CFGFAIL state. In the CFGFAIL state, BSTAT[3:0] is set to 9. To set the HSP firmware back to the HSPCFG state, the HSP must be reset through the RCC.

When the HSP firmware initialization is completed, the application can enable the events, which are supposed to trigger the programmed processing list.

BOOTEN, CDRLOCK[1:0], and BSTAT[3:0] are located in the HSP control register (HSP_CR) .

Figure 74. HSP start-up

MSV74835V2

The table below shows the different values BSTAT can take.

Table 151. BSTAT possible values

19.4.6 Message box (MSGB)

The message box (MSGB) offers various services dedicated to the HSP firmware configuration.

The MSGB block contains an HSP-to-CPU and a CPU-to-HSP message interface with:

• • Synchronization flags and interrupt capabilities
• • Two payload registers

The MSGB is generally used with the HSP parameter register x (HSP_PARAMRx) to provide the message payload. Messages are used to configure the HSP firmware part, especially to record the processing list.

Figure 75. MSGB block diagram

CPU to HSP message interface

Using polling mode

When the CPU wants to send a message to the HSP, it has to do the following:

1. 1. Read C2HSEM in the HSP CPU-to-HSP semaphore register (HSP_C2HSEMR) .
2. 2. Wait until C2HSEM = 0, indicating that the previous message has been read by the HSP and a new message can be transferred.
3. 3. Write a new value in the HSP CPU-to-HSP message data register (HSP_C2HMSGDR) .
4. 4. Set C2HSEM.

On its side, the HSP does the following:

1. 1. Read the C2HSEM bit.
2. 2. Wait until C2HSEM = 1, indicating that a new message is available.
3. 3. Read the C2HDATA.
4. 4. Clear C2HSEM to indicate that the message has been read.

Using interrupt mode

The MSGB can generate interrupts to the CPU when the CPU-to-HSP mailbox is ready to receive a new message (through the C2HMFREEF flag).

The CPU must first enable the interrupts by executing the sequence below:

1. 1. Clear the C2HMFREEF flag by setting C2HMFREEC in the HSP events interrupt clear register (HSP_EVT_ICR) .
2. 2. Allow the C2HMFREEF flag to generate an interrupt by setting C2HMFREEIE in the HSP events interrupt enable register (HSP_EVT_IER) .

When an event interrupt occurs, the interrupt subroutine (ISR) must do the following:

1. 1. Read the C2HMFREEF flag in the HSP events interrupt status register (HSP_EVT_ISR) .
2. 2. If C2HMFREEF is set:
   • – The CPU can clear this flag by setting C2HMFREEC.
   • – The CPU can write a new message.
   • – When the CPU wants to notify the HSP that a new message is available, C2HSEM must be set.

The last two steps can be done outside the ISR.

HSP-to-CPU message interface

Using polling mode

When the HSP wants to send a message to the CPU, it does the following:

1. 1. Read the H2CSEM flag.
2. 2. Wait until H2CSEM = 0, indicating that the previous message has been read by the CPU and the content of HSP_SPE_H2CMSGDR can be overwritten.
3. 3. Write the new value into C2HDATA.
4. 4. Set H2CSEM.

On its side, the CPU does the following:

1. 1. Read H2CSEM in the HSP HSP-to-CPU semaphore register (HSP_H2CSEMR) .
2. 2. Wait until H2CSEM = 1, indicating that a new message is available.
3. 3. Read the HSP HSP-to-CPU message data register (HSP_H2CMMSGDR) .
4. 4. Clear H2CSEM in the HSP HSP-to-CPU semaphore register (HSP_H2CSEMR) to indicate that the message has been read.

Note: Handling the MSGB in polling mode also sets H2CMRDYF and C2HMFREEF. Prior to using these flags, the software must clear them.

If the CPU and the HSP set and clear C2HSEM at the same time respectively, C2HSEM is cleared.

If the CPU and the HSP set and clear C2HSEM at the same time respectively, C2HSEM is cleared.

Using interrupt mode

The MSGB can generate interrupts to the CPU when a new message is available for the CPU (through the H2CMRDYF flag).

The CPU must first enable the interrupts by executing the sequence below:

1. 1. Clear the H2CMRDYF flag by setting the H2CMRDYC bit in the HSP events interrupt clear register (HSP_EVT_ICR) .
2. 2. Allow the H2CMRDYF flag to generate an interrupt by setting the H2CMRDYIE bit in the HSP events interrupt enable register (HSP_EVT_IER) .

When an event interrupt occurs, the interrupt subroutine (ISR) must do the following:

1. 1. Read the H2CMRDYF flag in the HSP events interrupt status register (HSP_EVT_ISR) .
2. 2. If H2CMRDYF is set:
   • – The CPU can clear this flag by setting H2CMRDYC.
   • – The CPU can read the message.
   • – When the CPU decides to free the message box, the H2CSEM bit must be cleared.

The last two steps can be done outside the ISR.

19.4.7 Direct command interface (DCMD)

The direct command interface (DCMD) is dedicated to the execution of direct commands, reducing the command overhead in an efficient way. It is used for HSP accelerator mode. This block is controlled by the HSP with a PLDCMD dedicated processing list (refer to Section 19.6.4: Executing direct commands (accelerator mode) ).

The DCMCD provides the following services:

• • Direct command ID register, for triggering events
• • Up to three data pointer interfaces
• • Status flags

The DCMD is generally used with the HSP parameter register x (HSP_PARAMRx) to provide the parameters corresponding to the command that the application wants to execute.

Figure 76. DCMD block diagram

Prior to running a direct command, the SPE must perform the following preliminary operations:

1. 1. Decode the command
2. 2. Adapt the data pointer values
3. 3. Execute the command

To reduce latency in command decoding, the DCMD block allows the SPE to start command decoding while the CPU is still providing the parameters.

By default, the DCMD block is enabled. DCMDDIS in the HSP BUFF configuration register (HSP_BUFFCFGR) controls the enabling and disabling of this function. This bit is write-once after an HSP reset. If the application wants to ensure that the DCMD cannot be accidentally disabled, it must clear DCMDDIS. If the application wants to disable the DCMD, DCMDDIS must be set.

The CPU can transmit the command ID to be executed by writing the command ID in the HSP DCMD command ID register (HSP_DCMDIDR) .

A write access to this register triggers two actions:

• • It sets the DCBSY flag.
• • It asserts the DCMD event ( dcmd_evt ).

dcmd_evt triggers a processing list dedicated to the execution of direct commands. The number of this processing list is 38, and its priority is set to 26.

The DCBSY flag is cleared by the SPE when the direct command execution is completed.

The HSP DCMD address pointer register x (HSP_DCMDPTRx) allows the CPU to provide to the SPE the address pointers requested by the direct commands.

When the CPU writes an address pointer into one of the HSP_DCMDPTRx registers, the HSP hardware sets the corresponding PTRF[x] flag in the HSP DCMD pointer status register (HSP_DCMDPTRSR) .

When the SPE reads this pointer, the DCMD hardware sets the corresponding PTRFx bit to zero. The DCMD also provides a bit (RDOG) indicating if the SPE is performing a read operation of one of the three data pointers. This bit can be used in a debug phase to check if the SPE is waiting for a data pointer value.

Note: If the SPE reads a pointer register not yet updated by the CPU, the SPE remains frozen on the read operation until the CPU has updated the corresponding pointer register.

The DCMD also offers the possibility to generate an interrupt when the DCBSY flag is cleared, meaning that the command has been completed. The interrupt is enabled by setting DCDONEIE in the HSP events interrupt enable register (HSP_EVT_IER) .

Figure 77 shows a typical example of a command programming sequence, and the behavior of the various signals. During an initialization sequence, the CPU is assumed to clear DCMDDIS.

1. 1. The CPU writes the command ID in the HSP DCMD command ID register (HSP_DCMDIDR) . The DCBSY and dcmd_evt are set (#1 in the figure).
2. 2. The CPU writes data parameters in the HSP parameter register x (HSP_PARAMRx) (#2 in the figure).
3. 3. The CPU starts to write the first two address pointers in the HSP DCMD address pointer register x (HSP_DCMDPTRx) . As soon as the EVTC allows it, task number 26 is activated (#3 in the figure).
4. 4. The SPE first reads the command ID to check which command must be executed, and then starts to read the necessary address pointers. The first two address pointers are already available, but the SPE remains blocked for several cycles when reading the third pointer, because the CPU did not yet write it (#4 in the figure).
5. 5. When the CPU writes the third pointer, the SPE gets it translated, and the command can be executed (#5 in the figure).
6. 6. When the command execution is completed, the SPE clears the DCBSY flag. This action clears the dcmd_evt (#6 in the figure).
7. 7. Finally, if DCDONEIE is set, an interrupt can be generated to inform that task execution has been completed. Then the CPU can clear the interrupt (and DCDONEF flag) by setting the clear bit (DCDONEC).

Figure 77. Direct command programming example

If the SPE reads a data pointer not written by the CPU, the SPE remains blocked in the reading operation. The SPE can no longer serve interrupts, nor enter debug mode. The SPE can exit this freeze state through one of the following actions:

• • The application provides the expected data pointer.
• • DCMDDIS is set (if possible). The SPE unfreezes, but executes a command with an invalid pointer, which could be unsafe.
• • The HSP is reset.

The HSP also provides a signal event for the CPU named hsp_txev , indicating that the current direct command execution has been completed. Every time a direct command execution is completed, a single-cycle pulse is generated. DCMDEVEN in the HSP control register (HSP_CR) allows this function activation (see also Section 19.4.12: HSP interrupt controller (HITC) ).

19.4.8 STREAM interface

The STREAM interface can be used if the application wants to trigger an HSP processing list when data are sent to or read from the STREAM interface. It allows the application to set up source- or sink-driven processing.

For example, a DAC associated with a DMA device can take its data from the STREAM interface. As soon as the STREAM interface is read by the DMA device, the SPE is advised and the associated processing list, recorded by the application during an initialization phase, is executed immediately. Typically, this processing list prepares the next sample for the DAC.

Conversely, an ADC associated with a DMA device can provide its data to the STREAM interface. As soon as the STREAM interface is written by the DMA device, the SPE is advised and the associated processing list, recorded by the application during an initialization phase, is executed immediately. Typically, this processing list processes the incoming sample and frees the STREAM interface for the next data.

Figure 78. STREAM block diagram

The STREAM interface provides up to four data buffers of 32 bits. Each of them can be configured either in the CPU-to-HSP direction (C2H) or the HSP-to-CPU direction (H2C). Buffers configured in CPU-to-HSP direction are called C2HBUFF in this document, and buffers configured in HSP-to-CPU direction are called H2CBUFF.

These buffers can be accessed by the application through the HSP BUFFx data register x (HSP_BUFFxDR) .

The data provided by the CPU (C2H direction) can be converted to float32 automatically if the I2FEN bit in the HSP BUFF configuration register (HSP_BUFFCFGR) is set.

The conversion from integer to float32 only works for the following input formats:

• • Signed integers up to 32 bits. The sign extension must always be performed up to 32 bits. The accuracy of a signed 32-bit integer is reduced to 24 bits due to the float32 format.
• • Unsigned integers up to 31 bits. Bit 31 must be cleared. The accuracy is limited to 24 bits due to the float32 format.

The STREAM buffers configured in the C2H direction assert the buff_att signal when a data is written into a STREAM buffer by the application. The buff_att signal remains active as long as the SPE does not read the corresponding STREAM buffer.

The STREAM buffers configured in the H2C direction assert the buff_att signal when they are empty. The buff_att event signal remains active as long as the SPE does not write data into the corresponding STREAM buffer.

The BUFcmb block adds additional flexibility by combining the buff_att[x] signals to generate the buffer events ( buff_evt[x] ). The BUFcmb allows the generation of the buff_evt[x] event, when the corresponding buff_att[x] signal is activated or when both buff_att[x] and buff_att[x+1] signals are activated. The BUFcmb is configured in the HSP BUFF configuration register (HSP_BUFFCFGR) .

Figure 79. BUFcmb details

The table below lists some of the possible configurations:

Table 152. BUFFcmb programming examples

Table 152. BUFFCMB programming examples (continued)

The CPU can configure the buffer directions and the BUF CMB with the HSP BUFF configuration register (HSP_BUFFCFGR) .

The STREAM interface is activated by setting STREAMEN in the HSP BUFF configuration register (HSP_BUFFCFGR) . When STREAMEN is set, it is no longer possible to change the buffer direction, nor to modify the BUFFCMB configuration.

Note: Clearing STREAMEN resets the STREAM block, and all pending buffer events are cleared. Any write access operation to the STREAM buffers is ignored, and read access returns the last data.

The STREAM interface generates an error signal for each buffer and the error signals buff_err[3:0] are asserted:

• • If new data are written into a buffer configured in the C2H direction while the previous data have not been read by the SPE, an overrun error is detected. The new data are written, and the previous ones are lost.
• • If a buffer configured in the H2C direction is read by the CPU while the SPE did not have time to write the new data, an underrun error is detected. In this case, the CPU reads the previous data.

These error signals activate the B[3:0]ERRF flags in the HSP error interrupt status register (HSP_ERR_ISR) . An interrupt to the CPU can be generated if the corresponding interrupt enable flag is set.

The STREAM interface also generates buffer status signals ( buff_rxe_txne[3:0] ). These signals set the corresponding B[3:0]EVT in the HSP events interrupt status register (HSP_EVT_ISR) in each of the following conditions:

• • If the corresponding C2H buffer is empty
• • If the corresponding H2C buffer is not empty

An interrupt to the CPU can be generated if the corresponding interrupt enable flag is set.

buff_att[x] signals are also provided to the TRGO to generate a trigger pulse on hsp_trgo[x] if the SPE reads a C2H buffer, or writes into the H2C buffer.

Figure 80 shows how buff_evt[x] , BxEVT, buff_evt[y] , ByEVT, and TRGO (when enabled) behave in the case of C2H and H2C buffers, when BUF CMB is configured with its default

values (bypass). When STREAMEN is cleared, the complete STREAM interface is reset and the buff_evt[x] and buff_rxe_txne[x] signals return to 0.

Case where BUFF[x] is set in the C2H direction:

1. 1. As soon as STREAMEN is set, B[x]EVTF goes high, indicating that BUFF[x] is empty.
2. 2. When the CPU writes into a BUFF[x], the B[x]EVTF flag goes back to 0 and buff_evt[x] is activated, requesting SPE processing (#1 in the figure).
3. 3. When the SPE reads BUFF[x], the B[x]EVTF flag is set again, buff_evt[x] is released, and a TRGO[x] pulse is generated if selected for the STREAM buffer (#2 in the figure).

Case where BUFF[x] is set in the H2C direction:

1. 1. As soon as STREAMEN is set, the buff_evt[y] signal goes high, requesting SPE activation.
2. 2. When the SPE writes BUFF[x], the B[x]EVTF flag is set, buff_evt[x] is released, and a TRGO[y] pulse is generated if selected for the STREAM buffer (#3 in the figure).
3. 3. When the CPU reads BUFF[x], the B[x]EVTF flag goes back to 0 and buff_evt[x] is activated, requesting SPE processing (#4 in the figure).

When the SPE writes into a BUFF[x], the buff_evt[y] flag goes back to 0, and a TRGO[x] pulse is generated if it is selected for the STREAM buffer (#1 in the figure).

Figure 80. Buffer usage generation example

19.4.9 Trigger input interface (TRGITF)

The HSP embeds up to 10 trigger input blocks, named TRGINx. Each TRGINx receives a trigger input signal from TRGMX. For each TRGINx, the application can select any trigger input signal, and program the activation of an event on a rising or falling edge of the selected signal.

TRGINx blocks can be configured through the HSP TRGIN configuration register (HSP_TRGINCFGR) , HSP TRGIN input selection register 0 (HSP_TRGINSEL0) , HSP TRGIN input selection register 1 (HSP_TRGINSEL1) , and HSP TRGIN input selection register 2 (HSP_TRGINSEL2) .

Each trigger interface can be independently enabled through the HSP BUFF configuration register (HSP_BUFFCFGR) .

The TRGIN blocks perform the following functions:

• • Selecting the rising or falling edge sensitivity to generate an event.
• • Storing a transition, even if this transition is faster than the EVTC internal clock.
• • Performing the clock domain crossing.
• • Storing the event until it is taken into account by the priority encoder.

The pending events are automatically cleared by the TCTL block when the SPE starts the corresponding processing.

Figure 81. TRGITF block diagram

1. The number of trigger inputs depends on the product (see Section 19.3: HSP implementation ).

The TRGMX block allows the application to route any trigger input to any TRGIN interface.

The WKTRG block allows the detection of an enabled pending event even if the TRGITF is not clocked. This signal is used for autonomous functions or to wake up the product if needed.

Note: When TRGIxEN are cleared, the corresponding TRGIN logic is maintained to reset, avoiding the storage of a spurious transition, for example when the polarity is changed. The overrun detector and pending event are also reset when TRGIxEN is cleared.

It is recommended to change the polarity bit and the signal source selection when the corresponding TRGIxEN bit is cleared.

TRGIN overrun detection

Each TRGIN block has an overrun detector checking if a new trigger event occurred while the previous one was not yet taken into account by the SPE. The overrun detector sets the trgin_err[x] signal when an overrun is detected. The overrun controller generates the trgin_ovr signal, setting the TRGIOVRF flag. If the TRGIOVRIE bit is set, an interrupt is generated to the CPU. The application can check which TRGIN block causes the overrun by reading TRGIERR[9:0] in the HSP error information register (HSP_ERRINFR) . When the

application clears the TRGIOVRF flag through the TRGIOVRC bit, all overrun detectors are reset.

See Section 19.4.12: HSP interrupt controller (HITC) .

Note: The overrun function does not work when hsp_hclk_core_ck is not present.

Figure 82 shows a case of overrun detection, using two TRGIN inputs. In the example, trgin_evt[2] activates the task number 2, and trgin_evt[5] activates the task number 5.

hsp_trgi[2] and hsp_trgi[5] receive an event at the same time (#1 in the figure). trgin_evt[2] and trgin_evt[5] are activated. In the example, a higher priority is given to trgin_evt[2] , which is executed as soon as the SPE is available. tsk_active[5:0] indicates that task number 2 is in execution.

While the trgin_evt[5] event is pending, a second trigger is detected in the hsp_trgi[5] input, causing an overrun error (#2 in the figure). The flag TRGIOVRF is set, and trgin_err[9:0] is set to 0x20 (bit 5 set). An interrupt can be activated for the application.

The SPE completed task number 2, and the HSP can serve the pending request from trgin_evt[5] . Task 5 is activated (#3 in the figure).

The hsp_trgi[2] receives two new triggers, the first one activates trgin_evt[2] and the second one activates the overrun error (#4 in the figure). The TRGIOVRF was already set, and the trgin_err[9:0] value is updated to 0x24 (bits 5 and 2 set).

The application reads trgin_err[9:0] and clears TRGIOVRF (#5 in the figure). trgin_err[x] , TRGIOVRF, and trgin_err[9:0] are reset. When the SPE completes task 5, the pending event is served and task 2 is executed again.

Note: Two events have been lost due to overrun.

Figure 82. TRGIN overrun detection

MSv74846V1

19.4.10 Software events generator (SEG)

The CPU can trigger events:

• • By using the event lines shared with STREAM and TRGITF, through the CPU shared event generator (CSEG) block.
• • By using the dedicated event line input 27 through the CPU-dedicated event generator (CDEG) block.

Similarly, the SPE can trigger events either by using the HSEG, or by using the dedicated event line input 0 through the HDEG block.

Figure 83. SEG block diagram

Generating events with CSEG

The CSEG allows the CPU to reuse events not allocated to a peripheral interface, such as STREAM or TRGITF.

For event inputs 1 to 22, the CPU can select the CSEG as the event generator. This is done through the EVTxSRC field for each event input x.

Then, with a simple write access request to the HSP CPU shared event generator register (HSP_CSEGR) , the CPU can trigger one or several events.

The priority encoder of the HSP handles all the activated events according to their priority. The software can check which event is processed by reading back HSP_CSEGR.

Prior to generating an event, the application must enable the CSEG interface by setting CSEGEN in the HSP BUFF configuration register (HSP_BUFFCFG) . When CSEGEN is cleared, the CSEG block is reset and all pending events ( cseg_evt[x] ) are cleared.

Note: There is no protection against overrun situations; the application must ensure that CSEVTx is cleared before setting it again.

For example, if the application wants to activate the event N, it must follow this sequence:

1. 1. Wait for CSEVT[N] = 0. If CSEVT[N] = 1, it means that the HSP did not yet consider the previous request.
2. 2. When CSEVT[N] = 0, set it.

The CSEG block can also be used by the application for debugging purposes, by forcing the execution of a task connected to STREAM or TRGITF. It also allows the CPU to generate events with a high priority level if necessary.

Generating events with CDEG

The CDEG allows the application to trigger any of the 38 tasks through the cdeg_evt event.

The CDEG allows one event to be posted at a time: the CPU needs to wait until the previous event has been taken into account before activating a new event.

Note: The cdeg_evt event is routed to the input number 27 of the priority encoder (PE) having the lowest priority.

Prior to generating events, the application must enable the CDEG interface by setting CDEGEN in the HSP BUFF configuration register (HSP_BUFFCFGR) . When CDEGEN is set to 0, the DSEG block is reset, and cdeg_evt is cleared.

To generate a dedicated event, the CPU must do the following:

1. 1. Wait until the CDEGBSY bit is cleared.
2. 2. Write the task number to execute (0 to 38) in CTSKN[5:0].

When the CPU writes in the HSP CPU dedicated event generation register (HSP_CDEGR) , the prc_evt[27] event is asserted, and CDEGBSY is set. The CDEG block can also generate an interrupt when the current CTSKN[5:0] is taken into account by the HSP.

Figure 84 shows a basic example. The CPU writes in HSP_CDEGR and CTSKN[5:0] is set to N. The write operation in this register sets the cdeg_evt signal and CDEGBSY flag. cdeg_evt is routed to prc_evt[27] . When the task controller is able to serve the task associated with prc_evt[27] , the cdeg_evt signal and CDEGBSY flag are cleared by the TCTL (#1 in the figure), and the CDEGRDYF flag is set, asserting an HSP interrupt if the corresponding interrupt enable control bit is set (#2 in the figure). The CDEG block is ready to accept a new request.

Note: CDEGRDYF is set when a transition from 1 to 0 is detected on the cdeg_evt signal.

CTSKN[5:0] and CDEGBSY are located in the HSP CPU dedicated event generation register (HSP_CDEGR) , and CDEGRDYF is located in the HSP events interrupt status register (HSP_EVT_ISR) .

Figure 84. Example of dedicated event generation

Generating events with HSEG

The HSP shared event generator (HSEG) allows the SPE to reuse events not allocated to a peripheral interface, such as STREAM or TRGITF.

The HSEG block is very similar to the CSEG, but it is dedicated to SPE usage.

Generating events with HDEG

The HSP dedicated event generator (HDEG) allows the SPE firmware to trigger any of the 38 tasks using the event 0.

The HDEG block is similar to the CDEG, but it is dedicated to SPE usage.

19.4.11 Event controller (EVTC)

The event controller (EVTC) collects the events generated by the various HSP internal peripherals and reconditions them. The event with the highest priority activates the corresponding task, which executes the recorded processing list.

• • Handle the STREAM interface.
• • Handle the trigger inputs.
• • Collect application events.
• • Select the event having the highest priority.
• • Ask the SPE to execute the processing list associated with the selected event.

The execution of a processing list can be triggered by several sources:

• • The CPU: up to 38 tasks can be triggered by software.
• • The SPE: up to 38 tasks can be triggered by firmware.

• • Trigger input lines ( hsp_trgi[X:0] ):
  • – Triggers from various device peripherals, such as timers, ADCs, DACs, and ADF/MDF
  • – Up to 20 trigger inputs are available.
• • The STREAM interface:
  • – Allows any peripheral to trigger a processing list.
  • – Has up to four buffers are available.

The EVTC is configured mainly by the application CPU through the AHB slave interface.

Figure 85. EVTC block diagram

Processing request control (PRC)

For each input of the priority encoder, the processing request control (PRC) is in charge:

• • Of selecting the request source that triggers a task through the EVTSRC[2:0]R registers.
• • Of enabling and disabling the synchronization option with the HSP event synchronization enable register (HSP_ESYNCENR) .
• • Of enabling and disabling the generation of the processing request with the HSP event enable register (HSP_EVTENR) .

Figure 86 shows the processing request control details for each type of inputs. Most of the inputs have a processing request source selector, a synchronizer, and a processing request enable.

Figure 86. Processing request control

The synchronization mechanism allows the application to delay the activation of an event until the completion of a specific task.

Figure 87 shows an example of the synchronization usage. Tasks 1 and 2 are running at a regular time interval, and their execution must not be delayed. From time to time, the application needs to run an additional task (18 in the figure), for example, to update dynamic parameters. The application does not want to delay the execution of tasks 1 and 2 due to task 18 execution, so it decides to run task 18 right after task 2, because the time interval between the end of task 2 and the start of task 1 allows it. The application sets TSKCMP0[5:0] to 2 to resynchronize the pending cdeg_evt event with the end of the execution of task 2.

Figure 87. Example of synchronization mechanism

The table below shows which event can be connected for each priority encoder input, and thus which processing task number is activated (tsk_active[5:0]).

Table 153. Trigger sources versus priority and task number ⁽¹⁾

1. 1. BUFF[y] represents the events buff_evt[y] ,
   BUFF[y] represents the events buff_evt[y] ,
   TRGIN[y] represents the events trgin_evt[y] ,
   HSEG[y] represents the events hseg_evt[y] ,
   CSEG[y] represents the events cseg_evt[y] ,
2. 2. With x = 1 to 22.

The following table shows a different view: for each event source, the possible priority levels are shown.

1. 1. The HDEG priority is fixed at 0 but can run any task number. The CDEG behaves similarly but has a priority fixed at 27.
2. 2. BUFF[y] represents the events buff_evt[y]
   TRGIN[y] represents the events trgin_evt[y]
   HSEG[y] represents the events hseg_evt[y]
   CSEG[y] represents the events cseg_evt[y]

Priority encoder (PE) and task controller (TCTL)

The priority encoder defines which event has the highest priority when several events are requesting the execution of processing lists.

The event priority is fixed. The event having the highest priority is the event connected to input 0 of the PE (dedicated to the SPE). The event having the lowest priority is the event connected to input 27.

When no event is pending, pe_evt[5:0] , and task_active[5:0] are equal to 0x3F, and the SPE remains in “wait for event” (WFE).

The TCTL generates the task number to be executed ( task_nb[5:0] ), according to the output provided by the priority encoder ( pe_evt[5:0] signal):

• • If the output of the priority encoder corresponds to the event number 0 ( pe_evt[5:0] = 0 ), the TCTL activates the task number given by HTSKN[5:0]. This field is updated by the SPE when the SPE requests the execution of a specific processing list through the HDEG interface.
• • If the output of the priority encoder corresponds to the event number 27 ( pe_evt[5:0] = 27 ), then the TCTL activates the task number given by CTSKN[5:0]. This field is provided by the CPU when it requested the execution of a specific processing list through the CDEG interface. Note that a specific protection mechanism prevents having a task number higher than 39. If CTSKN is higher than 37, the task number is forced to 39.
• • If the output of the priority encoder corresponds to the event number 26 ( pe_evt[5:0] = 26 ), the TCTL activates task number 38. This task is reserved for direct command handling.
• • Finally, if the output of the priority encoder provides other values, the TCTL consider it as a task number.

When task_nb[5:0] becomes different from 0x3F, the TCSM block latches the value of the task to be executed ( task_active[5:0] ). The active task value is used as an index to read a look-up table (TSKLUT), which contains the address of the task (or processing list) to be executed by the SPE. The TSKLUT is updated by the SPE. Finally, the TCTL asserts the evtc_wkup signal to inform the SPE that a task needs to be executed.

The TCTL is also responsible for clearing TRGINx, SEG, and DCMD events when they are taken into account. When the SPE starts the execution of the selected task, spe_wfe goes to zero, and several cycles later the SPE generates a pulse (on spe_jump_evt ), indicating that the processing list address has been taken into account, and can be updated for the next task to process. In addition, the TCTL generates an error if the SPE does not activate spe_jump_evt in the expected time window.

Figure 88. Task controller details

The task having the highest number (task number 39) is dedicated to the SPE firmware and indicates that an unexpected task number has been activated (PLFAIL). The SPE firmware activates the FWERRF flag with the error code described in Table 155: Firmware error number . An interrupt is generated to the application if enabled.

When no event is pending, the first event to become active is selected. If several events are waiting for a task completion by the SPE, the event having the highest priority is selected when the SPE acknowledges completion of the previous task.

In the example below, initially there are no pending events and the SPE is in WFE. tsk_active[5:0] has a default value output of 0x3F. The evtC_wkup signal is inactive, and the output of tsk_add[19:0] is the address of the maximum task number supported by the product (see Section 19.3: HSP implementation ).

As no event is pending, the first active event is the first served. As soon as prc_evt[12] becomes active ( trgin_evt[4] ), the priority encoder detects that an event is pending, and immediately updates its output pe_evt[5:0] (#1 in the figure). The PESM sees that pe_evt[5:0] is no longer equal to the default value, latches pe_evt[5:0] , asserts evtC_wkup , and clears the selected event source if the event is generated by TRGINx, CDEG, HDEG, CSEG, or HSEG.

The pe_evt[5:0] output is continuously changing according to the event activity.

The SPE exits from WFE (indicated by the clearing of the spe_wfe signal) and executes the processing list given at the address tsk_add[19:0] (@PL12 in the figure below). The SPE informs the EVTC that tsk_add[19:0] can be unfrozen by sending a pulse on spe_jump_evt when it branches to the address defined by tsk_add[19:0] . The EVTC can select the next processing list to execute while PL12 is under execution. When the execution of PL12 is complete, the SPE attempts to go to WFE, and the signal spe_wfe goes to 1 for one cycle. The rising edge of spe_wfe indicates to the EVTC that tsk_add[19:0] must be frozen again. The PESM latches pe_evt[5:0] and keeps evtC_wkup activated. In the example, BUFF0 ( prc_evt[1] ) is selected because at the end of the processing of PL12, prc_evt[1] has the highest priority.

Seeing evtC_wkup still active, the SPE processes PL1. When the SPE completes the execution of the PL1 processing list, it can branch to the execution of PL6.

The prc_evt[1] and prc_evt[6] are cleared when the SPE reads the corresponding buffer. When the SPE acknowledges prc_evt[6] (#2 in the figure), there are no processing requests. The PESM clears evtc_wkup . SPE completes the processing of PL6 and goes to WFE.

Figure 89. Priority encoder example

The EVTC monitors the delay between the moment the SPE exits from WFE and the moment it jumps to the execution of the corresponding task. If there is no jump to the selected processing list when the SPE exits from WFE, the EVTC remains frozen. The application is notified of this abnormal behavior by the assertion of the SCHERRF flag. To recover from this situation, the HSP must be reset through the RCC.

The execution of a task cannot be interrupted by another task.

If an enabled event occurs while a task is in execution, the event remains pending until the corresponding task is executed by the SPE.

If several enabled events occur at the same time, the priority encoder defines which must be served first.

19.4.12 HSP interrupt controller (HITC)

The HSP interrupt controller collects events and flags generated by the various parts of the HSP, and generates interrupts to the application processor and to the SPE.

Figure 90. HSP interrupt controller

1. 1. The signals and blocks related to these signals are not always present (see Section 19.3: HSP implementation ).

Four interrupt lines are provided to the application processor:

• • An interrupt line handling errors ( hsp_err_it )
• • An interrupt line handling various hardware events ( hsp_evt_it )
• • An interrupt line handling events generated by the SPE processing ( hsp_fwevt_it )
• • A global interrupt is asserted when one of the previous interrupts is asserted ( hsp_it )

In addition, the HITC provides a dedicated event output ( hsp_txev ) able to exit the CPU from a WFE state when a direct command execution is completed. There is no need to acknowledge this event. It can be enabled with DCMDEVEN in the HSP control register (HSP_CR) .

The HITC contains several flags, which can be read and cleared at any time by the application. These flags can also generate an interrupt if the corresponding interrupt enables have been set.

The application can enable the interrupts through the HSP error interrupt enable register (HSP_ERR_IER) , HSP events interrupt enable register (HSP_EVT_IER) , and HSP processing event interrupt enable register (HSP_PFCTEVT_IER) .

The application can check the status flags through the HSP error interrupt status register (HSP_ERR_ISR) , HSP events interrupt status register (HSP_EVT_ISR) , and HSP processing event interrupt status register (HSP_PFCTEVT_ISR) .

The application can clear the interrupt sources through the HSP error interrupt clear register (HSP_ERR_ICR) , HSP events interrupt clear register (HSP_EVT_ICR) , and HSP processing event interrupt clear register (HSP_PFCTEVT_ICR) .

For additional information on the interrupt root cause, refer to the HSP error information register (HSP_ERRINFR) .

Description of error flags

This section lists all event sources capable of asserting the error and global interrupt lines.

Figure 91. HSP error interrupt controller.

Floating point unit error (FPUERRF)

The FPUERRF flag reports floating-point exceptions. This flag is activated when one of the following events occurs: UDFLOW, OVFLOW, DIVZERO, INVALID, or DENORM.

In addition, the HSP error information register (HSP_ERRINFR) shows the value of these five exceptions at any time, plus the INEXACT exception.

The six FPU exception signals are generated by the SPE. The meaning of the exceptions is the following:

• • INEXACT: generated when an operation produces a result that does not fit into its intended destination. The result had to be altered by rounding it off to fit. This exception does not set the flag FPUERRF.
  Examples: \( 1 + 2^{-25} \) is rounded to 1 with the INEXACT flag activated, 2.0/3.0 provides inexact rounding as well.
• • UDFLOW: generated when an operation produces a result closer to 0 than what is supported by the float32. This exception sets the flag FPUERRF if UDFIE is set.
• • OVFLOW: generated when the largest representable finite number is exceeded in magnitude by what would have been the rounded floating-point result with the exponent range unbounded. This exception sets the flag FPUERRF if OVFIE is set.
  Example: \( 2^{127} * 4 \) yields an overflow.
• • DIVZERO: generated when a division by zero is performed. This exception sets the flag FPUERRF if DBZIE is set.
• • INVALID: generated when an operation produces a result outside of the float32 domain (such as the square root of a negative number or 0/0). This exception sets the flag FPUERRF if INVIE is set.
• • DENORM: generated when a denormal number is detected. When denormal numbers are detected, they are replaced by 0. This exception sets the flag FPUERRF if DENORMIE is set.

The FPUERRF flag and the information bits UDFLOW, OVFLOW, DIVZERO, INVALID, DENORM, and INEXACT are cleared when FPUERRC is set.

Note: It is possible to freeze HSP execution upon assertion of the FPUERRF flag through the BKITF (see Section 19.4.19: Break interface (BKITF) ).

Access error (ACCERRF)

The HSP indicates that an access error occurred by setting ACCERRF. Several conditions can lead to an access error and the HSP error information register (HSP_ERRINFR) gives additional information on the root cause. The meaning of the flags present in HSP_ERRINFR is described below:

• • CMERR: CRAM/CROM error
  When this flag is set, it means that the SPE fetches or performs load and store operations outside the CRAM/CROM memory range.
• • DMERR: BRAM/DRAM error
  When set, it means that the SPE performs load and store operations outside the BRAM/DRAM memory range.

• • MAHBERR internal AHB master error:

When set, it means that the HSP_CTRL is not properly accessed. This error typically occurs if the SPE performs a wrong access operation to HSP_CTRL.

• • SAHBERR slave AHB error:

When set, it means one of the following:

• – The device tried to access an invalid memory space.
• – The device attempted to write in the CRAM/DRAM memory while it was protected by CDRLOCK[1:0].
• – The device performed a nonsupported access operation through the slave AHB interface, such as an access operation not aligned on 32-bit data.

No error is reported if the device reads or writes into a nonexisting register located in the valid address range of the HSP. When an access operation is not valid, the slave AHB interface always responds to the request with data (in this case 0).

Invalid read access operations return 0. Invalid write access operations are ignored.

Accessing above BRAMAB_END (see Figure 71 ) also generates a bus error.

Note: It is possible to freeze HSP execution upon assertion of the ACCERRF flag through BKITF (see Section 19.4.19: Break interface (BKITF) ).

Firmware errors (FWERRF)

This flag is activated when the SPE firmware code reported error situations. When the SPE meets an error condition, during the code execution, not covered by hardware error flags, the flag FWERRF is activated and FWERRN[9:0] in the HSP firmware error register (HSP_FWERR) is updated.

Note: FWERRN[9:0] is only cleared when the HSP is reset. It always contains the last error code reported by the SPE firmware. Every time the firmware updates the error code, FWERRF is activated, generating a new interrupt if FWERRIE is activated. FWERRF is cleared by the application by setting FWERRC.

Various conditions can lead to the activation of the firmware error flag and FWERRN[9:0] reports the error code detected by the SPE firmware (as detailed in the table below).

Table 155. Firmware error number

1. FWERRN[9:0] is in the HSP firmware error register (HSP_FWERR) .

Scheduler errors (SCHERRF)

This flag is activated when the EVTC remains frozen due to an unexpected behavior of the SPE. More precisely, when the EVTC requests the SPE to execute a task, if the SPE responds OK but does not confirm the jump to the task address, the EVTC remains frozen. When this situation occurs, the SCHERRF flag is activated. The only way to recover from this situation is to reset the HSP.

This flag is activated when the SPE detects an invalid opcode. The SPE executes a NOP for each invalid opcode detected.

Note: It is possible to freeze HSP execution upon assertion of the OPCOERRF flag through BKITF (see Section 19.4.19: Break interface (BKITF) ).

For buffers configured in the C2H direction, this flag represents an overrun. For buffers configured in the H2C direction, it represents an underrun.

This flag is activated when new data are written in C2HBUFFx by the CPU, while the previous data have not yet been read. In this case, the new data are written in C2HBUFFx.

This flag is activated when H2CBUFFx is read by the CPU, while it is empty (HSP did not write any new data on time). In this case, the CPU reads the previous data.

This flag is activated when a new event occurs while the previous event is still pending. The application can check which TRGIN interface generated the overrun through TRGIERR[9:0] in the HSP error information register (HSP_ERRINFR) .

This flag is set when the SPE posts a firmware event while the previous event has not yet been taken into account. The new event posted by the SPE is ignored.

This flag is set when a new capture value must be written in HSP_CAPDR while the device has not yet read the previous one. In this case, the new capture value is dropped.

This flag indicates that the HSP receives a break input event. The SPE is frozen and an application action is needed to restart the HSP (see Section 19.4.19: Break interface (BKITF) ).

Description of event flags

This section lists all the event sources capable of asserting the event and global interrupt lines.

Figure 92. HSP event interrupt controller

CPU-dedicated event generator ready (CDEGRDYF)

It indicates if the execution of the previous event posted by the CPU into the CDEG block has been started. The CPU can use this information to post a new event.

STREAM buffer event (B[3:0]EVTTF)

For buffers configured in the C2H direction, this flag indicates that the buffer is empty. For buffers configured in the H2C direction, this flag indicates that the buffer is not empty.

FPU saturation (FPUSATF)

This flag indicates that the FPU detected and performed a saturation of the signal.

As shown in the figure below, when a saturation is detected, the SPE sets the spe_fpu_sat signal. This signal remains set until the completion of the current processing function. The

FPUSATF flag is set when a rising edge on spe_fpu_sat is detected, and it is cleared when FPCSATC is set.

Figure 93. Saturation flag

Capture buffer ready (CAPRDYF)

It indicates that a new capture value is available in the HSP data capture register (HSP_CAPDR) .

Message box ready and free (H2CMRDYF, C2HMFREEF)

The H2CMRDYF flag indicates that a message is available for the CPU in the MSGB.

The C2HMFREEF flag indicates that the MSGB is free and the CPU can post a new message for the HSP.

Start/end of task event comparator (SOTECF[3:0]F, EOTECF[3:0]F)

SOTECF _x F is set if the task selected by TSKCMP _x is starting.

EOTECF _x F is set if the task selected by TSKCMP _x has just been completed.

Start/end of WFE state (EOFWFEF, SOFWFEF)

SOFWFEF is set when the SPE enters the WFE state.

EOFWFEF is set when the SPE exits the WFE state.

Task overlap (TOVLPF)

This flag is set when the execution of one of the tasks on the selected range has been delayed due to the execution of another task (see Section 19.4.14: Task comparator unit (TCU) ).

Direct command done flag (DCDONEF)

This flag is set when the execution of the current direct command is completed. More precisely, it is set when the DCBSY flag transitions from 1 to 0 (see Section 19.4.7: Direct command interface (DCMD) ).

Processing function flags (PFCTF[31:0]F)

These flags are activated by the processing functions, several of which use flags.

The table below gives a summary of all interrupts that the application can use.

Table 156. HSP interrupt requests

1. 1. HSP_ERR is generated by the hsp_err_it signal; HSP_EVT is generated by the hsp_evt_it signal; HSP_FWEVT is generated by the hsp_fwevt_it signal; HSP_GLOB is generated by the hsp_it signal.
2. 2. This interrupt line is not always connected to the interrupt controller (see Section 19.3: HSP implementation ).

19.4.13 HSP reset and clocking

The HSP MMC block is reset by the product system reset.

The other HSP blocks, including the SPE, are also reset by the product system reset, but can also be reset by the application through a reset control bit in the RCC.

When the application resets the HSP with the RCC control bit, the following conditions must be satisfied:

• • There are no ongoing transactions through its AHB slave interface.
• • The SPE no longer performs transactions through its bus interfaces.

The HSP offers a mechanism to ensure that the SPE has stopped all transactions before a reset. The application must ensure that transactions through its AHB slave interface are stopped.

The application must follow this sequence to set the HSP to a safe state before resetting it with the RCC control bit:

1. 1. Clear the HSP_EVTENR register.
2. 2. In the HSP_ITFENR register, set the DCMDDIS bit and clear all others.
3. 3. Set RSTREQ in HSP_CR.
4. 4. Wait for RSTOK = 1 in HSP_CR.

This bit must go high after 1 ms at most after an RSTREQ assertion. A timeout must control if this delay elapsed.

If RSTOK is set, the application can reset the HSP safely through the RCC reset control bits, by executing the following sequence:

1. a) Disable the HSP clock ( hsp_hclk_core_ck ).
2. b) Set the HSP reset bit to 1.
3. c) Clear the HSP reset bit.
4. d) Enable the HSP clocks.

If the timeout elapsed before RSTOK is set, it cannot be ensured that resetting the HSP does not disturb the activity of other components of the product.

HSP clocking

The HSP works with two clocks that are synchronous to the interconnect clock:

• • hsp_hclk_mem_ck : clock for the memory components and associated logic

This clock allows the application to use the SRAM4 as additional memory even when the HSP is disabled.

• • hsp_hclk_core_ck : clock for the remaining parts of the HSP, including the SPE

When the HSP is disabled or not used (BOOTEN = 0), the CPU must provide hsp_hclk_mem_ck to access the SRAM4.

When the application wants to use the HSP, the CPU must provide hsp_hclk_mem_ck and hsp_hclk_core_ck .

The clock generation is controlled through the RCC.

Smart clock gating

The HSP performs a local clock gating to reduce power consumption. This smart clock gating is activated by default, but can be disabled by CTRLCGDIS, SPECGDIS and MMCCGDIS in the HSP control register (HSP_CR) .

• • When CTRLCGDIS is cleared, parts of the HSP_CTRL block are not clocked when they are inactive.
• • When MMCCGDIS is cleared, the MMC block is not clocked when there is no memory access.
• • When SPECGDIS is cleared, the SPE is not clocked in WFE.

Setting one of these bits forces the clocking of the corresponding block.

Figure 94. HCC block diagram

The HSP can request the bus clock (with the hsp_bus_ckreq signal) when needed.

In addition, the HSP can detect a TRGIN event, even if hsp_hclk_mem_ck and hsp_xclk_core_ck clocks are not provided by the product.

See the low-power capability table “Functionalities depending on the working mode” in the PWR section of the product to check if the bus clock request is supported.

Figure 95 shows a wake-up example using TRGITF.

1. 1. Before the trigger event occurs, the HSP is not clocked at all (#1 in the figure).
2. 2. As soon as the hsp_trgi[0] active edge is detected asynchronously, the HSP asserts the hsp_bus_ckreq signal. After a setup delay generally due to the startup of the

oscillator providing the clock, the RCC provides a bus clock, but the spe_core_ck remains gated (#2 in the figure).

1. 3. Using the bus clock, the EVTC can generate trgin_evt[0] and wakes up the SPE. spe_core_ck is enabled to allow the SPE to process processing list PL3 (#3 in the figure).
2. 4. hsp_bus_ckreq is maintained active until the SPE turns back to WFE. The spe_core_ck clock is gated as well (#4 in the figure).

Figure 95. TRGITF wake-up capabilities

19.4.14 Task comparator unit (TCU)

The TCU offers several services based on the task active value (tsk_active[5:0]) provided by the EVTC.

The TSKCMP[3:0] comparator enables the following features controlled through the HSP task comparator unit register (HSP_TCUCFGR) :

• • Synchronize the generation of an event with the completion of a selected task.
• • Generate an interrupt when the execution of a specific task starts or stops, or when the SPE goes to WFE.
• • Route comparator outputs to I/Os (with HSP_SNP[5:0] I/Os) for debugging or tuning purposes, to check the duration of a task or for task sequencing.

The TCU can also be used to detect if there are task overlap situations. This function informs the application that the execution of several tasks does not occur at the expected time, because the HSP was performing another task. In some applications, this may inform the application that scheduling behaves in an unexpected way.

Figure 96. TCU block diagram

A task overlap situation is detected if between the end of execution of the previous task and the start of the next task, the SPE remains only one clock cycle to WFE. This means that when the previous task execution was completed, there was a request to execute another task. If the delayed task is not in the selected group, the detection is not activated.

The application can define a group of tasks where the overlap situation must be reported; the group range can go from task number 1 to task number 39.

In the figure below, HTNB is set to 19, and LTNB is set to 15, to restrict the test overlap check to tasks 16, 17, and 18. The tasks 16, 5, 57, and 18 have been delayed, but only the delay of tasks 16 and 18 are reported.

Figure 97. Task overlap

Note: In some cases, it is normal to have task overlap situations: for example, when the SPE triggers a new task, or when a task is synchronized with the completion of another task. Selecting a limited group of tasks where the overlap must be checked reduces the risk of having spurious generation of the task overlap event.

To activate the task overlap function, the application must do the following:

1. 1. Select the range of tasks where the overlap condition must be checked, by initializing HTNB[5:0] and LTNB[5:0] in the HSP task overlap control register (HSP_TOVLPCR) to the range boundary.
2. 2. Set the TOVLPIE control bit if an interrupt is requested from the CPU.
3. 3. Set TOVLPEN in the HSP task overlap control register (HSP_TOVLPCR) .

19.4.15 Trigger outputs (TRGO)

The HSP offers the possibility to generate trigger pulses on up to four trigger outputs ( hsp_trgo[3:0] ). The pulse width is one hsp_hclk_core_ck period.

It is also possible for the application to control the level of eight GPOs ( hsp_gpo[7:0] ) using dedicated processing functions.

Figure 98. TRGO block diagram

The TRGO is enabled with TRGOEN in the HSP interface enable register (HSP_ITFENR) . When TRGOEN=0, it is not possible to generate trigger pulses on hsp_trgo[3:0] , nor to change the level of hsp_gpo[7:0] .

A selector allows the application to define the trigger source for one of the four trigger outputs, using the HSP TRGO configuration register (HSP_TRGOCFGR) .

The table below lists the possible trigger sources.

Table 157. List of trigger sources

The trigger output can typically be used to trigger an automatic data transfer using a DMA device. For example:

• • When a pulse is generated from the tsc_capture event, the DMA device can read the HSP data capture register (HSP_CAPDR) and write it into a circular buffer, storing the scheduling history automatically.
• • If a buffer configured in the C2H direction generates a pulse trigger, the DMA device can automatically write the next data to process in the HSP BUFFx data register x (HSP_BUFFxDR) . The SPE is informed that a new sample is available on one of the Rx buffers.
• • If a buffer configured in the H2C direction generates a pulse trigger, the DMA device can automatically read the corresponding Tx buffer through the HSP BUFFx data register x (HSP_BUFFxDR) . The SPE is informed that a Tx buffer is available and a new sample can be written in the corresponding Tx buffer.

19.4.16 Time-stamp capture (TSC)

To ease the processing tuning and the debug, the HSP offers the possibility to capture a time-stamp, the task number, the processing function number, and other helpful information, using three different capture modes:

• • Task capture mode: a capture is done every time the activated task number changes.
• • Processing function capture mode: a capture is done every time the processing function number changes.
• • Break capture mode: a capture is done every time the SPE breaks.

Figure 99. TSC block diagram

The TSC mainly contains a trace controller, a data capture function, and a free-running counter.

The data capture function consists of storing information concerning SPE activity in the HSP_CAPDR register.

The data capture function can be controlled with CAPMOD[1:0]:

• • When CAPMOD[1:0] = 0, the capture function is disabled. The capture events are ignored. The complete capture function is no longer clocked.
• • When CAPMOD[1:0] = 1, a capture is performed every time the SPE breaks ( bkitf_spefz ).
• • When CAPMOD[1:0] = 2, a capture is performed every time the processing list number changes ( tsk_active[5:0] ).
• • When CAPMOD[1:0] = 3, a capture is performed every time the processing function number changes ( tsc_pfctnb[5:0] ).

The SPE provides several signals to ease the debugging:

• • spe_pfct_pulse signal generates a pulse when the SPE starts the execution of a processing function.
• • spe_if_pulse signal generates a pulse when a conditional function is executed.
• • spe_iftrue_pulse signal generates a pulse if the conditional function result is true.
• • spe_wfe signal indicates if the SPE is in WFE.

All these signals are visible through the SNOOP block (see Section 19.4.18: Snoop function (SNOOP) ).

The TSC trace controller reconditions the signals received from the SPE, TCU, and EVTC and provides the following services:

• • Counting the processing function inside a processing list ( tsc_pfctnb[5:0] ). This counter is reset every time the SPE goes back to WFE. When this counter reaches 63, on the next processing function it wraps around to 0 and continues counting.
• • Generating a signal indicating when the execution of a new processing function starts. This signal ( tsc_pfcttd ) can be used to freeze the SPE every time the execution of a new processing function starts.

It can also be used to generate a capture event and thus monitor the execution of processing functions.

In addition, it is possible to generate the tsc_pfcttd signal only during the execution of a specific task number. This can be done by using the output of TSKCMP0 ( tsk_comp[0] ) as the filter signal. This filtering function can be controlled through the TSKFLT bit.

• • Counting the number of conditional functions the SPE has performed since the previous execution of a processing function ( IFCNT[3:0] ). This counter is reset when a new processing function is executed, or when the SPE goes to WFE.
• • Providing a comparison history of conditional functions since the previous execution of a processing function ( IFHIST[14:0] ). For example, if three conditional functions have been executed since the previous execution of a processing function.
  • – IFHIST[0] contains 1 if the comparison of the first conditional function was true.
  • – IFHIST[1] contains the comparison result of the second conditional function.
  • – IFHIST[2] contains the comparison result of the third conditional function.

IFHIST and IFCNT are stored in the capture register only when the next processing function is executed and if CAPMOD[1:0] = 3.

• • Reformat the spe_pfct_pulse, spe_if_pulse, and spe_iftrue_pulse signals for the SNOOP block. Each signal is stretched to a minimum pulse width of five hsp_hclk_core_ck periods.

The figure below shows a simplified block diagram of the trace controller.

Figure 100. Trace controller block diagram

The TSC also provides a clock prescaler (PRESC[4:0]) cascaded with a 14-bit free-running counter (FRCNTR). The prescaler uses the HSP core clock as its timebase (hsp_hclk_core_ck). The PRESC[4:0] offers a 15-bit dynamic range, allowing the application to adjust the time granularity according to the desired trace.

The free-running counter and prescaler are enabled with the FRCNTEN bit.

When FRCNTEN is cleared, PRESC[4:0] and FRCNTR are reset, and no longer clocked. To change the prescaler value safely (PRESC[4:0]), the application must first clear FRCNTEN.

When a capture event occurs, the TSC stores the value of various signals in the HSP_CAPDR register:

• • Timestamp (TSTAMP[13:0])
• • Processing list number (TSKNB[5:0])
• • Processing function number (PFCTNB[5:0])
• • Number of conditional functions executed since the previous processing function (IFCNF[3:0])
• • Comparison of the status history for each conditional function (IFHIST[14:0])

The TSC offers two data capture formats for more flexibility. This format is selected through the FRCNTEN bit.

• • When FRCNTEN is cleared, the time-stamp function is disabled, and HSP_CAPDR contains:
  • – The processing list number (TSKNB[5:0])
  • – The processing function number (PFCTNB[5:0])
  • – The conditional function counter (IFCNT[3:0])
  • – The conditional function comparison status history (IFHIST[14:0])
• • When FRCNTEN is set, the timestamp function is enabled, and HSP_CAPDR contains:
  • – The timestamp (TSTAMP[13:0])
  • – The processing list number (TSKNB[5:0])
  • – The conditional function counter (IFCNT[3:0])
  • – A reduced set of the conditional functions comparison status history (IFHIST[7:0])

Note: Having 15 bits for IFHIST allows keeping the history of up to 15 consecutive conditional functions. Having 8 bits for IFHIST keeps the history of up to 8 consecutive conditional functions.

When a capture occurs, the HSP performs the following actions:

• • The parameters listed above are stored into the capture register (HSP_CAPDR).
• • The flag CAPRDYF is activated (with the tsc_cap_rdy signal) to inform the CPU that the capture register has been updated.
• • A capture event signal is sent to the TRGO to generate a trigger pulse (see Section 19.4.15: Trigger outputs (TRGO) ).

PRESC[4:0], FRCNTEN, TSKFLT, and CAPMOD[1:0] are located in the HSP capture control register (HSP_CAPCR) .

Note: PFCTNB[5:0] (tsc_pfctnb[5:0]) represents the number of processing functions since the start of the current task. This value is incremented every time a processing function is executed. When the capture event is due to a change of TSKNB[5:0] (task_active[5:0]), PFCTNB is equal to 0.

The tsc_pfctnb[5:0] is also available on I/Os with the SNOOP function.

Figure 101 shows how the TSC works, and which kinds of information can be captured.

Initially, the free-running counter is enabled and CAPMOD is cleared, indicating that the capture is disabled. Then the application clears and sets FRCNTEN to restart the free-running counter.

When CAPMOD is set to 2, the TSC stores all transitions of the task number in HSP_CAPCR. The CAPRDYF flag is set every time data are ready in HSP_CAPCR, and cleared when the application reads data. In this mode, IFCNT and IFHIST are not meaningful. When CAPMOD = 2, PFCTNB is cleared.

Later, CAPMOD is cleared and the free-running counter is still working, but the capture interface is disabled.

Next, CAPMOD is set to 3, with FRCNTEN = 1, allowing the TSC to store all processing function transitions with an associated timestamp in HSP_CAPCR. In this case, the amount of captured data may be important. In some cases, an overrun may occur. In this mode, IFCNT and IFHIST are updated according to the content of the processing list.

Finally, if FRCNTEN is cleared, the HSP_CAPDR format is changed and the timestamp is no longer present, but the depth of IFHIST is increased and PFCTNB is added.

Figure 101. TSC capture example 1

Note: IF CAPMOD is set to 2 before the boot of the SPE (BOOTEN = 1), the TSC captures an event, even when the SPE goes to WFE for the first time.

When TSKNB[5:0] = 0x3F and PFCTNB[5:0] = 0, it means that the SPE is in WFE.

When two processing lists are spaced by only one cycle in WFE, the WFE state (event indicating the end of the processing list) is not recorded in HSP_CAPDR, avoiding the generation of a probable overrun situation.

Figure 102 details the case where CAPMOD is set to 3, with a processing list containing conditional functions.

The left side of Figure 102 shows the (simplified) processing list to be traced, with the red line indicating what has been executed. Processing functions in lines 2, 9, 12, and 13 are not executed.

The first record in HSP_CAPDR shows that one conditional function has been executed before this record. Using the processing list code, the application can deduce that the IFEQ comparison result is false (IFHIST[1] = 0). The ELSE part is then executed, and this first record corresponds to SCA_ABS.

The second record in HSP_CAPDR, at t2, shows that two conditional functions have been executed since t1. Using the processing list code, the application can deduce that after executing SCA_ABS, the IFGT comparison result was true (IFHIST[0] = 1). The ELSE part has not been executed. This is also confirmed by the true IFLT comparison result (IFHIST[1] = 1). The record at t2 corresponds to SCA_ADD, and so on.

Figure 102. TSC capture example 2

1  IFEQ()
2  SCA_MUL()
3  ELSE
4  SCA_ABS()
5  IFGT()
6  IFLT()
7  SCA_ADD()
8  ELSE
9  SCA_SUB()
10 ENDIF
11 ELSE
12 SCA_SIN()
13 SCA_ATAN()
14 ENDIF
15 ENDIF
16 IFNEQ()
17 SCA_SQRT()
18 ENDIF
19 IFGTE()
20 SAT()
21 ENDIF
    

If the capture register needs to be written with a new record while the application did not yet read the previous value:

• • The TSC activates the overrun flag (CAPOVRF).
• • The TSC does not overwrite the capture register. The previous unread value is not corrupted.
• • The TSC does not generate a capture event for the TRGO.

The TSC also provides CAPRDYF, asserted when a data is available in the HSP_CAPDR register. This flag is automatically cleared when the CPU reads HSP_CAPDR.

If CAPRDYIE is set in the HSP events interrupt enable register (HSP_EVT_IER) , an interrupt can be generated to the CPU.

Note: A TRGO signal can be generated as well. Depending on the product, it allows using the device DMA to read HSP_CAPDR (see Section 19.4.15: Trigger outputs (TRGO)).

Application example: catching the SPE state in case of SPE break

The application must follow this programming sequence:

1. 1. Clear FRCNTEN.
2. 2. Clear CAPMOD[1:0].
3. 3. In the BKITF, enable all sources that are able to freeze the SPE.
4. 4. Set CAPMOD[1:0].

This configuration can be helpful if the application wants to log field issues and identify what the SPE was doing when a break event occurred. The timestamp is not enabled in this example.

Application example: capturing processing function timestamps

The application must follow the programming sequence below:

• • If the application intends to generate capture events only for processing functions located in a specific task:
  1. a) In the TCU, write the task number where the trace must be done in TSKCMP0[5:0] in the HSP task comparator unit register (HSP_TCUCFGR) .
  2. b) Enable the task comparator 0 by setting TC0EN in HSP_TCUCFGR.
  3. c) In BKITF, set TSKFLT.
• • If the application intends to generate capture events every time a new processing function is executed, clear TSKFLT in the BKITF block. It is not necessary to program the TCU block.
• • Prevent the processing function transition detector to break the SPE by setting SSSEN = 0.
• • In the TSC:
  • – Clear FRCNTEN.
  • – Clear CAPMOD[1:0].
  • – Set the PRESC[4:0] to the desired value.
  • – Set FRCNTEN.
  • – Select the processing functions capture mode (CAPMOD[1:0] = 0b11).

The application can read the captured values in several ways:

• • In polling mode, by waiting for CAPRDYF = 1, then reading HSP_CAPDR. This method is simple but not flexible and requests CPU load.
• • In interrupt mode, by setting CAPRDYIE to allow the HSP to generate an interrupt every time new data are available. This is a simple and flexible method, but requests CPU load.
• • Program the HSP to generate an event on one of the hsp_trgo[x] signals. This can be done by setting TRGO0SRC[1:0] to 3, for example, to use the hsp_trgo_out[3] signal. Depending on the product capabilities, the hsp_trgo[x] signals are connected to the trigger inputs of the device DMA, allowing it to read HSP_CAPDR every time a new timestamp is available. This method is the most efficient for the CPU loading but also for real time.

Note: Performing captures of processing function transitions may cause real-time issues, depending on the traced processing function. The execution time of some processing functions can be down to 10 hsp_hclk_core_ck cycles, causing potential overrun if HSP_CAPDR is not read on time.

Warning: When CAPMOD[1:0] must be modified, it is recommended to clear it before setting it to the desired value.

19.4.17 BRAM conflict counter

The BRAM can be accessed by the following masters:

• • SPE
• • SoC master devices via HSP slave port SP1

The priority is given to the SPE, but the application may want to check if access requests to the BRAM-A, BRAM-B, or BRAM-AB suffer from contentions, reducing the overall performance. For this purpose, the HSP offers a 32-bit conflict counter incremented every time the MMC detects a contention on BRAM access.

This feature can be enabled or disabled through CCNTREN in the HSP capture control register (HSP_CAPCR) . The conflict counter is reset when CCNTREN is disabled.

The conflict counter value can be read at any moment through the HSP conflict counter register (HSP_CCNTR) .

19.4.18 Snoop function (SNOOP)

The HSP offers the possibility to observe key signals to ease application tuning. The application can select which set of signals can be observed on the HSP_SNP[5:0] pads through SNPSELB[2:0] and SNPSEL A[2:0] in the HSP SNOOP register (HSP_SNPR) .

Figure 103. SNOOP function

The table below shows the signal that can be observed through pads.

Table 158. Snoop signal selection

19.4.19 Break interface (BKITF)

The HSP offers a break output interface, providing up to four break output signals ( hsp_brk_out[3:0] ). These signals can be used by the application to stop sensitive peripherals when a critical issue is detected in the HSP.

The HSP also offers a break input interface allowing the application to freeze the SPE in case of internal errors or errors reported by an external block through hsp_break_in . When the SPE breaks, it is possible to store in a capture register which processing list the HSP was executing, as well as a timestamp.

In addition, the BKITF allows the step-by-step processing list execution with the processing function granularity for debugging purposes.

Figure 104. Break interface

1. 1. CTI is not present in all products (see Section 19.3: HSP implementation ).
2. 2. hsp_break_in is not always connected; refer to Table 149: HSP break connections for more details.

HSP break output interface

For each break output signal, it is possible to select one or several flags as the source. The table below lists the possible sources for the break output interface. The control bits listed in the table must be set to allow the corresponding flag to generate a break signal.

Table 159. Flags and signal sources for break function

1. 1. These bits are in the HSP break output configuration register x (HSP_BKOxCFGGR) .

Note: These flags are asserted by the HSP or firmware code, and cleared by the application (see Table 156: HSP interrupt requests ).

The hsp_break_out[x] signal is set when at least one of the enabled sources is activated, and goes back to 0 when all enabled sources are inactive.

HSP break input interface

The break input interface can be used to:

• • Freeze the SPE
• • Generate capture events to the TSC

The freeze of the SPE can be activated by various sources:

• • Several error status flags
• • A break input signal
• • A start of the end of execution of processing functions
• • A request from the DBGMCU
• • A request from CTI (if available in the product)

Table 160 lists the possible sources for the break input interface. The control bits must be set to allow the corresponding flag to generate a break signal. These control bits are in the HSP break input configuration register (HSP_BKICFGR) .

Note: The BKINF flag is not asserted by all available break sources.

Table 160. Flags and signal sources for break input and debug functions

1. 1. These bits are located in the HSP break input configuration register (HSP_BKICFGR) , except for DBGMCU and CTI sources.

1. 2. DBGMCU has a bit to control this function (see the DEBUG section of the reference manual).

The SPE freeze is controlled by the bkitf_spfz signal. When bkitf_spfz is asserted, the SPE immediately stops fetching code and remains frozen. The HSP_CTRL is still

accessible, allowing the application to access all HSP registers and memories (conditioned by the REGLCK bit).

The SPE can resume the execution if all enabled break sources are inactive and the corresponding flags are cleared.

In addition, the moment the SPE is frozen, a capture event is sent to the TSC to store the time-stamp, the task number, and the processing function number.

If the break is generated by BRK_FUNC, the BKINF is asserted as well. As shown in Figure 105 , when the application resets the BKINF flag, if the break condition is still present at the input, the BKINF flag is not reset (#1 in the figure). If the break condition is no longer present, the CPU can clear the BKINF flag, and the SPE can resume the execution (#2 in the figure).

When the SPE is in break, the application can decide on one of the following actions:

• • Resume the SPE execution: the application clears all enabled break sources and clears the BKINF (by setting BKINC).
• • Restart the complete application: the application maintains the SPE frozen by not resetting the BKINF and performs an HSP reset through the RCC control bits.

The break input function is configured through the HSP break input configuration register (HSP_BKICFGR) .

Figure 105. Break input timing example

19.5 Debug

The HSP offers the following debug options:

• • Freeze the SPE according to some error status flags.
  This can be helpful to find the processing function that is causing the error (see Application example: SPE freeze on specific error conditions ).
• • Freeze the SPE every time the SPE starts the execution of a new processing function (see Application example: SPE step-by-step debug ).
• • Capture a timestamp every time a new processing function is executed (see Application example: capturing processing function timestamps ).
• • Freeze the SPE when the CPU is halted by using a control bit located in the DBGMCU block.

Application example: SPE freeze on specific error conditions

This feature can be used in applications requesting the SPE to stop immediately in case of errors inside or outside the HSP. It can also be used for debugging purposes, to find the processing function generating an unexpected error, for example.

To use this function, the HSP must be programmed as follows:

• • Define which flags or signals generate an SPE break (see Table 160: Flags and signal sources for break input and debug functions ).
• • If CAPMOD[1:0] of the TSC block is set to 0b01, when the SPE breaks, the application finds the timestamp, the last task, and the processing function number in the HSP_CAPDR register.

When the SPE breaks due to error detection, the application can decide:

• • To resume the SPE execution.
• • To restart the complete application.

Application example: SPE step-by-step debug

This feature can be helpful for debugging purposes to analyze data buffers after the execution of each processing function. It is possible to perform this step-by-step debugging only for processing functions located in a specific task, or for any processing function.

To use this feature, the HSP must be programmed as follows:

• • If the application intends to break the SPE only when a specific task is executed:
  • – In the TCU, write the task number where the step-by-step feature must be activated in TSKCMP0[5:0] of the HSP task comparator unit register (HSP_TCUCFGR) and enable the task comparator by setting TC0EN in HSP_TCUCFGR.
  • – Set the TSKFLT bit of the HSP_CAPCR register.
• • If the application intends to break the SPE every time a new processing function is executed, clear TSKFLT. No need to program the TCU block.
• • Allows the step-by-step feature to break the SPE by setting SSEN = 1.
• • If the capture mode of the TSC is configured to perform a capture every time the SPE is frozen (CAPMOD[1:0] = 0b01), when the SPE breaks, the application finds the task under execution, the processing function number, and a timestamp in HSP_CAPDR.

When the SPE is in break, the application can check buffer contents and resume the SPE execution. To resume the SPE execution, the application must clear the BKINF flag by setting BKINC in the HSP error interrupt clear register (HSP_ERR_ICR) . If additional flags or signals are able to generate a break, all enabled sources must be cleared to resume the SPE.

The CPU can be broken when the SPE breaks (see Section 19.5.1: Register protection ).

In the figure below, TSKCMP0[5:0] is set to 5. The SPE runs normally until it starts the execution of task number 5. At the start of the execution of task number 5, the SPE breaks, allowing the application to dump the data before execution of processing function number 1. Then the application clears the BKINF flag, and the SPE executes processing function number 1 and breaks again at the start of processing function number 2, allowing the application to dump data, and so on.

Figure 106. Step-by-step timing example

19.5.1 Register protection

The HSP embeds some hardware protection to prevent unexpected changes to register contents when the HSP is activated. Table 161 shows the list of write-protected and unprotected fields. The register protection is mainly handled by the REGLCK bit.

Note: When the application sets the REGLCK bit, it is no longer possible to clear it by writing this bit to 0. The HSP must be reset.

Table 161. List of locked fields

Table 161. List of locked fields (continued)

19.6 HSP firmware description

The HSP is built around a dedicated high-performance signal processor engine (SPE) running the firmware embedded in the CROM and the CRAM. The CROM mainly contains a set of optimized signal processing functions (libraries), and the CRAM contains the scheduler part of the HSP.

These signal processing functions are called “processing functions”, and the application can record several lists of processing functions to be executed upon activation of specific events. These lists of processing functions are called “processing lists”.

Events generated by peripherals trigger tasks, and each task can contain a single processing list.

This section gives an overview of the way that the application can perform the various operations supported by the HSP, such as running a direct command or recording a processing list.

This document does not provide details on processing functions; refer to the user manual HSP processing functions on STM32 MCUs (UM3360) .

19.6.1 Processing list mapping

Table 162 shows the processing list mapping. Processing lists 0 to 36 are dedicated to recording application processing lists.

Processing lists 37, 38, and 39 are built-in processing lists, not available to the application.

• • The processing list number 37, named PLSUP, is responsible for several control tasks, such as recording processing lists.
• • The processing list number 38, named PLDCMD, is used to run direct commands when the application wants to use the HSP in accelerator mode.
• • The processing list number 39, named PLFAIL, is triggered every time the application tries to execute a processing list with a number higher than 38 or when the application wants to execute a nonexisting processing list.

The built-in processing lists cannot be modified by the application.

After an HSP reset, processing lists 0 to 36 are routed to PLFAIL, to handle the activation of nonexisting processing lists. Every time the application records a new processing list, the link to PLFAIL is replaced by the link to the new processing list.

Several blocks can trigger a processing list: TRGIN, STREAM, CSEG, HSEG, CDEG, HDEG, DCMD.

Table 162 shows that:

• • Processing list number 0 can only be triggered by HDEG.
• • Processing lists numbers 1 to 22 can be triggered by TRGIN, STREAM, CSEG, HSEG, CDEG, and HDEG.
• • Processing lists numbers 23 to 36 can be triggered by CDEG and HDEG
• • Processing list number 37 can be triggered by CDEG.
• • Processing list number 38 can be triggered by DCMD.

CDEG always has the priority 27 (lowest); HDEG always has the priority 0 (highest); DCMD always has the priority 26.

TRGIN, STREAM, CSEG, and HSEG always have the priority of the processing number they are activating. For example, if STREAM is programmed to trigger processing list number 12, then its priority is 12.

Table 162. Processing list mapping

19.6.2 Sending commands to the HSP

The application must send commands to the HSP in the following cases:

• • To complete the HSP initialization phase by sending the FW_INIT command.
• • When a processing list must be programmed.
• • When a direct command must be executed.
• • When the application wants to erase all processing lists.

Sending the FW_INIT command

The firmware initialization command (FW_INIT) is sent only once during the initialization phase to give to the HSP firmware the base address of the BRAMAB, and to activate or not the performance monitor. This base address may differ from a product to another.

To send the FW_INIT command, the application must do the following:

1. 1. Wait until the HSP is ready to accept the FW_INIT command, signified by BSTAT[3:0] = 1.
2. 2. Send the FW_INIT command as follows:
   1. a) Check that MSGB is free (C2HSEM is cleared).
   2. b) Write the base address of BRAM-AB in HSP_PARAMR0. This address changes from one product to another, so the application needs to provide this information to the HSP.
   3. c) Clear HSP_PARAMR1 to disable the performance monitor, and set it to enable it.
   4. d) Write the command ID of the FW_INIT command in HSP_C2HMSGDR.
   5. e) Set C2HSEM.
3. 3. Check for the completion of the command execution (H2CSEM is set).
4. 4. Read the command status in HSP_H2CMSGDR. If the status differs from 0, the command has not been processed properly.
5. 5. Clear H2CSEM.

Sending commands to the supervisor

The PLSUP built-in processing list activates the supervisor function. The supervisor can be used to perform various tasks including the processing list recording. The supervisor can be activated at any moment by writing 37 in the HSP CPU dedicated event generation register (HSP_CDEGR) .

The supervisor event has the lowest priority. If it is activated while other active events are pending, it is served when all other events are served.

To send a command to the supervisor, the application must:

1. 1. Activate the supervisor.
2. 2. Use the MSGB and HSP_PARAMRx to send commands.

The recommended procedure to send a command to the supervisor is detailed below:

Sending a command to the supervisor

1. 1. If not yet enabled, set CDEGEN in the HSP_IFTENR register.
2. 2. Activate (if not done yet) the supervisor as follows:
   1. a) Check that CDEG is free (CDEGBSY is cleared).
   2. b) Write 37 in the HSP_CDEGR register.
3. 3. Check that MSGB is free (C2HSEM is cleared).
4. 4. Write the command parameters in the HSP_PARAMRx registers.
5. 5. Write the command ID in the HSP_C2HMSGDR register.
6. 6. Set C2HSEM in the HSP_C2HSEMR register.
7. 7. Wait for the completion of the command execution (H2CSEM is set).
8. 8. Read the HSP_H2CMSGDR register to get the command status.
9. 9. Clear H2CSEM.

As shown in the figure below, the supervisor can perform the following operations:

• • Erase all existing processing lists.
• • Program new processing lists.

Figure 107. PLSUP simplified algorithm

graph TD; PLSUP[PLSUP] -- "Activated by event 37" --> C2HSEM{C2HSEM == 1?}; C2HSEM -- No --> PLSUP; C2HSEM -- Yes --> HSP_RESET{HSP_C2HMSGDR == PL_RESET?}; HSP_RESET -- Yes --> Erase["Erase all the programmed processing lists<br>Write status into HSP_H2CMSGDR<br>Set C2HSEM to 0<br>Set H2CSEM to 1"]; HSP_RESET -- No --> HSP_START{HSP_C2HMSGDR == PROCFG_START?}; HSP_START -- Yes --> BSTAT3[Set BSTAT to 3]; BSTAT3 -- "Start programming of a new processing list<sup>1</sup>" --> Recording[Processing list recording]; Recording --> BSTAT2[Set BSTAT to 2]; HSP_START -- No --> Error["Set FWERRN[9:0] to CMDERR<br>Set FWERRF to 1"]; Error --> C2HSEM0[Set C2HSEM to 0]; Erase --> END[END]; BSTAT2 --> END; C2HSEM0 --> END;

1. Refer to Figure 108: Processing list programming algorithm .

19.6.3 Recording processing lists

At any time, the application can add a new processing list to the HSP by activating the supervisor:

1. 1. Send the PROCFG_START command as follows:
   1. a) Activate the supervisor by writing 37 in HSP_CDEGR (this action activates the supervisor, if not done yet).
   2. b) Check that C2HSEM is cleared.
   3. c) Write the processing list number in the HSP_PARAMR0 register.
   4. d) Write the PROCFG_START command ID in the HSP_C2HMSGDR register.
   5. e) Set C2HSEM in the HSP_C2HSEMR register.
   6. f) Wait for H2CSEM to be set, read the command status, and clear H2CSEM.
2. 2. Send the command to record the first processing function as follows:
   1. a) Check that C2HSEM is cleared.
   2. b) Write the processing function parameters in the HSP_PARAMRx registers.
   3. c) Write the processing function command ID in the HSP_C2HMSGDR register.
   4. d) Set C2HSEM in the HSP_C2HSEMR register.
   5. e) Wait for H2CSEM to be set, read the command status, and clear H2CSEM.
3. 3. Record the wanted sequence by sending commands as explained in step 2.
4. 4. Write the PROCFG_END command to exit the supervisor:
   1. a) Check that C2HSEM is cleared.
   2. b) Write the PROCFG_END command ID in the HSP_C2HMSGDR register.
   3. c) Set C2HSEM in the HSP_C2HSEMR register.
   4. d) Wait for H2CSEM to be set, read the command status, and clear H2CSEM.

The number and format of each processing function parameter are described in the user manual HSP processing functions on STM32 MCUs (UM3360).

For each command, the HSP firmware sends back a status with HSP_H2CMSGDR.

Figure 108 shows the processing list recording sequence:

1. 1. When the PROCFG_START command is recognized, the supervisor enters into this processing list programming sequencer.
2. 2. BSTAT[3:0] indicates when the supervisor is programming a processing list.
3. 3. When an error is detected, processing list programming is aborted. The processing list address is removed from TSKLUT. The command status reported by the command provides information about the error root cause.

As soon as a processing list is programmed, if its associated event is enabled, activated, and selected by the EVTC, the processing list is executed.

Figure 108. Processing list programming algorithm

graph TD
    Start[Processing list recording] --> ReadParam[Read parameter]
    ReadParam --> Invalid{Parameters invalid?}
    Invalid -- Yes --> CMD_ERR1[CMD_ERR]
    Invalid -- No --> StartList[Start creation of processing list:
TSKLUT updated
Write status into HSP_H2CMMSGDR
Set C2HSEM to 0
Set H2CSEM to 1]
    StartList --> Wait[Wait for new command]
    Wait --> C2HSEM{C2HSEM == 1?}
    C2HSEM -- No --> Wait
    C2HSEM -- Yes --> PROCFG_END{HSP_C2HMSGD = PROCFG_END?}
    PROCFG_END -- Yes --> WriteStatus1[Write status into HSP_H2CMMSGDR
Set H2CSEM to 1
Set C2HSEM to 0]
    WriteStatus1 --> END1[END]
    PROCFG_END -- No --> KnownFunc{HSP_C2HMSGD = known
processing function?}
    KnownFunc -- No --> CMD_ERR2[CMD_ERR]
    KnownFunc -- Yes --> ReadParams[Read parameters]
    ReadParams --> Valid{All parameters valid,
enough memory, etc.?}
    Valid -- No --> CMD_ERR2
    Valid -- Yes --> AddFunc[Add the processing function
to the processing list]
    AddFunc --> Translate[Translate command into efficient executable code into CRAM
Add the parameters into the DRAM
Write status into HSP_H2CMMSGDR
Set C2HSEM to 0
Set H2CSEM to 1]
    Translate --> END2[END]
    CMD_ERR3[CMD_ERR] --> RemoveList[Processing list removed from TSKLUT
Error status written into HSP_H2CMMSGDR
Set C2HSEM to 0
Set H2CSEM to 1]
    RemoveList --> END3[END]
    

MSV74881V2

19.6.4 Executing direct commands (accelerator mode)

At any time, the application can ask the HSP to execute a processing function as a direct command. If the HSP is executing processing lists, the execution of the direct command is delayed until the EVTTC grants the request.

The direct commands are mainly used to execute processing functions dedicated to vector operations. In addition, the processing functions executed in immediate mode can only work with data from BRAM.

The direct command execution is performed through the DCMD and HSP_PARAMRx registers.

The list below provides the recommended sequence to run a direct command. The number of arguments and pointers depend on the command executed (refer to the HSP firmware commands in the user manual HSP processing functions on STM32 MCUs (UM3360) ).

The DCMD block is enabled by default, but can be disabled:

1. 1. Write the command ID of the command to be executed in the HSP DCMD command ID register (HSP_DCMDIDR) .
2. 2. Write all parameters except the pointers in HSP_PARAMRx.

1. 3. Write the first pointer in HSP_DCMDPTR0.
2. 4. Write the second pointer in HSP_DCMDPTR1 (if needed).
3. 5. Write the third pointer in HSP_DCMDPTR2 (if needed).
4. 6. Write the fourth pointer as follows (if needed):
   1. a) Wait for PRTF0 = 0.
   2. b) Write the fourth pointer in HSP_DCMDPTR0.
5. 7. Write the fifth pointer as follows (if needed):
   • – Wait for PRTF1 = 0.
   • – Write the fifth pointer in HSP_DCMDPTR1.
6. 8. And so on
7. 9. Wait for command completion by checking that DCBSY = 0.

Figure 109 describes the PLDCMD built-in processing function. The SPE is expecting from the CPU to program the HSP as described above. To reduce overhead, the PLDCMD task does not perform a lot of checks. The application must properly program the direct command interface.

Note: ST provides a set of functions making the HSP interface transparent for the user.

Figure 109. Direct command processing list simplified algorithm

graph TD; PLDCMD[PLDCMD] --> Init["DCBSY = 1<br/>Compute NbPtr from HSP_DCMDIDR<br/>CntPtr = 0<br/>xx = 0"]; Init --> CntPtrCheck{CntPtr lower than NbPtr?}; CntPtrCheck -- No --> Execute[Execute command]; Execute --> ExecComp{Execution completed?}; ExecComp -- No --> Execute; ExecComp -- Yes --> SetDCBSY[Set DCBSY to 0]; SetDCBSY --> END[END]; CntPtrCheck -- Yes --> ReadPtr[Read HSP_DCMDPTR[xx]]; ReadPtr --> Translate["Perform address translation of read pointer<br/>Update HSP_SPE_PARAMR[y]"]; Translate --> Increment["xx ++<br/>CntPtr ++"]; Increment --> xxCheck{xx bigger than 2?}; xxCheck -- No --> ReadPtr; xxCheck -- Yes --> ResetXx[xx = 0]; ResetXx --> ReadPtr;

19.6.5 Data buffer handling

The HSP working buffers are located in the BRAM. Data exchanges between the HSP and the application can use the following interfaces:

• • BRAM-A, BRAM-B, or BRAM-AB
• • STREAM

Depending on the executed processing function, sharing data through the BRAM must be done using the BRAM-AB section or the BRAM-A and BRAM-B sections. Refer to Table 163: List of processing functions for more details.

Using the BRAM-AB section means that the content of BRAM-A must be the same as BRAM-B.

Figure 110. Data sharing models

19.6.6 Performance monitoring

In addition to the TSC block, the HSP also offers a performance monitoring tool, allowing the application to measure the execution time of a processing list.

This function is activated by setting the HSP_PARAM1R register (PERFEN) during the execution of the FW_INIT command.

When activated, a cycle counter value can be read in the last DRAM location after the completion of each processing list. The value is given in HSP core clock cycles ( hsp_hclk_core_ck ). Note that the application cannot read this cycle counter if CDRLCK[1:0] is set to 3.

The cycle counter is cleared every time the HSP starts the execution of a processing list.

Note: The PL_RESET command also allows the enabling or disabling of the performance monitor.

19.6.7 Processing functions summary

The table below gives a summary of all commands that the application can use to program processing functions into processing lists, or to execute them as direct commands. All the commands are described in detail in the user manual HSP processing functions on STM32 MCUs (UM3360) .

In the table below:

• • The column “Type” indicates if the function can be executed immediately in accelerator mode (ACC) or included in a processing list (SEQ).
• • The column “STREAM” indicates if input or output data can be taken from the STREAM interface: “Y” = yes, “y/n” = yes for sequencer and no for accelerator mode, “-” means no.
• • The column “BRAM” indicates which BRAM section must be used to exchange data: “DP” means that the BRAM-AB section must be used, “SP” means that the BRAM-A, and/or BRAM-B sections must be used.

Table 163. List of processing functions

Table 163. List of processing functions (continued)

Table 163. List of processing functions (continued)

Table 163. List of processing functions (continued)

Table 163. List of processing functions (continued)

19.7 HSP registers

All HSP registers can be read in 8, 16, or 32 bits. All write operations must be performed in 32 bits.

19.7.1 HSP control register (HSP_CR)

Address offset: 0x000

Reset value: 0x0000 0000

This register is used to control several HSP functions such as HSP boot, register access protection, and smart clock gating.

Bits 31:28 BSTAT[3:0] : Boot status

Set and cleared by the HSP. This bitfield shows the status of the boot sequence.

For possible values, refer to Table 151: BSTAT possible values .

Bits 27:26 Reserved, must be kept at reset value.

Bits 25:24 BARB[1:0] : BRAM arbitration

Set and cleared by the CPU.

00: Max arbitration latency is 16 cycles. This setting gives 96% of the BRAM bandwidth to the SPE, when the SPE requests 100% of the BRAM bandwidth. (default after reset).

01: Max arbitration latency is 8 cycles. This setting gives 89% of the BRAM bandwidth to the SPE, when the SPE requests 100% of the BRAM bandwidth.

10: Max arbitration latency is 4 cycles. This setting gives 80% of the BRAM bandwidth to the SPE, when the SPE request 100% of the BRAM bandwidth.

11: Reserved

Note: This bitfield is write-protected when REGLCK = 1.

Bits 23:18 Reserved, must be kept at reset value.

Bit 17 RSTOK : Reset request accepted

Set by the HSP, cleared by hardware when the HSP is reset. This bit indicates to the CPU that the HSP can be safely reset.

0: The HSP is not yet set into a state which ensures a safe reset. The application must wait until this bit is set (default after reset).

1: The HSP can be safely reset.

Bit 16 RSTREQ : Reset request

Set by the CPU, cleared by hardware when the HSP is reset. Writing this bit to 0 has no effect. Read operation returns the effective value.

0: No HSP reset requested (default after reset)

1: HSP reset requested

1. Bit 15 REGLCK : Register write lock access control
   Set by the CPU, cleared by hardware when the HSP is reset. Writing this bit to 0 has no effect. Read operation returns the effective value.
   0: Registers are accessible by the CPU through the slave AHB interface (default after reset).
   1: Selected registers are write-protected and the CPU cannot change the content.
2. Bits 14:13 CDRLCK[1:0] : CRAM and DRAM lock access control
   Set by the CPU, cleared by hardware when the HSP is reset. Writing this bit to 0 has no effect. Read operation returns the effective value.
   00: CRAM and DRAM are accessible for read and write operations (default after reset).
   01: CRAM and DRAM are write protected, but can be read.
   1x: CRAM and DRAM are read and write protected.
3. Bit 12 DCMDEVEN : Direct command event enable
   Set and cleared by CPU. This bit is used to enable the generation of an event on hsp_txeu signal every time the execution of a direct command is completed.
   0: Event generation disabled (default after reset)
   1: Event generation enabled
4. Bits 11:9 Reserved, must be kept at reset value.
5. Bit 8 Reserved, must be kept at reset value.
6. Bit 7 SPECGDIS : SPE clock gating disable
   Set and cleared by the CPU.
   0: SPE clock gating enabled: SPE clocks are locally gated (default after reset).
   1: SPE clock gating disabled: SPE clocks are not locally gated.
7. Bit 6 MMCCGDIS : MMC clock gating disable
   Set and cleared by the CPU.
   0: MMC clock gating enabled: MMC clocks are locally gated (default after reset).
   1: MMC clock gating disabled: MMC clocks are not locally gated.
8. Bit 5 Reserved, must be kept at reset value.
9. Bit 4 CTRLCGDIS : HSP_CTRL clock gating disable
   Set and cleared by the CPU.
   0: HSP_CTRL clock gating enabled: HSP_CTRL clocks are locally gated (default after reset).
   1: HSP_CTRL clock gating disabled: HSP_CTRL clocks are not locally gated.
10. Bits 3:1 Reserved, must be kept at reset value.
11. Bit 0 BOOTEN : Boot enable control
    Set by the CPU and cleared by an HSP reset.
    This bit allows the HSP to boot. Writing this bit to 0 has no effect. Read operation returns the effective value.
    0: The HSP is not allowed to boot (default after reset).
    1: The HSP is allowed to boot, and the SPE executes the code located in the CRAM.

19.7.2 HSP CPU-to-HSP semaphore register (HSP_C2HSEMR)

Address offset: 0x040

Reset value: 0x0000 0000

This register is used by the CPU to synchronize the messages. This register can also be accessed by the SPE processor. When the CPU sets a bit to 1, it sets the corresponding bit. Writing 0 has no effect. Reading returns the effective register value.

Bits 31:1 Reserved, must be kept at reset value.

Bit 0 C2HSEM : CPU to HSP semaphore

Set by the CPU and cleared by the HSP processor. When the CPU writes this bit to 1, it sets the bit. Writing this bit to 0 has no effect. Reading returns the effective bit value.

0: The CPU to HSP MSGB is ready to send a new message (default after reset).

1: The CPU to HSP MSGB contains a message for the HSP not yet read.

19.7.3 HSP CPU-to-HSP message data register (HSP_C2HMSGDR)

Address offset: 0x044

Reset value: 0x0000 0000

This register is used by the CPU to write a message data for the HSP. Writing this register automatically sets C2HSEM in HSP_C2HSEMR.

Bits 31:0 C2HDATA[31:0] : CPU message for the HSP

Set and reset by software.

19.7.4 HSP HSP-to-CPU semaphore register (HSP_H2CSEMR)

Address offset: 0x048

Reset value: 0x0000 0000

This register is used by the CPU to synchronize the messages. This register can also be accessed by the HSP processor. When the CPU writes a bit to 1, it clears the corresponding bit. Writing 0 has no effect. Reading returns the effective register value.

Bits 31:1 Reserved, must be kept at reset value.

Bit 0 H2CSEM : HSP to CPU semaphore

Set by the HSP processor, and cleared by the CPU. When the CPU writes this bit to 1, it clears the bit. Writing this bit to 0 has no effect. Reading returns the effective bit value.

0: The HSP to CPU MSGB does not contain a new message from the HSP (default after reset).

1: The HSP to CPU MSGB contains a new message from the HSP.

19.7.5 HSP HSP-to-CPU message data register (HSP_H2CMMSGDR)

Address offset: 0x04C

Reset value: 0x0000 0000

This register is used by the CPU to read a message data sent by the HSP.

Bits 31:0 H2CDATA[31:0] : HSP message for the CPU

Set and reset by software.

19.7.6 HSP DCMD command status register (HSP_DCMDSDR)

Address offset: 0x058

Reset value: 0x0000 0000

This register is used by the CPU to check if the current direct command execution is completed.

Bits 31:1 Reserved, must be kept at reset value.

Bit 0 DCBSY : Direct command busy flag

Set by hardware and reset by SPE. This flag indicates if the SPE is ready to accept a new MSGD.

0: The current direct command execution is completed. A new CMDID can be written in HSP_DCMDIDR (default after reset).

1: The current direct command execution is ongoing.

19.7.7 HSP DCMD pointer status register (HSP_DCMDPTSR)

Address offset: 0x05C

Reset value: 0x0000 0000

This register is used by the CPU to check if the HSP_DCMDPTRx pointer registers have been read by the SPE.

Bits 31:16 Reserved, must be kept at reset value.

Bit 15 RDOG : Read ongoing indicator

Set and cleared by hardware. This flag indicates if the SPE is currently reading one of the data pointer. The level of this flag can change very fast. It can be used during the debug phase. For example, when the execution of a direct command is abnormally long: if RDOG is stable at 1, it means that the SPE is blocked on the reading of a data pointer. Typically this issue appears when the application did not respect the expected data format for a direct command.

0: SPE does not read a pointer (default after reset).

1: SPE is reading a pointer. The SPE may be blocked if no pointer is provided by the CPU.

Bits 14:3 Reserved, must be kept at reset value.

Bit 2 PTRF2 : Address pointer 2 flag

Set and cleared by hardware. This flag indicates if the SPE read the last address pointer 2 written by the CPU in HSP_DCMDPTR2.

0: SPE read the address pointer 2. A new address pointer can be written in HSP_DCMDPTR2 (default after reset).

1: The current address pointer 2 has not been read by the SPE.

Bit 1 PTRF1 : Address pointer 1 flag

Set and cleared by hardware. This flag indicates if the SPE read the last address pointer 1 written by the CPU in HSP_DCMDPTR1.

0: SPE read the address pointer 1. A new address pointer can be written in HSP_DCMDPTR1 (default after reset).

1: The current address pointer 1 has not been read by the SPE.

Bit 0 PTRF0 : Address pointer 0 flag

Set and cleared by hardware. This flag indicates if the SPE read the last address pointer 0 written by the CPU in HSP_DCMDPTR0.

0: SPE read the address pointer 0. A new address pointer can be written in HSP_DCMDPTR0 (default after reset).

1: The current address pointer 0 has not been read by the SPE.

19.7.8 HSP DCMD command ID register (HSP_DCMDIDR)

Address offset: 0x060

Reset value: 0x0000 0000

This register is used by the CPU to provide the command ID to be executed to the direct command interface (DCMD).

Bits 31:16 Reserved, must be kept at reset value.

Bits 15:0 CMDID[15:0] : Command ID

Set and reset by software. This value represents the command ID of the command to be executed.

19.7.9 HSP DCMD address pointer register x (HSP_DCMDPTRx)

Address offset: 0x064 + 0x4 * x, (x = 0 to 2)

Reset value: 0x0000 0000

This register is used by the CPU to provide the address pointers to the DCMD.

Bits 31:0 PTCPU[31:0] : Address pointer value

Set and cleared by CPU. The CPU writes in this bitfield the pointer value requested by direct commands. This pointer value represents a peripheral or memory buffer address 'seen' by the CPU. This pointer value is automatically translated into a value directly usable by the SPE.

When the CPU writes this register, the corresponding PTRFx flag is set.

19.7.10 HSP event enable register (HSP_EVTENR)

Address offset: 0x080

Reset value: 0x0000 0000

This register is used to control the generation of events, which trigger a task. Write access operations in this register are not allowed when REGLCK is set.

Bits 31:23 Reserved, must be kept at reset value.

Bits 22:1 EVTEN[22:1] : Events enable

Set and reset by software. EVTEN[n] controls the enabling/disabling of the event number n.

0: Event generation disabled (default after reset)

1: Event generation enabled

Note: This bitfield is write-protected when REGLCK = 1.

Bit 0 Reserved, must be kept at reset value.

19.7.11 HSP event synchronization enable register (HSP_ESYNCENR)

Address offset: 0x084

Reset value: 0x0000 0000

This register is used to enable or disable the synchronization mechanism for the event generation. Write access operations to this register are not allowed when REGLCK is set.

Bits 31:27 Reserved, must be kept at reset value.

Bit 26 CDEGSYNCEN : CPU dedicated event synchronization enable

Set and cleared by software. This bit controls the enable/disable of the synchronization for the CPU dedicated event.

0: Synchronization disabled (default after reset)

1: Synchronization enabled.

Note: This bit is write-protected when REGLCK = 1.

Bits 25:23 Reserved, must be kept at reset value.

Bits 22:1 EVTSYNCEN[22:1] : Event synchronization enable

Set and cleared by software. EVTSYNCEN[n] controls the enable/disable of the synchronization for the event n.

0: Synchronization disabled (default after reset)

1: Synchronization enabled.

Note: This bitfield is write-protected when REGLCK = 1.

Bit 0 Reserved, must be kept at reset value.

19.7.12 HSP event synchronization source register 0 (HSP_ESYNC0SRCR)

Address offset: 0x088

Reset value: 0x0000 0000

This register is used to select the synchronization source for events 1 to 8. Write access operations to this register are not allowed when REGLCK is set, or when the corresponding EVTENx is set.

Bits 31:30 Reserved, must be kept at reset value.

Bits 29:28 EV8SSRC[1:0] : Event 8 synchronization source

Set and cleared by software.

00: tsk_cmp[0] selected as synchronization source

01: tsk_cmp[1] selected as synchronization source

10: tsk_cmp[2] selected as synchronization source

11: tsk_cmp[3] selected as synchronization source

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[8] = 1.

Bits 27:26 Reserved, must be kept at reset value.

Bits 25:24 EV7SSRC[1:0] : Event 7 synchronization source

Set and cleared by software.

00: tsk_cmp[0] selected as synchronization source

01: tsk_cmp[1] selected as synchronization source

10: tsk_cmp[2] selected as synchronization source

11: tsk_cmp[3] selected as synchronization source

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[7] = 1.

Bits 23:22 Reserved, must be kept at reset value.

Bits 21:20 EV6SSRC[1:0] : Event 6 synchronization source

Set and cleared by software.

00: tsk_cmp[0] selected as synchronization source

01: tsk_cmp[1] selected as synchronization source

10: tsk_cmp[2] selected as synchronization source

11: tsk_cmp[3] selected as synchronization source

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[6] = 1.

Bits 19:18 Reserved, must be kept at reset value.

Bits 17:16 EV5SSRC[1:0] : Event 5 synchronization source

Set and cleared by software.

00: tsk_cmp[0] selected as synchronization source

01: tsk_cmp[1] selected as synchronization source

10: tsk_cmp[2] selected as synchronization source

11: tsk_cmp[3] selected as synchronization source

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[5] = 1.

Bits 15:14 Reserved, must be kept at reset value.

Bits 13:12 EV4SSRC[1:0] : Event 4 synchronization source

Set and cleared by software.

00: tsk_cmp[0] selected as synchronization source

01: tsk_cmp[1] selected as synchronization source

10: tsk_cmp[2] selected as synchronization source

11: tsk_cmp[3] selected as synchronization source

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[4] = 1.

Bits 11:10 Reserved, must be kept at reset value.

Bits 9:8 EV3SSRC[1:0] : Event 3 synchronization source

Set and cleared by software.

00: tsk_cmp[0] selected as synchronization source

01: tsk_cmp[1] selected as synchronization source

10: tsk_cmp[2] selected as synchronization source

11: tsk_cmp[3] selected as synchronization source

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[8] = 1.

Bits 7:6 Reserved, must be kept at reset value.

Bits 5:4 EV2SSRC[1:0] : Event 2 synchronization source

Set and cleared by software.

00: tsk_cmp[0] selected as synchronization source

01: tsk_cmp[1] selected as synchronization source

10: tsk_cmp[2] selected as synchronization source

11: tsk_cmp[3] selected as synchronization source

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[2] = 1.

Bits 3:2 Reserved, must be kept at reset value.

Bits 1:0 EV1SSRC[1:0] : Event 1 synchronization source

Set and cleared by software.

00: tsk_cmp[0] selected as synchronization source

01: tsk_cmp[1] selected as synchronization source

10: tsk_cmp[2] selected as synchronization source

11: tsk_cmp[3] selected as synchronization source

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[1] = 1.

19.7.13 HSP event synchronization source register 1 (HSP_ESYNC1SRCR)

Address offset: 0x08C

Reset value: 0x0000 0000

This register is used to select the synchronization source for events 9 to 16. Write access operations to this register are not allowed when REGLCK is set, or when the corresponding EVTENx is set.

Bits 31:30 Reserved, must be kept at reset value.

Bits 29:28 EV16SSRC[1:0] : Event 16 synchronization source

Set and cleared by software.

00: tsk_cmp[0] selected as synchronization source

01: tsk_cmp[1] selected as synchronization source

10: tsk_cmp[2] selected as synchronization source

11: tsk_cmp[3] selected as synchronization source

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[16] = 1.

Bits 27:26 Reserved, must be kept at reset value.

Bits 25:24 EV15SSRC[1:0] : Event 15 synchronization source

Set and cleared by software.

00: tsk_cmp[0] selected as synchronization source

01: tsk_cmp[1] selected as synchronization source

10: tsk_cmp[2] selected as synchronization source

11: tsk_cmp[3] selected as synchronization source

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[15] = 1.

Bits 23:22 Reserved, must be kept at reset value.

Bits 21:20 EV14SSRC[1:0] : Event 14 synchronization source

Set and cleared by software.

00: tsk_cmp[0] selected as synchronization source

01: tsk_cmp[1] selected as synchronization source

10: tsk_cmp[2] selected as synchronization source

11: tsk_cmp[3] selected as synchronization source

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[14] = 1.

Bits 19:18 Reserved, must be kept at reset value.

Bits 17:16 EV13SSRC[1:0] : Event 13 synchronization source

Set and cleared by software.

00: tsk_cmp[0] selected as synchronization source

01: tsk_cmp[1] selected as synchronization source

10: tsk_cmp[2] selected as synchronization source

11: tsk_cmp[3] selected as synchronization source

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[13] = 1.

Bits 15:14 Reserved, must be kept at reset value.

Bits 13:12 EV12SSRC[1:0] : Event 12 synchronization source

Set and cleared by software.

00: tsk_cmp[0] selected as synchronization source

01: tsk_cmp[1] selected as synchronization source

10: tsk_cmp[2] selected as synchronization source

11: tsk_cmp[3] selected as synchronization source

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[12] = 1.

Bits 11:10 Reserved, must be kept at reset value.

Bits 9:8 EV11SSRC[1:0] : Event 11 synchronization source

Set and cleared by software.

00: tsk_cmp[0] selected as synchronization source

01: tsk_cmp[1] selected as synchronization source

10: tsk_cmp[2] selected as synchronization source

11: tsk_cmp[3] selected as synchronization source

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[11] = 1.

Bits 7:6 Reserved, must be kept at reset value.

Bits 5:4 EV10SSRC[1:0] : Event 10 synchronization source

Set and cleared by software.

00: tsk_cmp[0] selected as synchronization source

01: tsk_cmp[1] selected as synchronization source

10: tsk_cmp[2] selected as synchronization source

11: tsk_cmp[3] selected as synchronization source

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[10] = 1.

Bits 3:2 Reserved, must be kept at reset value.

Bits 1:0 EV9SSRC[1:0] : Event 9 synchronization source

Set and cleared by software.

00: tsk_cmp[0] selected as synchronization source

01: tsk_cmp[1] selected as synchronization source

10: tsk_cmp[2] selected as synchronization source

11: tsk_cmp[3] selected as synchronization source

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[9] = 1.

19.7.14 HSP event synchronization source register 2 (HSP_ESYNC2SRCR)

Address offset: 0x090

Reset value: 0x0000 0000

This register is used to select the synchronization source for events 17 to 22 and 27. Write access operations to this register are not allowed when REGLCK is set or when the corresponding EVTENx = 1.

Bits 31:30 CDEGSSRC[1:0] : CPU dedicated event synchronization source

Set and cleared by software.

00: tsk_cmp[0] selected as synchronization source

01: tsk_cmp[1] selected as synchronization source

10: tsk_cmp[2] selected as synchronization source

11: tsk_cmp[3] selected as synchronization source

Note: This bitfield is write-protected when REGLCK = 1 or when CDEGEN = 1.

Bits 29:22 Reserved, must be kept at reset value.

Bits 21:20 EV22SSRC[1:0] : Event 22 synchronization source

Set and cleared by software.

00: tsk_cmp[0] selected as synchronization source

01: tsk_cmp[1] selected as synchronization source

10: tsk_cmp[2] selected as synchronization source

11: tsk_cmp[3] selected as synchronization source

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[22] = 1.

Bits 19:18 Reserved, must be kept at reset value.

Bits 17:16 EV21SSRC[1:0] : Event 21 synchronization source

Set and cleared by software.

00: tsk_cmp[0] selected as synchronization source

01: tsk_cmp[1] selected as synchronization source

10: tsk_cmp[2] selected as synchronization source

11: tsk_cmp[3] selected as synchronization source

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[21] = 1.

Bits 15:14 Reserved, must be kept at reset value.

Bits 13:12 EV20SSRC[1:0] : Event 20 synchronization source

Set and cleared by software.

00: tsk_cmp[0] selected as synchronization source

01: tsk_cmp[1] selected as synchronization source

10: tsk_cmp[2] selected as synchronization source

11: tsk_cmp[3] selected as synchronization source

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[20] = 1.

Bits 11:10 Reserved, must be kept at reset value.

Bits 9:8 EV19SSRC[1:0] : Event 19 synchronization source

Set and cleared by software.

00: tsk_cmp[0] selected as synchronization source

01: tsk_cmp[1] selected as synchronization source

10: tsk_cmp[2] selected as synchronization source

11: tsk_cmp[3] selected as synchronization source

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[19] = 1.

Bits 7:6 Reserved, must be kept at reset value.

Bits 5:4 EV18SSRC[1:0] : Event 18 synchronization source

Set and cleared by software.

00: tsk_cmp[0] selected as synchronization source

01: tsk_cmp[1] selected as synchronization source

10: tsk_cmp[2] selected as synchronization source

11: tsk_cmp[3] selected as synchronization source

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[18] = 1.

Bits 3:2 Reserved, must be kept at reset value.

Bits 1:0 EV17SSRC[1:0] : Event 17 synchronization source

Set and cleared by software.

00: tsk_cmp[0] selected as synchronization source

01: tsk_cmp[1] selected as synchronization source

10: tsk_cmp[2] selected as synchronization source

11: tsk_cmp[3] selected as synchronization source

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[17] = 1.

19.7.15 HSP pending event level register (HSP_PEVTLR)

Address offset: 0x098

Reset value: 0x0000 0000

This register shows event states before the priority encoder. This register is mainly dedicated to debugging purposes.

Bits 31:28 Reserved, must be kept at reset value.

Bits 27:0 EVTL[27:0] : Event level

Set and cleared by hardware. This bitfield shows the current events level. Bit n correspond to event n.

0: Level low (inactive)

1: Level high (pending)

19.7.16 HSP interface enable register (HSP_ITFENR)

Address offset: 0x0A0

Reset value: 0x0000 0000

This register is used by the application to enable the STREAM and TRGITF peripheral interfaces. CPU write access operations to this register are not allowed when REGLCK is set. This register can also be modified by the SPE.

Bit 31 HDEGEN : HDEG interface enable bit

Set and cleared by software.

0: HDEG interface disabled, and maintained in reset

1: HDEG interface enabled

Bit 30 HSEGEN : HSEG interface enable bit

Set and cleared by software.

0: HSEG interface disabled, and maintained in reset

1: HSEG interface enabled

1. Bit 29 CDEGEN : CDEG interface enable bit
   Set and cleared by software.
   0: CDEG interface disabled, and maintained in reset
   1: CDEG interface enabled
   Note: This bit is write-protected when REGLCK = 1.
2. Bit 28 CSEGEN : CSEG interface enable bit
   Set and cleared by software.
   0: CSEG interface disabled, and maintained in reset
   1: CSEG interface is enabled
   Note: This bit is write-protected when REGLCK = 1.
3. Bit 27 DCMDDIS : Direct command interface disable bit
   Set and cleared by software. This bit can only be written once, after a HSP reset. By default the direct command interface is enabled. Reading returns the effective value.
   0: Writing this bit to 0 enables the DCMD interface, and prevents other applications to disable it (default after reset).
   1: Writing this bit to 1 disables the DCMD interface. Only an HSP reset can re enable it.
   Note: This bit is write-protected when REGLCK = 1.
4. Bit 26 Reserved, must be kept at reset value.
5. Bits 25:16 TRGINxEN : TRGINx enable bit (x = 9 to 0)
   Set and cleared by software.
   0: TRGINx disabled, all the TRGIN logic maintained in reset
   1: TRGINx enabled
   Note: This bit is write-protected when REGLCK = 1.
6. Bits 15:13 Reserved, must be kept at reset value.
7. Bit 12 TRGOEN : TRGO enable bit
   Set and cleared by software.
   0: TRGO function disabled. It is not possible to generate trigger pulses on hsp_trgo[3:0], nor to change the level of hsp_gpo[7:0].
   1: TRGO function enabled
   Note: This bit is write-protected when REGLCK = 1.
8. Bits 11:9 Reserved, must be kept at reset value.
9. Bit 8 STREAMEN : STREAM enable
   Set and cleared by software.
   0: STREAM disabled
   1: STREAM enabled
   Note: This bit is write-protected when REGLCK = 1.
10. Bits 7:0 Reserved, must be kept at reset value.

19.7.17 HSP event source register 0 (HSP_EVTSRC0R)

Address offset: 0x0B4

Reset value: 0x0000 0000

This register is used to select the event source for the priority encoder inputs 1 to 8. Write access operations to this register are not allowed when REGLCK is set, or when the corresponding EVTENx is set.

Bit 31 Reserved, must be kept at reset value.

Bits 30:28 EVT8SRC[2:0] : Event source selection for priority encoder input 8

Set and cleared by software.

000: Reserved, no event selected

001: Reserved, no event selected

010: Event provided by the BUFF3 is selected ( buff_evt[3] )

011: Event provided by the TRGIN0 is selected ( trgin_evt[0] )

100: Event provided by the TRGIN5 is selected ( trgin_evt[5] )

101: Event provided by the HSEG is selected ( hseg_evt[8] )

110: Event provided by the CSEG is selected ( cseg_evt[8] )

Other: same as position 101

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[8] = 1.

Bit 27 Reserved, must be kept at reset value.

Bits 26:24 EVT7SRC[2:0] : Event source selection for priority encoder input 7

Set and cleared by software.

000: Reserved, no event selected

001: Reserved, no event selected

010: Event provided by the BUFF2 is selected ( buff_evt[2] )

011: Event provided by the TRGIN4 is selected ( trgin_evt[4] )

100: Event provided by the TRGIN9 is selected ( trgin_evt[9] )

101: Event provided by the HSEG is selected ( hseg_evt[7] )

110: Event provided by the CSEG is selected ( cseg_evt[7] )

Other: same as position 101

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[7] = 1.

Bit 23 Reserved, must be kept at reset value.

Bits 22:20 EVT6SRC[2:0] : Event source selection for priority encoder input 6

Set and cleared by software.

000: Reserved, no event selected

001: Reserved, no event selected

010: Event provided by the BUFF1 is selected ( buff_evt[1] )

011: Event provided by the TRGIN3 is selected ( trgin_evt[3] )

100: Event provided by the TRGIN8 is selected ( trgin_evt[8] )

101: Event provided by the HSEG is selected ( hseg_evt[6] )

110: Event provided by the CSEG is selected ( cseg_evt[6] )

Other: same as position 101

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[6] = 1.

Bit 19 Reserved, must be kept at reset value.

Bits 18:16 EVT5SRC[2:0] : Event source selection for priority encoder input 5

Set and cleared by software.

000: Reserved, no event selected

001: Reserved, no event selected

010: Event provided by the BUFF0 is selected ( buff_evt[0] )

011: Event provided by the TRGIN2 is selected ( trgin_evt[2] )

100: Event provided by the TRGIN7 is selected ( trgin_evt[7] )

101: Event provided by the HSEG is selected ( hseg_evt[5] )

110: Event provided by the CSEG is selected ( cseg_evt[5] )

Other: same as position 101

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[5] = 1.

Bit 15 Reserved, must be kept at reset value.

Bits 14:12 EVT4SRC[2:0] : Event source selection for priority encoder input 4

Set and cleared by software.

000: Reserved, no event selected

001: Reserved, no event selected

010: Event provided by the BUFF3 is selected ( buff_evt[3] )

011: Event provided by the TRGIN1 is selected ( trgin_evt[1] )

100: Event provided by the TRGIN6 is selected ( trgin_evt[6] )

101: Event provided by the HSEG is selected ( hseg_evt[4] )

110: Event provided by the CSEG is selected ( cseg_evt[4] )

Other: same as position 101

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[4] = 1.

Bit 11 Reserved, must be kept at reset value.

Bits 10:8 EVT3SRC[2:0] : Event source selection for priority encoder input 3

Set and cleared by software.

000: Reserved, no event selected

001: Reserved, no event selected

010: Event provided by the BUFF2 is selected ( buff_evt[2] )

011: Event provided by the TRGIN0 is selected ( trgin_evt[0] )

100: Event provided by the TRGIN5 is selected ( trgin_evt[5] )

101: Event provided by the HSEG is selected ( hseg_evt[3] )

110: Event provided by the CSEG is selected ( cseg_evt[3] )

Other: same as position 101

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[3] = 1.

Bit 7 Reserved, must be kept at reset value.

Bits 6:4 EVT2SRC[2:0] : Event source selection for priority encoder input 2

Set and cleared by software.

000: Reserved, no event selected

001: Reserved, no event selected

010: Event provided by the BUFF1 is selected ( buff_evt[1] )

011: Event provided by the TRGIN4 is selected ( trgin_evt[4] )

100: Event provided by the TRGIN9 is selected ( trgin_evt[9] )

101: Event provided by the HSEG is selected ( hseg_evt[2] )

110: Event provided by the CSEG is selected ( cseg_evt[2] )

Other: same as position 101

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[2] = 1.

Bit 3 Reserved, must be kept at reset value.

Bits 2:0 EVT1SRC[2:0] : Event source selection for priority encoder input 1

Set and cleared by software.

000: Reserved, no event selected

001: Reserved, no event selected

010: Event provided by the BUFF0 is selected ( buff_evt[0] )

011: Event provided by the TRGIN3 is selected ( trgin_evt[3] )

100: Event provided by the TRGIN8 is selected ( trgin_evt[8] )

101: Event provided by the HSEG is selected ( hseg_evt[1] )

110: Event provided by the CSEG is selected ( cseg_evt[1] )

Other: same as position 101

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[1] = 1.

19.7.18 HSP event source register 1 (HSP_EVTSRC1R)

Address offset: 0x0B8

Reset value: 0x0000 0000

This register is used to select the event source for the priority encoder inputs 9 to 16. Write access operations to this register are not allowed when REGLCK is set or when the corresponding EVTENx is set.

Bit 31 Reserved, must be kept at reset value.

Bits 30:28 EVT16SRC[2:0] : Event source selection for priority encoder input 16

Set and cleared by software.

000: Reserved, no event selected

001: Reserved, no event selected

010: Event provided by the BUFF3 is selected ( buff_evt[3] )

011: Event provided by the TRGIN3 is selected ( trgin_evt[3] )

100: Event provided by the TRGIN8 is selected ( trgin_evt[8] )

101: Event provided by the HSEG is selected ( hseg_evt[16] )

110: Event provided by the CSEG is selected ( cseg_evt[16] )

Other: same as position 101

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[16] = 1.

Bit 27 Reserved, must be kept at reset value.

Bits 26:24 EVT15SRC[2:0] : Event source selection for priority encoder input 15

Set and cleared by software.

000: Reserved, no event selected

001: Reserved, no event selected

010: Event provided by the BUFF2 is selected ( buff_evt[2] )

011: Event provided by the TRGIN2 is selected ( trgin_evt[2] )

100: Event provided by the TRGIN7 is selected ( trgin_evt[7] )

101: Event provided by the HSEG is selected ( hseg_evt[15] )

110: Event provided by the CSEG is selected ( cseg_evt[15] )

Other: same as position 101

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[15] = 1.

Bit 23 Reserved, must be kept at reset value.

Bits 22:20 EVT14SRC[2:0] : Event source selection for priority encoder input 14

Set and cleared by software.

000: Reserved, no event selected

001: Reserved, no event selected

010: Event provided by the BUFF1 is selected ( buff_evt[1] )

011: Event provided by the TRGIN1 is selected ( trgin_evt[1] )

100: Event provided by the TRGIN7 is selected ( trgin_evt[6] )

101: Event provided by the HSEG is selected ( hseg_evt[14] )

110: Event provided by the CSEG is selected ( cseg_evt[14] )

Other: same as position 101

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[14] = 1.

Bit 19 Reserved, must be kept at reset value.

Bits 18:16 EVT13SRC[2:0] : Event source selection for priority encoder input 13

Set and cleared by software.

000: Reserved, no event selected

001: Reserved, no event selected

010: Event provided by the BUFF0 is selected ( buff_evt[0] )

011: Event provided by the TRGIN0 is selected ( trgin_evt[0] )

100: Event provided by the TRGIN5 is selected ( trgin_evt[5] )

101: Event provided by the HSEG is selected ( hseg_evt[13] )

110: Event provided by the CSEG is selected ( cseg_evt[13] )

Other: same as position 101

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[13] = 1.

Bit 15 Reserved, must be kept at reset value.

Bits 14:12 EVT12SRC[2:0] : Event source selection for priority encoder input 12

Set and cleared by software.

000: Reserved, no event selected

001: Reserved, no event selected

010: Event provided by the BUFF3 is selected ( buff_evt[3] )

011: Event provided by the TRGIN4 is selected ( trgin_evt[4] )

100: Event provided by the TRGIN9 is selected ( trgin_evt[9] )

101: Event provided by the HSEG is selected ( hseg_evt[12] )

110: Event provided by the CSEG is selected ( cseg_evt[12] )

Other: same as position 101

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[12] = 1.

Bit 11 Reserved, must be kept at reset value.

Bits 10:8 EVT11SRC[2:0] : Event source selection for priority encoder input 11

Set and cleared by software.

000: Reserved, no event selected

001: Reserved, no event selected

010: Event provided by the BUFF2 is selected ( buff_evt[2] )

011: Event provided by the TRGIN3 is selected ( trgin_evt[3] )

100: Event provided by the TRGIN8 is selected ( trgin_evt[8] )

101: Event provided by the HSEG is selected ( hseg_evt[11] )

110: Event provided by the CSEG is selected ( cseg_evt[11] )

Other: same as position 101

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[11] = 1.

Bit 7 Reserved, must be kept at reset value.

Bits 6:4 EVT10SRC[2:0] : Event source selection for priority encoder input 10

Set and cleared by software.

000: Reserved, no event selected

001: Reserved, no event selected

010: Event provided by the BUFF1 is selected ( buff_evt[1] )

011: Event provided by the TRGIN2 is selected ( trgin_evt[2] )

100: Event provided by the TRGIN7 is selected ( trgin_evt[7] )

101: Event provided by the HSEG is selected ( hseg_evt[10] )

110: Event provided by the CSEG is selected ( cseg_evt[10] )

Other: same as position 101

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[10] = 1.

Bit 3 Reserved, must be kept at reset value.

Bits 2:0 EVT9SRC[2:0] : Event source selection for priority encoder input 9

Set and cleared by software.

000: Reserved, no event selected

001: Reserved, no event selected

010: Event provided by the BUFF0 is selected ( buff_evt[0] )

011: Event provided by the TRGIN1 is selected ( trgin_evt[1] )

100: Event provided by the TRGIN6 is selected ( trgin_evt[6] )

101: Event provided by the HSEG is selected ( hseg_evt[9] )

110: Event provided by the CSEG is selected ( cseg_evt[9] )

Other: same as position 101

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[9] = 1.

19.7.19 HSP event source register 2 (HSP_EVT SRC2R)

Address offset: 0x0BC

Reset value: 0x0000 0000

This register is used to select the event source for the priority encoder inputs 17 to 22. Write access operations to this register are not allowed when REGLCK is set, or when the corresponding EVTENx is set.

Bits 31:23 Reserved, must be kept at reset value.

Bits 22:20 EVT22SRC[2:0] : Event source selection for priority encoder input 22

Set and cleared by software.

000: Reserved, no event selected

001: Reserved, no event selected

010: Event provided by the BUFF1 is selected ( buff_evt[1] )

011: Event provided by the TRGIN4 is selected ( trgin_evt[4] )

100: Event provided by the TRGIN9 is selected ( trgin_evt[9] )

101: Event provided by the HSEG is selected ( hseg_evt[22] )

110: Event provided by the CSEG is selected ( cseg_evt[22] )

Other: same as position 101

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[22] = 1.

Bit 19 Reserved, must be kept at reset value.

Bits 18:16 EVT21SRC[2:0] : Event source selection for priority encoder input 21

Set and cleared by software.

000: Reserved, no event selected

001: Reserved, no event selected

010: Event provided by the BUFF0 is selected ( buff_evt[0] )

011: Event provided by the TRGIN3 is selected ( trgin_evt[3] )

100: Event provided by the TRGIN8 is selected ( trgin_evt[8] )

101: Event provided by the HSEG is selected ( hseg_evt[21] )

110: Event provided by the CSEG is selected ( cseg_evt[21] )

Other: same as position 101

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[21] = 1.

Bit 15 Reserved, must be kept at reset value.

Bits 14:12 EVT20SRC[2:0] : Event source selection for priority encoder input 20

Set and cleared by software.

000: Reserved, no event selected

001: Reserved, no event selected

010: Event provided by the BUFF3 is selected ( buff_evt[3] )

011: Event provided by the TRGIN2 is selected ( trgin_evt[2] )

100: Event provided by the TRGIN7 is selected ( trgin_evt[7] )

101: Event provided by the HSEG is selected ( hseg_evt[20] )

110: Event provided by the CSEG is selected ( cseg_evt[20] )

Other: same as position 101

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[20] = 1.

Bit 11 Reserved, must be kept at reset value.

Bits 10:8 EVT19SRC[2:0] : Event source selection for priority encoder input 19

Set and cleared by software.

000: Reserved, no event selected

001: Reserved, no event selected

010: Event provided by the BUFF2 is selected ( buff_evt[2] )

011: Event provided by the TRGIN1 is selected ( trgin_evt[1] )

100: Event provided by the TRGIN6 is selected ( trgin_evt[6] )

101: Event provided by the HSEG is selected ( hseg_evt[19] )

110: Event provided by the CSEG is selected ( cseg_evt[19] )

Other: same as position 101

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[19] = 1.

Bit 7 Reserved, must be kept at reset value.

Bits 6:4 EVT18SRC[2:0] : Event source selection for priority encoder input 18

Set and cleared by software.

000: Reserved, no event selected

001: Reserved, no event selected

010: Event provided by the BUFF1 is selected ( buff_evt[1] )

011: Event provided by the TRGIN0 is selected ( trgin_evt[0] )

100: Event provided by the TRGIN5 is selected ( trgin_evt[5] )

101: Event provided by the HSEG is selected ( hseg_evt[18] )

110: Event provided by the CSEG is selected ( cseg_evt[18] )

Other: same as position 101

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[18] = 1.

Bit 3 Reserved, must be kept at reset value.

Bits 2:0 EVT17SRC[2:0] : Event source selection for priority encoder input 17

Set and cleared by software.

000: Reserved, no event selected

001: Reserved, no event selected

010: Event provided by the BUFF0 is selected ( buff_evt[0] )

011: Event provided by the TRGIN4 is selected ( trgin_evt[4] )

100: Event provided by the TRGIN9 is selected ( trgin_evt[9] )

101: Event provided by the HSEG is selected ( hseg_evt[17] )

110: Event provided by the CSEG is selected ( cseg_evt[17] )

Other: same as position 101

Note: This bitfield is write-protected when REGLCK = 1 or when EVTEN[17] = 1.

19.7.20 HSP BUFF configuration register (HSP_BUFFCFGR)

Address offset: 0x0F4

Reset value: 0x0000 0000

This register is used by the application to select the direction of each buffer (C2H or H2C), and to configure the buffer combiner. Write access operations to this register are not allowed when REGLCK is set or when BUFFEN is set.

Bits 31:19 Reserved, must be kept at reset value.

Bits 18:16 COMBx : BUF CMB control for buff_evt[x] (x = 2 to 0)

Set and cleared by software. This bit defines how buff_evt[x] is activated.

0: buff_evt[x] activated when buff_att[x] is activated

1: buff_evt[x] activated when buff_att[x] and buff_evt[x+1] are activated

Note: This bit is write-protected when REGLCK = 1 or when BUFFEN = 1.

Bits 15:9 Reserved, must be kept at reset value.

Bit 8 I2FEN : Integer to float32 conversion

Set and cleared by software. The integer to float only works for the RX buffers. The integer number must have one of the following format:

• - signed integers

• - unsigned 8-, 16-, or 24-bit integers

0: Integer to float32 conversion disabled

1: Integer to float32 conversion enabled

Note: This bit is write-protected when REGLCK = 1 or when BUFFEN = 1.

Bits 7:4 Reserved, must be kept at reset value.

Bits 3:0 BUFFxDIR : Direction selection of BUFFx (x = 3 to 0)

Set and cleared by software.

0: BUFFx direction is C2H (means written by the CPU and read by the HSP).

1: BUFFx direction is H2C (means read by the CPU and written by the HSP).

Note: This bit is write-protected when REGLCK = 1 or when BUFFEN = 1.

19.7.21 HSP BUFFx data register x (HSP_BUFFxDR)

Address offset: 0x0F8 + 0x4 * x, (x = 0 to 3)

Reset value: 0x0000 0000

This register is used to read or write data into a C2H or H2CBUFF.

Bits 31:0 BUFFDAT[31:0] : Data buffer

Set and cleared by software. The application can read H2CBUFFs, and write C2HBUFFs.

Writing into a H2CBUFF has no effect, reading a C2HBUFF returns an invalid data.

19.7.22 HSP TRGIN configuration register (HSP_TRGINCFGR)

Address offset: 0x120

Reset value: 0x0000 0000

This register is used to enable and select the polarity of each TRGIN input. Write access operations to this register are not allowed when REGLCK is set or when TRGINxEN is set.

Bits 31:10 Reserved, must be kept at reset value.

Bits 9:0 TRGxPOL : Polarity selection for TRGINx (x = 9 to 0)

Set and cleared by software.

0: TRGINx triggers on rising edge of the input signal.

1: TRGINx triggers on falling edge of the input signal.

Note: This bit is write-protected when REGLCK = 1 or when TRGIN[x]EN = 1.

19.7.23 HSP TRGO configuration register (HSP_TRGOCFGGR)

Address offset: 0x124

Reset value: 0x0000 0000

This register is used to enable and select the signal sources generating a trigger output. Write access operations to this register are not allowed when REGLCK is set or when TRGOEN is set.

Bits 31:8 Reserved, must be kept at reset value.

Bits 7:0 TRGOxSRC[1:0] : Trigger source selection for hsp_trgo[x] (x = 3 to 0)

Set and cleared by software.

00: hsp_trgo[x] disabled

01: buff_trgo[x] selected as trigger source

10: spe_trgo[x] selected as trigger source

11: tsc_trgo selected as trigger source

Note: This bitfield is write-protected when REGLCK = 1 or when TRGOEN = 1.

19.7.24 HSP TRGIN input selection register 0 (HSP_TRGINSEL0)

Address offset: 0x150

Reset value: 0x0000 0000

This register is used to select the input trigger signal for TRGIN0 to TRGIN3. Write access operations to this register are not allowed when REGLCK is set or when the corresponding TRGxEN is set.

Note: The number of valid positions depends on the number of trigger inputs implemented in the product (see Section 19.3: HSP implementation).

Bits 31:30 Reserved, must be kept at reset value.

Bits 29:24 TRG3SEL[5:0] : Input trigger selection for TRGIN3

Set and cleared by software.

0: hsp_trgi[0] input signal selected

1: hsp_trgi[1] input signal selected

x: hsp_trgi[x] input signal selected (x must be lower than 20)

Note: This bit is write-protected when REGLCK = 1 or when TRGI3EN= 1.

Bits 23:22 Reserved, must be kept at reset value.

Bits 21:16 TRG2SEL[5:0] : Input trigger selection for TRGIN2

Set and cleared by software.

0: hsp_trgi[0] input signal selected

1: hsp_trgi[1] input signal selected

x: hsp_trgi[x] input signal selected (x must be lower than 20)

Note: This bit is write-protected when REGLCK = 1 or when TRGI2EN= 1.

Bits 15:14 Reserved, must be kept at reset value.

Bits 13:8 TRG1SEL[5:0] : Input trigger selection for TRGIN1

Set and cleared by software.

0: hsp_trgi[0] input signal selected

1: hsp_trgi[1] input signal selected

x: hsp_trgi[x] input signal selected (x must be lower than 20)

Note: This bit is write-protected when REGLCK = 1 or when TRGI1EN= 1.

Bits 7:6 Reserved, must be kept at reset value.

Bits 5:0 TRG0SEL[5:0] : Input trigger selection for TRGIN0

Set and cleared by software.

0: hsp_trgi[0] input signal selected

1: hsp_trgi[1] input signal selected

x: hsp_trgi[x] input signal selected (x must be lower than 20)

Note: This bit is write-protected when REGLCK = 1 or when TRGI0EN= 1.

19.7.25 HSP TRGIN input selection register 1 (HSP_TRGINSEL1)

Address offset: 0x154

Reset value: 0x0000 0000

This register is used to select the input trigger signal for TRGIN4 to TRGIN7. Write access operations to this register are not allowed when REGLCK is set or when the corresponding TRGixEN is set.

Note: The number of valid positions depends on the number of trigger inputs implemented in the product (see Section 19.3: HSP implementation).

Bits 31:30 Reserved, must be kept at reset value.

Bits 29:24 TRG7SEL[5:0] : Input trigger selection for TRGIN7

Set and cleared by software.

0: hsp_trgi[0] input signal selected

1: hsp_trgi[1] input signal selected

x: hsp_trgi[x] input signal selected (x must be lower than 20)

Note: This bit is write-protected when REGLCK = 1 or when TRGI7EN= 1.

Bits 23:22 Reserved, must be kept at reset value.

Bits 21:16 TRG6SEL[5:0] : Input trigger selection for TRGIN6

Set and cleared by software.

0: hsp_trgi[0] input signal selected

1: hsp_trgi[1] input signal selected

x: hsp_trgi[x] input signal selected (x must be lower than 20)

Note: This bit is write-protected when REGLCK = 1 or when TRGI6EN= 1.

Bits 15:14 Reserved, must be kept at reset value.

Bits 13:8 TRG5SEL[5:0] : Input trigger selection for TRGIN5

Set and cleared by software.

0: hsp_trgi[0] input signal selected

1: hsp_trgi[1] input signal selected

x: hsp_trgi[x] input signal selected (x must be lower than 20)

Note: This bit is write-protected when REGLCK = 1 or when TRGI5EN= 1.

Bits 7:6 Reserved, must be kept at reset value.

Bits 5:0 TRG4SEL[5:0] : Input trigger selection for TRGIN4

Set and cleared by software.

0: hsp_trgi[0] input signal selected

1: hsp_trgi[1] input signal selected

x: hsp_trgi[x] input signal selected (x must be lower than 20)

Note: This bit is write-protected when REGLCK = 1 or when TRGI4EN= 1.

19.7.26 HSP TRGIN input selection register 2 (HSP_TRGINSEL2)

Address offset: 0x158

Reset value: 0x0000 0000