The scheduling algorithm is the software routine that decides which ready state task to transition into the running state.

Round Robin: this scheduler will ensure tasks that share priority are selected to enter the running state in turn. The Round Robin scheduling algorithm in FreeRTOS does not guarantee time is shared equally between tasks of equal priority, only that ready state tasks of equal priority will enter the running state in turn.

Fixed priority: this scheduler does not change the priority assigned to the tasks being scheduled but also does not prevent the tasked from changing their own priority or that of other tasks.

Pre-emptive: this scheduler will immediately preempt the running state task if a task that has priority higher than the running state task enters the ready state. Being pre-empted means being involuntarily moved out of the running state and into the ready state to allow a different task to enter the running state.

Time slicing: this scheduler shares processing time between tasks of equal priority, even when the task does not explicitly yield or enter the blocked state. Scheduling algorithms described as using time slicing will select a new task to enter the running state at the end of each time slice if there are other ready state tasks that have the same priority as running task.

// FreeRTOSConfig.h

// Preemptive priority scheduler
// No automatic round-robin for equal priorities
// Deterministic execution until voluntary block/yield
#define configUSE_PREEMPTION                      1 
#define configUSE_TIME_SLICING                    0

// Priority-based preemptive scheduling
// Round-robin between equal priorities
#define configUSE_PREEMPTION                      1 
#define configUSE_TIME_SLICING                    1 

// FreeRTOSConfig.h

// Preemptive priority scheduler
// No automatic round-robin for equal priorities
// Deterministic execution until voluntary block/yield
#define configUSE_PREEMPTION                      1 
#define configUSE_TIME_SLICING                    0

// Priority-based preemptive scheduling
// Round-robin between equal priorities
#define configUSE_PREEMPTION                      1 
#define configUSE_TIME_SLICING                    1 

// FreeRTOSConfig.h

#define configENABLE_FPU                          1
#define configENABLE_MPU                          0
#define configSUPPORT_STATIC_ALLOCATION           1
#define configSUPPORT_DYNAMIC_ALLOCATION          1
#define configUSE_PREEMPTION                      1
#define configUSE_TIME_SLICING                    1
#define configUSE_IDLE_HOOK                       0
#define configUSE_TICK_HOOK                       0
#define configUSE_QUEUE_SETS                      1
#define configUSE_TRACE_FACILITY                  1
#define configUSE_16_BIT_TICKS                    0
#define configUSE_MUTEXES                         1
#define configUSE_TASK_NOTIFICATIONS              1
#define configUSE_RECURSIVE_MUTEXES               1
#define configUSE_COUNTING_SEMAPHORES             1
#define configUSE_PORT_OPTIMISED_TASK_SELECTION   0
#define configCPU_CLOCK_HZ                        ( SystemCoreClock ) // system_stm32f4xx.c
#define configTICK_RATE_HZ                        ((TickType_t)1000)
#define configMAX_PRIORITIES                      ( 56 )
#define configMINIMAL_STACK_SIZE                  ((uint16_t)128)
#define configTOTAL_HEAP_SIZE                     ((size_t)15360)
#define configMAX_TASK_NAME_LEN                   ( 16 )
#define configQUEUE_REGISTRY_SIZE                 8

// FreeRTOSConfig.h

#define configENABLE_FPU                          1
#define configENABLE_MPU                          0
#define configSUPPORT_STATIC_ALLOCATION           1
#define configSUPPORT_DYNAMIC_ALLOCATION          1
#define configUSE_PREEMPTION                      1
#define configUSE_TIME_SLICING                    1
#define configUSE_IDLE_HOOK                       0
#define configUSE_TICK_HOOK                       0
#define configUSE_QUEUE_SETS                      1
#define configUSE_TRACE_FACILITY                  1
#define configUSE_16_BIT_TICKS                    0
#define configUSE_MUTEXES                         1
#define configUSE_TASK_NOTIFICATIONS              1
#define configUSE_RECURSIVE_MUTEXES               1
#define configUSE_COUNTING_SEMAPHORES             1
#define configUSE_PORT_OPTIMISED_TASK_SELECTION   0
#define configCPU_CLOCK_HZ                        ( SystemCoreClock ) // system_stm32f4xx.c
#define configTICK_RATE_HZ                        ((TickType_t)1000)
#define configMAX_PRIORITIES                      ( 56 )
#define configMINIMAL_STACK_SIZE                  ((uint16_t)128)
#define configTOTAL_HEAP_SIZE                     ((size_t)15360)
#define configMAX_TASK_NAME_LEN                   ( 16 )
#define configQUEUE_REGISTRY_SIZE                 8

