38.6.1.5 DPRAM Management

Pipes and endpoints can only be allocated in ascending order, from pipe/endpoint 0 to the last pipe/endpoint to be allocated. The user should therefore configure them in the same order.

The allocation of a pipe/endpoint x starts when the Endpoint Memory Allocate bit in the Endpoint x Configuration register (USBHS_DEVEPTCFGx.ALLOC) is written to one. Then, the hardware allocates a memory area in the DPRAM and inserts it between the x - 1 and x+ 1 pipes/endpoints. The x+ 1 pipe/endpoint memory window slides up and its data is lost. Note that the following pipe/endpoint memory windows (from x+ 2) do not slide.

Disabling a pipe, by writing a zero to the Pipe x Enable bit in the Host Pipe register (USBHS_HSTPIP.PENx), or disabling an endpoint, by writing a zero to the Endpoint x Enable bit in the Device Endpoint register (USBHS_DEVEPT.EPENx), does not reset the USBHS_DEVEPTCFGx.ALLOC bit or the Pipe/Endpoint configuration:

  • Pipe Configuration
    • Pipe Banks (USBHS_HSTPIPCFGx.PBK)
    • Pipe Size (USBHS_HSTPIPCFGx.PSIZE)
    • Pipe Token (USBHS_HSTPIPCFGx.PTOKEN)
    • Pipe Type (USBHS_HSTPIPCFGx.PTYPE)
    • Pipe Endpoint Number (USBHS_HSTPIPCFGx.PEPNUM)
    • Pipe Interrupt Request Frequency (USBHS_HSTPIPCFGx.INTFRQ)
  • Endpoint Configuration
    • Endpoint Banks (USBHS_DEVEPTCFGx.EPBK)
    • Endpoint Size (USBHS_DEVEPTCFGx. EPSIZE)
    • Endpoint Direction (USBHS_DEVEPTCFGx.EPDIR)
    • Endpoint Type (USBHS_DEVEPTCFGx.EPTYPE)

To free endpoint memory, the user must write a zero to the USBHS_DEVEPTCFGx.ALLOC bit. The x+ 1 pipe/endpoint memory window then slides down and its data is lost. Note that the following pipe/endpoint memory windows (from x + 2) do not slide.

The following figure illustrates the allocation and reorganization of the DPRAM in a typical example.

Figure 38-4. Allocation and Reorganization of the DPRAM
  1. Pipes/endpoints 0 to 5 are enabled, configured and allocated in ascending order. Each pipe/endpoint then owns a memory area in the DPRAM.
  2. Pipe/endpoint 3 is disabled, but its memory is kept allocated by the controller.
  3. In order to free its memory, its USBHS_DEVEPTCFGx.ALLOC bit is written to zero. The pipe/endpoint 4 memory window slides down, but pipe/endpoint 5 does not move.
  4. If the user chooses to reconfigure pipe/endpoint 3 with a larger size, the controller allocates a memory area after the pipe/endpoint 2 memory area and automatically slides up the pipe/endpoint 4 memory window. Pipe/endpoint 5 does not move and a memory conflict appears as the memory windows of pipes/endpoints 4 and 5 overlap. The data of these pipes/endpoints is potentially lost.
    Note: 1. The data of pipe or endpoint 0 cannot be lost (except if it is de-allocated) as the memory allocation and de-allocation may affect only higher pipes/endpoints.
    Note: 2. Deactivating then reactivating the same pipe/endpoint with the same configuration only modifies temporarily the controller DPRAM pointer and size for this pipe/endpoint. Nothing changes in the DPRAM. Higher endpoints seem not to have been moved and their data is preserved as long as nothing has been written or received into them while changing the allocation state of the first pipe/endpoint.
    Note: 3. When the user writes a one to the USBHS_DEVEPTCFGx.ALLOC bit, the Configuration OK Status bit (USBHS_DEVEPTISRx.CFGOK) is set only if the configured size and number of banks are correct as compared to the endpoint maximum allowed values and to the maximum FIFO size (i.e., the DPRAM size). The USBHS_DEVEPTISRx.CFGOK value does not consider memory allocation conflicts.