package ti.sysbios.family.arm.ducati

Contains specifications for the Ducati device-specific SYS/BIOS functions

The two M3 cores share a number of hardware and software resources. [ more ... ]
XDCspec declarations sourced in ti/sysbios/family/arm/ducati/package.xdc
 
package ti.sysbios.family.arm.ducati [2, 0, 0, 0] {
 
    module CTM;
    // Counter Timer Module Device Definitions
    module Core;
    // Core Identification Module
    module GateDualCore;
    // A Gate for use by the two Ducati M3 cores to manage shared resources
    module GateSmp;
    // Hwi, Swi & Task Gate
    module Timer;
    // Ducati Cortex M3 Timer Peripherals Manager
    module TimestampProvider;
    // Ducati Cortex M3 TimestampProvider delegate for use with xdc.runtime.Timestamp
    module Wugen;
    // Wugen Module
}
DETAILS
The two M3 cores share a number of hardware and software resources.
The system software must carefully manage these resources when the dynamic loading of applications is required.
Below is a list of the shared resources that SYS/BIOS modules utilize and manage.
Shared resources:
AMMU
  • Must be configured before unicache is enabled.
  • Must have a page descriptor for EVERY memory address accessed by either core before unicache is enabled.
  • AMMU is configured statically, no runtime APIs to modify the AMMU configuration are provided.
  • Initialization is controlled by the AMMU.configureAmmu flag.
  • By default, this flag is true.
Unicache
  • Must be configured and enabled.
  • Runtime APIs use GateDualCore[0] to arbitrate shared unicache register usage.
  • Initialization is controlled by the Cache.configureCache flag.
  • By default this flag is false.
CTM 2,3,4,5 used for timestamping
  • These counters are initialized by the TimestampProvider module, which is used by the xdc.runtime.Timestamp module to provide timestamp services.
  • Must be configured and started.
  • Configured and started by whichever core comes up first and detects (by testing register contents) that the CTM hasn't been configured and started.
Reset Exception vector table (vectors 0-14)
  • The address of the Reset Exception vector table is shared by both cores.
  • Vectors 0 and 1 at addresses 0x0 are fetched each time a core is reset. At that time they must contain the SP and address of c_int00 for the core being reset.
  • Exception vectors 2-14 are used by each core until it has successfully configured its NVIC's Vector Table Offset Register (VTOR) to point to the vector table that will be used afterwards.
  • The Reset Exception vectors are required to be valid and unique to the core being reset in case an exception occurs prior to the VTOR being configured.
  • The Reset Exception vector table placement is controlled by the Hwi.resetVectorAddress config parameter.
  • By default, both cores place their Reset Exception vector table at 0x00000000.
  • It is left to the system software design to guarantee that only one core is climbing up at a time.
Runtime Exception and Interrupt vector table (vectors 0-79)
  • The address of the Runtime Exception and Interrupt vector table should be unique to each core.
  • The Runtime Exception and Interrupt vector table placement is controlled by the Hwi.vectorTableAddress config parameter.
  • Default behavior is that core 0 places its runtime vector table at 0x400 and core 1 places its runtime vector table at 0x800.
GateDualCore[0] is used by the unicache module. GateDualCore[1-n] can be used by applications to manage shared hardware/software resources
  • Initialization is controlled by the GateDualCore.initGates flag.
  • By default, core 0 initializes the gate objects.
generated on Thu, 25 May 2017 22:09:59 GMT