The F2837xD includes three buffered 12-bit DAC modules that can provide a programmable reference output voltage capable of driving an external load. Values written to the DAC can take effect immediately or be synchronized with ePWM events.

Buffered DAC Block Diagram

Two sets of DACVAL registers are present in the buffered DAC module: DACVALA and DACVALS. DACVALA is a read-only register that actively controls the DAC value. DACVALS is a writable shadow register that loads into DACVALA either immediately or synchronized with the next PWMSYNC event. The ideal output of the internal DAC can be calculated as shown in the equation below.

Reference

[1] TMS320F2837xD Microcontroller Workshop

TMS320F28x7x Interrupt Sources

The internal interrupt sources include the general purpose timers 0, 1, and 2, and all of the peripherals on the device. External interrupt sources include the three external interrupt lines, the trip zones, and the external reset pin. The core has 14 interrupt lines. The Peripheral Interrupt Expansion block, known as the PIE block, is connected to the core interrupt lines 1 through 12 and is used to expand the core interrupt capability, allowing up to 192 possible interrupt sources.

TMS320F28x7x Interrupt Processing

By using a series of flag and enable registers, the CPU can be configured to service one interrupt while others remain pending, or perhaps disabled when servicing certain critical tasks. When an interrupt signal occurs on a core line, the interrupt flag register (IFR) for that core line is set. If the appropriate interrupt enable register (IER) is enabled for that core line, and the interrupt global mask (INTM) is enabled, the interrupt signal will propagate to the core.

Once the interrupt service routine (ISR) starts processing the interrupt, the INTM bit is disabled to prevent nested interrupts. The IFR is then cleared and ready for the next interrupt signal. When the interrupt servicing is completed, the INTM bit is automatically enabled, allowing the next interrupt to be serviced. Notice that when the INTM bit is 0, the switch is closed and enabled. When the bit is 1, the switch is open and disabled. The IER is managed by ORing and ANDing mask values. The INTM bit in the status register is managed by using in-line assembly instructions.

TMS320F28x7x IFR, IER, INTM

TMS320F28x7x Peripheral Interrupt Expansion (PIE)

The C28x CPU core has a total of fourteen interrupt lines, of which two interrupt lines are directly connected to CPU Timers 1 and 2 (on INT13 and INT14, respectively) and the remaining twelve interrupt lines (INT1 through INT12) are used to service the peripheral interrupts. A Peripheral Interrupt Expansion (PIE) module multiplexes up to sixteen peripheral interrupts into each of the twelve CPU interrupt lines, further expanding support for up to 192 peripheral interrupt signals. The PIE module also expands the interrupt vector table, allowing each unique interrupt signal to have its own interrupt service routine (ISR), permitting the CPU to support a large number of peripherals.

The PIE module has an individual flag and enable bit for each peripheral interrupt signal. Each of the sixteen peripheral interrupt signals that are multiplexed into a single CPU interrupt line is referred to as a group, so the PIE module consists of 12 groups. Each PIE group has a 16-bit flag register (PIEIFRx), a 16-bit enable register (PIEIERx), and a bit field in the PIE acknowledge register (PIEACK) which acts as a common interrupt mask for the entire group.

For a peripheral interrupt to propagate to the CPU, the appropriate PIEIFR must be set, the PIEIER enabled, the CPU IFR set, the IER enabled, and the INTM enabled. Note that some peripherals can have multiple events trigger the same interrupt signal, and the cause of the interrupt can be determined by reading the peripheral’s status register.

We have already discussed the interrupt process in the core. Now we need to look at the peripheral interrupt expansion block. This block is connected to the core interrupt lines 1 through 12. The PIE block consists of 12 groups. Within each group, there are sixteen interrupt sources. Each group has a PIE interrupt enable register and a PIE interrupt flag register. Note that interrupt lines 13, 14, and NMI bypass the PIE block.

The PIE assignment table maps each peripheral interrupt to the unique vector location for that interrupt service routine. Notice the interrupt numbers on the left represent the twelve core group interrupt lines and the interrupt numbers across the top represent the lower eight of the sixteen peripheral interrupts within the core group interrupt line. The next figure shows the upper eight of the sixteen peripheral interrupts within the core group interrupt line.

Similar to the core interrupt process, the PIE module has an individual flag and enable bit for each peripheral interrupt signal. Each PIE group has a 16-bit flag register, a 16-bit enable register, and a bit field in the PIE acknowledge register which acts as a common interrupt mask for the entire group. The enable PIE bit in the PIECTRL register is used to activate the PIE module.

// Clear all interrupts and initialize PIE vector table:
// Disable CPU interrupts
DINT;

// Initialize the PIE control registers to their default state.
InitPieCtrl();

// Disable CPU interrupts and clear all CPU interrupt flags:
IER = 0x0000;
IFR = 0x0000;

// Initialize the PIE vector table with pointers to the shell Interrupt
// Service Routines (ISR).
InitPieVectTable();

// Interrupts that are used in this example are re-mapped to
// ISR functions found within this project
EALLOW;  
PieVectTable.SCIA_RX_INT = &RXAINT_recv_ready;
PieVectTable.SCIA_TX_INT = &TXAINT_data_sent;
EDIS;    

// Enable global Interrupts and higher priority real-time debug events
EINT;  // Enable Global interrupt INTM
ERTM;  // Enable Global realtime interrupt DBGM

// Initialize the SCIA ...
PieCtrlRegs.PIEIER9.bit.INTx1 = 1; // Enables SCI-A Receive (RX)
PieCtrlRegs.PIEIER9.bit.INTx2 = 1; // Enables SCI-A Transmit (TX)
IER |= (M_INT9);
PieCtrlRegs.PIEACK.all = (PIEACK_GROUP9);

// Clear all interrupts and initialize PIE vector table:
// Disable CPU interrupts
DINT;

// Initialize the PIE control registers to their default state.
InitPieCtrl();

// Disable CPU interrupts and clear all CPU interrupt flags:
IER = 0x0000;
IFR = 0x0000;

// Initialize the PIE vector table with pointers to the shell Interrupt
// Service Routines (ISR).
InitPieVectTable();

// Interrupts that are used in this example are re-mapped to
// ISR functions found within this project
EALLOW;  
PieVectTable.SCIA_RX_INT = &RXAINT_recv_ready;
PieVectTable.SCIA_TX_INT = &TXAINT_data_sent;
EDIS;    

// Enable global Interrupts and higher priority real-time debug events
EINT;  // Enable Global interrupt INTM
ERTM;  // Enable Global realtime interrupt DBGM

// Initialize the SCIA ...
PieCtrlRegs.PIEIER9.bit.INTx1 = 1; // Enables SCI-A Receive (RX)
PieCtrlRegs.PIEIER9.bit.INTx2 = 1; // Enables SCI-A Transmit (TX)
IER |= (M_INT9);
PieCtrlRegs.PIEACK.all = (PIEACK_GROUP9);

TMS320F28x7x PIE Block Initialization

The interrupt vector table, as mapped in the PIE interrupt assignment table, is located in the PieVect.c file. During processor initialization a function call to PieCtrl.c file is used to copy the interrupt vector table to the PIE RAM and then the PIE module is enabled by setting ENPIE to 1. When the CPU receives an interrupt, the vector address of the ISR is fetched from the PIE RAM, and the interrupt with the highest priority that is both flagged and enabled is executed. Priority is determined by the location within the interrupt vector table. The lowest numbered interrupt has the highest priority when multiple interrupts are pending.

In summary, the PIE initialization code flow is as follows. After the device is reset and execution of the boot code is completed, the selected boot option determines the code entry point. In this figure, two different entry points are shown. The one on the left is for memory block M0 RAM, and the one on the right is for flash.

In either case, the CodeStartBranch.asm file has a Long Branch instruction to the entry point of the runtime support library. After the runtime support library completes execution, main is called. In main, a function is called to initialize the interrupt process and enable the PIE module. When the CPU receives an interrupt, the vector address of the ISR is fetched from the PIE RAM, and the interrupt with the highest priority that is both flagged and enabled is executed. Priority is determined by the location within the interrupt vector table.

TMS320F28x7x Interrupt Signal Flow

In summary, the following steps occur during an interrupt process. First, a peripheral interrupt is generated and the PIE interrupt flag register is set. If the PIE interrupt enable register is enabled, then the core interrupt flag register will be set. Next, if the core interrupt enable register and global interrupt mask is enabled, the PIE vector table will redirect the code to the interrupt service routine.

TMS320F28x7D Dual-Core Interrupt Structure

Each C28x CPU core in the F2837xD device has its own PIE module, and each PIE module is configured independently. Some interrupt signals are sourced from shared peripherals that canbe owned by either CPU, and these interrupt signals are sent to both CPU PIE modules regardless of which CPU owns the peripheral. Therefore, if enabled a peripheral owned by one CPU can cause an interrupt on the other CPU.

TMS320F28x7x Interrupt Response and Latency

Reference

[1] TMS320F2837xD Microcontroller Workshop

FreeRTOS is a lightweight, deterministic real-time operating system (RTOS) designed for microcontrollers and small embedded processors where timing, reliability, and resource efficiency are critical. Unlike general-purpose operating systems, FreeRTOS provides a minimal kernel focused on predictable task scheduling, fast interrupt response, and low memory footprint, making it well suited for motor control, robotics, automotive, and IoT devices. It enables developers to structure firmware as multiple concurrent tasks instead of a single super-loop, improving modularity and maintainability while still meeting strict real-time deadlines. The kernel offers essential synchronization and communication mechanisms such as queues, semaphores, mutexes, software timers, and event groups, allowing safe data exchange between tasks and interrupt service routines. Because it is portable across many architectures and integrates easily with vendor SDKs, FreeRTOS has become one of the most widely adopted foundations for modern embedded real-time software.

Scheduling & Execution Model

• Supports preemptive, cooperative, and time-slice scheduling
• Supports real-time tasks and co-routines
• Unlimited number of tasks
• Unlimited priority levels

Memory & Footprint

• Very small kernel footprint (typically 4–9 KB RAM)
• Components can use static or dynamic memory allocation
• Written mainly in C language for portability
• Portable across 40+ CPU architectures

Power & Efficiency

• Provides Tickless mode for low-power applications
• Efficient software timers
• Optimized for small microcontrollers

Inter-Task Communication & Synchronization

• Task notifications
• Message queues
• Binary semaphores
• Counting semaphores
• Recursive mutexes
• Mutexes with priority inheritance
• Event groups (event flags)

Safety & Reliability

• Stack overflow detection
• Strong execution tracing capability
• MPU support on Cortex-M (e.g., STM32F429, STM32F407)
• SafeRTOS derived version available for higher code integrity

FreeRTOS Files

FreeRTOS General-Purpose Functional Files and Their Functions

Common Macro Definitions in projdefs.h and Their Functions

Reference

[1] FreeRTOS
[2] FreeRTOS LTS Libraries
[3] Beginner’s guides to FreeRTOS
[4] FreeRTOS Documentation
[5] FreeRTOS Book Examples
[6] FreeRTOS Kernel Developer Docs

TMS320F28x7x ADC Subsystem

The F2837xD includes four independent high-performance ADC modules which can be accessed by both CPU subsystems, allowing the device to efficiently manage multiple analog signals for enhanced overall system throughput. Each ADC module has a single sample-and-hold (S/H) circuit and using multiple ADC modules enables simultaneous sampling or sequential sampling. The ADC module is implemented using a successive approximation (SAR) type ADC with a configurable resolution of either 16-bits or 12-bits.

For 16-bit resolution, the ADC performs differential signal conversions with a performance of 1.1 MSPS, yielding 4.4 MSPS for the device. In differential signal mode, a pair of pins (positive input ADCINxP and negative input ADCINxN) is sampled and the input applied to the converter is the difference between the two pins (ADCINxP – ADCINxN). A benefit of differential signaling mode is the ability to cancel noise that may be introduced common to both inputs. For 12-bit resolution, the ADC performs single-ended signal conversions with a performance of 3.5 MSPS, yielding 14 MSPS for the device. In single-ended mode, a single pin (ADCINx) is sampled and applied to the input of the converter.

TMS320F28x7x ADC Module Block Diagram

The ADC triggering and conversion sequencing is managed by a series of start-of-conversion (SOCx) configuration registers. Each SOCx register configures a single channel conversion, where the SOCx register specifies the trigger source that starts the conversion, the channel to convert, and the acquisition sample window duration. Multiple SOCx registers can be configured for the same trigger, channel, and/or acquisition window. Configuring multiple SOCx registers to use the same trigger will cause that trigger to perform a sequence of conversions, and configuring multiple SOCx registers for the same trigger and channel can be used to oversample the signal.

The various trigger sources that can be used to start an ADC conversion include the General Purpose Timers from each CPU subsystem, the ePWM modules, an external pin, and by software. Also, the flag setting of either ADCINT1 or ADCINT2 can be configured as a trigger source which can be used for continuous conversion operation. The ADC interrupt logic can generate up to four interrupts. The results for SOC 0 through 15 appear in result registers 0 through 15, respectively.

TMS320F28x7x ADC SOCx Functional Diagram

The figure below is a conceptual view highlighting a single ADC start-of-conversion (SOC) functional flow from triggering to interrupt generation. This figure is replicated 16 times and the red text indicates the register names.

TMS320F28x7x ADC Triggering

The top example in the figure below shows channels A1, A3, and A5 being converted with a trigger from EPWM1. After A5 is converted, ADCINT1 is generated. The bottom example shows channels A2, A4, and A6 being converted initially by a software trigger. Then, after A6 is converted, ADCINT2 is generated and also fed back as a trigger to start the process again.

TMS320F28x7x ADC Ping-Pong Triggering

The ADC ping-pong triggering example in the figure below shows channels B0 through B5 being converted, triggered initially by software. After channel B2 is converted, ADCINT1 is generated, which also triggers channel B3. After channel B5 is converted, ADCINT2 is generated and is also fed back to start the process again from the beginning. Additionally, ADCINT1 and ADCINT2 are being used to manage the ping-pong interrupts for the interrupt service routines.

TMS320F28x7x ADC Conversion Priority

When multiple triggers are received at the same time, the ADC conversion priority determines the order in which they are converted. Three different priority modes are supported. The default priority mode is round robin, where no start-of-conversion has an inherently higher priority over another, and the priority depends upon a round robin pointer. The round robin pointer operates in a circular fashion, constantly wrapping around to the beginning. In high priority mode, one or more than one start-of-conversion is assigned as high priority. The high priority start-of-conversion can then interrupt the round robin wheel, and after it has been converted the wheel will continue where it was interrupted. High priority mode is assigned first to the lower number start-of-conversion and then in increasing numerical order. If two high priority start-of-conversion triggers occur at the same time, the lower number will take precedence. Burst mode allows a single trigger to convert one or more than one start-of-conversion sequentially at a time. This mode uses a separate Burst Control register to select the burst size and trigger source.

In this conversion priority functional diagram, the Start-of-Conversion Priority Control Register contains two bit fields. The Start-of-Conversion Priority bit fields determine the cutoff point between high priority and round robin mode, whereas the Round-Robin Pointer bit fields contains the last converted round robin start-of-conversion which determines the order of conversions.

The Round-Robin Burst mode utilizes an ADC Burst Control Register to enable the burst mode, determine the burst size, and select the burst trigger source.

TMS320F28x7x ADC Post Processing Block

To further enhance the capabilities of the ADC, each ADC module incorporates four postprocessing blocks (PPB), and each PPB can be linked to any of the ADC result registers. The PPBs can be used for offset correction, calculating an error from a set-point, detecting a limit and zero-crossing, and capturing a trigger-to-sample delay.

Offset correction can simultaneously remove an offset associated with an ADCIN channel that was possibly caused by external sensors or signal sources with zero-overhead, thereby saving processor cycles.

Error calculation can automatically subtract out a computed error from a set-point or expected result register value, reducing the sample to output latency and software overhead.

Limit and zero-crossing detection automatically performs a check against a high/low limit or zero-crossing and can generate a trip to the ePWM and/or generate an interrupt. This lowers the sample to ePWM latency and reduces software overhead. Also, it can trip the ePWM based on an out-of-range ADC conversion without any CPU intervention which is useful for safety conscious applications.

Sample delay capture records the delay between when the SOCx is triggered and when it begins to be sampled. It can enable software techniques to be used for reducing the delay error.

TMS320F28x7x ADC Clocking Flow

TMS320F28x7x ADC Converter Registers

TMS320F28x7x ADC Control Registers

TMS320F28x7x ADC Conversion Result Registers

TMS320F28x7x ADC Signed Input Voltages

TMS320F28x7x ADC Calibration and Reference

Reference

[1] TMS320F2837xD Microcontroller Workshop

TMS320F28x7x General Purpose Digital I/O

The F2837xD device incorporates a multiplexing scheme to enable each I/O pin to be configured as a GPIO pin or one of several peripheral I/O signals. Sharing a pin across multiple functions maximizes application flexibility while minimizing package size and cost. A GPIO Group multiplexer and four GPIO Index multiplexers provide a double layer of multiplexing to allow up to twelve independent peripheral signals and a digital I/O function to share a single pin.

Each output pin can be controlled by either a peripheral or CPU1, CPU1 CLA, CPU2, or CPU2 CLA. However, the peripheral multiplexing and pin assignment can only be configured by CPU1. By default, all of the pins are configured as GPIO, and when configured as a signal input pin, a qualification sampling period can be specified to remove unwanted noise. Optionally, each pin has an internal pullup resistor that can be enabled in order to keep the input pin in a known state when no external signal is driving the pin.

The I/O pins are grouped into six ports, and each port has 32 pins except for the sixth port which has nine pins (i.e. the remaining I/O pins). For a GPIO, each port has a series of registers that are used to control the value on the pins, and within these registers each bit corresponds to one GPIO pin.

If the pin is configured as GPIO, a direction (DIR) register is used to specify the pin as either an input or output. By default, all GPIO pins are inputs. The current state of a GPIO pin corresponds to a bit value in a data (DAT) register, regardless if the pin is configured as GPIO or a peripheral function. Writing to the DAT register bit field clears or sets the corresponding output latch, and if the pin is configured as an output the pin will be driven either low or high. The state of various GPIO output pins on the same port can be easily modified using the SET, CLEAR, and TOGGLE registers. The advantage of using these registers is a single instruction can be used to modify only the pins specified without disturbing the other pins. This also eliminates any timing issues that may occur when writing directly to the data registers.

TMS320F28x7x GPIO Input Qualification

The input qualification scheme is very flexible, and the type of input qualification can be configured for each GPIO pin individually. In the case of a GPIO input pin, the qualification can be specified as only synchronize to SYSCLKOUT or qualification by a sampling window. For pins that are configured as peripheral inputs, the input can also be asynchronous in addition to synchronized to SYSCLKOUT or qualified by a sampling window.

TMS320F28x7x GPIO Input X-Bar

The Input X-BAR is used to route external GPIO signals into the device. It has access to every GPIO pin, where each signal can be routed to any or multiple destinations which include the ADCs, eCAPs, ePWMs, Output X-BAR, and external interrupts. This provides additional flexibility above the multiplexing scheme used by the GPIO structure. Since the GPIO does not affect the Input X-BAR, it is possible to route the output of one peripheral to another, such as measuring the output of an ePWM with an eCAP for frequency testing.

TMS320F28x7x GPIO Output X-Bar

The Output X-BAR is used to route various internal signals out of the device. It contains eight outputs that are routed to the GPIO structure, where each output has one or multiple assigned pin positions, which are labeled as OUTPUTXBARx. Additionally, the Output X-BAR can select a single signal or logically OR up to 32 signals.

TMS320F28x7x External Interrupts

• Five external interrupt signals: XINT1, XINT2, XINT3, XINT4 and XINT5
• Each can be mapped to any of GPIO pins via the X-Bar Input architecture
• XINT1, XINT2 and XINT3 also each have a free-running 16-bit counter that measures the elapsed time between interrupts. The counter resets to zero each time the interrupt occurs

Reference

[1] TMS320F2837xD Microcontroller Workshop

TMS320F28x7x Oscillator / PLL Clock Module

The device clock signals are derived from one of four clock sources:

• Internal Oscillator 1 (INTOSC1)
• Internal Oscillator 2 (INTOSC2)
• External Oscillator (XTAL)
• Auxiliary Clock Input (AUXCLKIN)

At power-up, the device is clocked from the on-chip 10 MHz oscillator INTOSC2. INTSOC2 is the primary internal clock source, and is the default system clock at reset. The device also includes a redundant on-chip 10 MHz oscillator INTOSC1. INTOSC1 is a backup clock source, which normally only clocks the watchdog timers and missing clock detection circuit.

Additionally, the device includes dedicated X1 and X2 pins for supporting an external clock source such as an external oscillator, crystal, or resonator. The AUXCLKIN is used as the bit clock source for the USB and CAN to generate the precise frequency requirements.

The clock sources can be multiplied using the PLL and divided down to produce the desired clock frequencies for a specific application. By default, the CPU1 subsystem owns the PLL clock configuration, however a clock control semaphore is available for the CPU2 subsystem to access the clock configuration registers.

A clock source can be fed directly into the core or multiplied using the PLL. The PLL gives us the capability to use the internal 10 MHz oscillator and run the device at the full clock frequency. If the input clock is removed after the PLL is locked, the input clock failed detect circuitry will issue a limp mode clock of 1 to 4 MHz. Additionally, an internal device reset will be issued. The lowspeed peripheral clock prescaler is used to clock some of the communication peripherals.

The PLL has a 7-bit integer and 2-bit fractional ratio control to select different CPU clock rates. The C28x CPU provides a SYSCLK clock signal. This signal is prescaled to provide a clock source for some of the on-chip communication peripherals through the low-speed peripheral clock prescaler. Other peripherals are clocked by SYSCLK and use their own clock prescalers for operation.

// External Oscillator (XTAL): 20 MHz
// PLLSYSCLK = (XTAL_OSC) * (IMULT + FMULT) / (PLLSYSCLKDIV)
// CPUx.SYSCLK = PLLSYSCLK = 200 MHz
// CPUx.LSPCLK = PLLSYSCLK / LSPCLKDIV = 50 MHz
ClkCfgRegs.CLKSRCCTL1.OSCCLKSRCSEL   = 0x01  // EXTCLK
ClkCfgRegs.SYSPLLMULT.bit.IMULT      = 0x14  // 20
ClkCfgRegs.SYSPLLMULT.bit.FMULT      = 0x00  // 0
ClkCfgRegs.SYSPLLCTL1.PLLCLKEN       = 0x01  // PLL Clock Enable
ClkCfgRegs.SYSCLKDIVSEL.PLLSYSCLKDIV = 0x01  // Divide by 2
ClkCfgRegs.LOSPCP.LSPCLKDIV          = 0x02  // Divide by 4

// External Oscillator (XTAL): 20 MHz
// PLLSYSCLK = (XTAL_OSC) * (IMULT + FMULT) / (PLLSYSCLKDIV)
// CPUx.SYSCLK = PLLSYSCLK = 200 MHz
// CPUx.LSPCLK = PLLSYSCLK / LSPCLKDIV = 50 MHz
ClkCfgRegs.CLKSRCCTL1.OSCCLKSRCSEL   = 0x01  // EXTCLK
ClkCfgRegs.SYSPLLMULT.bit.IMULT      = 0x14  // 20
ClkCfgRegs.SYSPLLMULT.bit.FMULT      = 0x00  // 0
ClkCfgRegs.SYSPLLCTL1.PLLCLKEN       = 0x01  // PLL Clock Enable
ClkCfgRegs.SYSCLKDIVSEL.PLLSYSCLKDIV = 0x01  // Divide by 2
ClkCfgRegs.LOSPCP.LSPCLKDIV          = 0x02  // Divide by 4

TMS320F28x7D Dual-Core System Clock

The PLL system clock is fed to both the CPU1 and CPU2 subsystems. By default, all peripherals are assigned to the CPU1 subsystem. Using the CPU selection register, each individual peripheral can be assigned to either the CPU1 or CPU2 subsystem. The clock for the EPWM modules are limited to 100 MHz, and by using the peripheral clock divider selection register, this clock can be divided down to meet this specification.

The dual-core CPU select register selects either CPU1 or CPU2 as the clock source for each peripheral. The peripheral clock control register allows individual peripheral clock signals to be enabled or disabled. If a peripheral is not being used, its clock signal could be disabled, thus reducing power consumption.

TMS320F28x7x Watchdog Timer

The watchdog timer is a safety feature, which resets the device if the program runs away or gets trapped in an unintended infinite loop. The watchdog counter runs independent of the CPU. If the counter overflows, a user-selectable reset or interrupt is triggered. During runtime the correct key values in the proper sequence must be written to the watchdog key register in order to reset the counter before it overflows.

Resets the C28x if the CPU crashes

• Watchdog counter runs independent of CPU
• If counter overflows, a reset or interrupt is triggered (user selectable)
• CPU must write correct data key sequence to reset the counter before overflow

The watchdog timer provides a safeguard against CPU crashes by automatically initiating a reset if it is not serviced by the CPU at regular intervals. In motor control applications, this helps protect the motor and drive electronics when control is lost due to a CPU lockup. Any CPU reset will set the PWM outputs to a high-impedance state, which should turn off the power converters in a properly designed system.

The watchdog timer starts running immediately after system power-up/reset, and must be dealt with by software soon after. Specifically, the watchdog must be serviced or disabled within 13.11 milliseconds (using a 10 MHz watchdog clock) after any reset before a watchdog initiated reset will occur. This translates into 131,072 watchdog clock cycles, which is a seemingly tremendous amount. Indeed, this is plenty of time to get the watchdog configured as desired and serviced. A failure of your software to properly handle the watchdog after reset could cause an endless cycle of watchdog initiated resets to occur.

The watchdog clock is divided by 512 and prescaled, if desired for slower watchdog time periods. A watchdog disable switch allows the watchdog to be enabled and disabled. Also a watchdog override switch provides an additional safety mechanism to insure the watchdog cannot be disabled. Once set, the only means to disable the watchdog is by a system reset.

During initialization, a value 101 is written into the watchdog check bit fields. Any other values will cause a reset or interrupt. During run time, the correct keys must be written into the watchdog key register before the watchdog counter overflows and issues a reset or interrupt. Issuing a reset or interrupt is user-selectable. The watchdog also contains an optional windowing feature that requires a minimum delay between counter resets.

TMS320F28x7x Low Power Modes

TMS320F28x7x Register Protection

A series of lock registers can be used to protect several system configuration settings from spurious CPU writes. After the lock registers bits are set, the respective locked registers can no longer be modified by software.

Reference

[1] TMS320F2837xD Microcontroller Workshop

TMS320F28x7x Reset Sources

The device has various reset sources, but in general resets on CPU1 will reset the entire device and resets on CPU2 will reset only the CPU2 subsystem. The reset sources include an external reset pin, watchdog timer reset, power-on reset which generates a device reset during power-up conditions, Hibernate reset, as well as a missing clock detect reset. A reset cause register (RESC) is available for each CPU subsystem which can be read to determine the cause of the reset. The external reset pin is the main chip-level reset for the device, and it resets both CPU subsystems to their default state. The power-on reset (POR) circuit is used to create a clean reset throughout the device during power-up, while suppressing glitches on the input/output pins.

TMS320F28x7x Dual-Core Boot Process

• CPU1 starts execution from CPU1 boot ROM while CPU2 is held in reset
• CPU1 controls the boot process
• CPU2 goes through its own boot process under the control of CPU1 – except when CPU2 is set to boot-to-flash
• IPC registers are used to communicate between CPU1 and CPU2 during the boot process

During the F2837xD dual-core microcontroller booting, CPU1 controls the boot process and starts execution from the CPU1 boot ROM while CPU2 is held in reset. CPU2 goes through its own boot process under the control of CPU1, except when CPU2 is set to boot-to-flash. The IPC registers are used to communicate between CPU1 and CPU2 during the boot process. Additionally, the boot ROM contains the necessary boot loading routines to support peripheral boot loading.

TMS320F28x7x Reset – Bootloader

When the device is reset, the peripheral interrupt expansion block, also known as the PIE block, and the master interrupt switch INTM are disabled. This prevents any interrupts during the boot process. The program counter is set to 0x3FFFC0, where the reset vector is fetched. In the boot code the JTAG Test Reset line (TRST line) is checked to determine if the emulator is connected.

If the emulator is connected, then the boot process follows the Emulation Boot mode flow. In Emulation Boot mode, the boot is determined by the EMU_BOOTCTRL register located in the PIE RAM. Specific details about the boot flow are then determined by the EMU_KEY and EMU_BMODE bit fields in the EMU_BOOTCTRL register.

If the emulator is not connected, the boot process follows the Stand-alone Boot mode flow. In Stand-alone Boot mode, the boot is determined by two GPIO pins and the Z1-BOOTCTRL and Z2-BOOTCTRL registers located in the OTP. Specific details about the boot flow are then determined by the OTP_KEY and OTP_BMODE bit fields in the Z1-BOOTCTRL and Z2-BOOTCTRL registers

TMS320F28x7x Emulation Boot Mode

In Emulation Boot mode, first the EMU_KEY bit fields are checked for a value of 0x5A. If either EMU_KEY or EMU_BMODE bit fields are invalid, the “Wait” boot mode is entered. These bit field values can then be modified using the debugger and then a reset is issued to restart the boot process. This is the typical sequence followed during device power-up with the emulator connected, allowing the user to control the boot process using the debugger.

Once the EMU_KEY bit fields are set to 0x5A, then the EMU_BMODE bit field values determines the boot mode. The various Emulation Boot modes supported are Parallel I/O, SCI, SPI, I2C, CAN, M0 RAM, FLASH, USB, and Wait. The GetMode and when EMU_BMODE bit fields have a value of 0xFE or 0xFF are used to emulate the Stand-alone Boot mode.

TMS320F28x7x Stand-Alone Boot Mode

In Stand-alone boot mode, first GPIO pins 72 and 84 are checked to determine if the boot mode is Parallel I/O, SCI, Wait, or GetMode. These pin can be remapped to any GPIO pins, if needed, and the default “unconnected” pins set the boot mode to GetMode. In GetMode the OTP_KEY bit fields in the Z1-BOOTCTRL and Z2-BOOTCTRL registers are checked for a value of 0x5A. An un-programmed device will have these locations set as 1’s, and the flash boot mode is entered, as expected for the default mode. If the OTP_KEY bit fields in either Z1-BOOTCTRL or Z2-BOOTCTRL registers has a value of 0x5A, then the OTP_BMODE bit field values in the registers determines the boot mode. The various Stand-alone Boot modes supported are Parallel I/O, SCI, SPI, I2C, CAN, M0 RAM, FLASH, USB, and Wait.

TMS320F28x7x Reset Code Flow

The reset code flow is as follows. After reset, the program counter is set to 0x3FFFC0, where the flow is vectored to the Init_Boot code in the Boot ROM. The Init_Boot code defines the execution entry based on emulation boot mode or stand-alone boot mode. The entry point can be executing boot-loading routines, entry to the flash, or M0 RAM.

TMS320F28x7x Emulation Boot Mode using GEL

The CCS GEL file is used to setup the boot modes for the device during debug. By default the GEL file provides functions to set the device for Boot to SARAM and Boot to FLASH. It can be modified to include other boot mode options, if desired.

To access the GEL file use: Views -> GEL Files

TMS320F28x7x main()

When the bootloader process is completed, a branch to the compiler runtime support library is located at the code entry point. This branch to _c_int00 is executed, then the compiler environment is set up, and finally main is called.

At the code entry point, branch to _c_int00()

• Part of compiler runtime support library
• Sets up compiler environment
• Calls main()

TMS320F28x7x Peripheral Software Reset Registers

The peripheral software reset register contains the reset bit for each peripheral.

Reference

[1] TMS320F2837xD Microcontroller Workshop