TI Training home
Delfino™ premium performance MCUs
Delfino™ MCU family devices Designing with the C2000 F2807x and F2837x Microcontroller Family
Delfino™ premium performance MCUs
1.5 Designing with the C2000 F2807x and F2837x Microcontroller Family
Hello. My name is Ken Schachter, and welcome to designing with the F2807x and F2837x microcontroller family. This session is a general overview of designing with the F2807x and F2837x device family. It will cover the device features that are different from the previous C2000 device families. Most importantly, the easily misunderstood items will be discussed, along with code snippets that reinforce how the device is programmed.
Topics include boot modes, peripheral interrupt expansion block, clock module, configuring the GPIOs and X-bars, CLA and DMA peripheral assignment, dual code security module, and inter-processor communications. This session is based on lessons learned during the development of the F2837xD multi-day workshop. Some knowledge about the device architecture and the peripheral register header files is needed for this session.
This presentation is divided into eight parts, session introduction, boot process, PIE and clock module, configuring GPIO and X-bars, selected peripheral configuration, which will include the ADC, DAC, DMA, and CLA, dual code security module, inter-processor communication, and resources. We will now start with the session introduction. This presentation will cover the unique features that are different from the previous C2000 device families and explain easily misunderstood concepts about the architecture, using code snippets to reinforce how the devise is programmed. The topics are based on the lessons learned during the development of the multi-day workshop. Some knowledge about the device architecture and programming is a prerequisite.
The C2000 microcontroller family can be classified as Piccolo devices and Delfino devices. The F2807x is classified as a Piccolo device, whereas the F2837x is classified as a Delfino device. The F2837xS is a single CPU version, where the F2837xD is a dual CPU version. This chart highlights the various peripherals and features on each device family.
The block diagram can be divided into three main sections. On center is the CPUs, immediately to the left is the analog subsystem, and along the bottom are the peripherals. This diagram shown is for the dual core device. Other device members are a subset of this block diagram.
The memory map is similar to the previous C2000 devices, with the exception of a message RAM shared between the two CPUs, as well as the global shared memory blocks. Next, we will discuss the boot process. After reset, the PIE global interrupts are disabled. The program counter is loaded to 3F FFFC0, and the reset vector is fetched from the Boot Rom. CPU2 is held in reset until released by CPU1.
The JTAG test reset line is tested to determine if the emulator is connected or not connected to the device. If it is connected to the device, it is in emulation boot mode and the boot is determined by EMU_KEY and EMU_BMODE. If it is not connected to the device, it is in standalone boot mode, and the boot is determined by OTP_KEY and OTP_BMODE.
In emulation boot mode, the emulator is connected. First, EMU_KEY is tested for a value of 5a. If EMU_KEY does not have a value of 5a, a wait mode is entered. Then the debugger can be used to modify the keys, and the debugger can then issue a reset to restart the boot process.
Once EMU_KEY has a value of 5a, EMU_BMODE is then evaluated. Values FE and FF are used for standalone boot mode emulation. EMU_BMODE mode can be set to parallel I/O, SCI, GetMode, SPI, I2C, CAN, memory block M0, FLASH, Wait, or USB. Alternate pin mapping is also available. The GetMode is used to emulate the standalone boot mode by reading the values in OTP_KEY and OTP_BMODE.
In standalone boot mode, the emulator is not connected. The boot is determined by two GPIO pins and a boot control register. Reset code flow summary. After reset, the program counter is set to 3F FFC0. 0 At that location is a reset vector which then runs the [INAUDIBLE] boot code inside the Boot Rom. The execution entry is then determined by emulation boot mode or standalone boot mode.
Next, we will discuss the PIE and clock module. There are many internal and external interrupt sources. All interrupt sources go through the PIE, Peripheral Interrupt Expansion block, with the exception of the external reset, timer interrupt one, and timer interrupt two.
The peripheral interrupt expansion block is made up of 12 groups. There are up to 16 possible interrupts in each group, for a total of up to 192 interrupts. Each group has an peripheral interrupt expansion interrupt flag register, as well as a peripheral interrupt expansion enable register. Each group then gets fed into the core interrupt logic.
PIE block initialization is performed by copying the PIE vector table to the PIE RAM am in the memory map and then enabling that block. Interrupt signal flow summary. When an interrupt occurs, the peripheral interrupt expansion interrupt flag register is set. If the peripheral interrupt expansion enable register is closed, the signal propagates through to the core interrupt logic where the interrupt flag register is set.
If the interrupt enable line is closed and the global switch is closed, the interrupt signal then propagates to the PIE block, which is then vectored into the ISR. We have just discussed the interrupt flow for a single CPU. For a second CPU, the flow is identical, except a common set of peripherals are used. There are four possible clock sources available, internal oscillator one, internal oscillator two, external clock source in, or external crystal.
Internal oscillator two is the default oscillator. A common PLL SYS clock is fed to CPU1 and CPU2. Using the CPU selection register, each peripheral can be assigned to either CPU1 or CPU2. EPWM is limited to 100 megahertz for its clock, and this clock signal can be divided down using the peripheral clock divider selection register.
The dual course selection register assigns each peripheral to either CPU1 or CPU2. By default, all peripherals are assigned to CPU1. The peripheral clock control register enables the clock for each peripheral. The insert is an example of code enabling the clock for various peripherals.
The peripheral software reset register is used to reset the peripherals. The insert shows an example of code that is used to reset the peripheral and release the peripheral from reset. Next, we'll discuss configuring the GPIO and X-bars.
The GPIO is implemented with a two level MUX scheme. First, the group MUX must be set, and then the MUX within the group needs to be set. Notice on the right side the group MUX and the individual MUXs for each group.
This code example shows GPIO0 being set for EPWM1A. Notice that the group MUX is set to 0 and the MUX within the group is set to 1. Also, notice that the output X-bar is MUXed with the GPIO pins. For F2837xD, there's a dual core GPIO core selection register which selects which CPU core controls the GPIO pin.
This code example shows the setting of GPIO31 to be controlled by CPU2. All of the GPIO lines are fed into the input X-bar, where they can be routed to the [? e-capture ?] units, the external interrupt lines, the EPWM modules, the ADC, and the output X-bar. The input X-bar architecture block diagram shown on this slide is replicated 14 times. The table below shows the routing of the 14 inputs.
Notice the code used for setting GPIO24 as an input to [? e-capture ?] one. The GPIO output X-bar routes the various signals shown on this slide as outputs through the GPIO module. The GPIO output architecture block diagram shown in this slide is replicated eight times. The tables below show the various signals that are routed as outputs.
The code shown here selects one of four possible MUX inputs that will be routed to the output X-bar, along with the MUX enable. The EPWM X-bar routes the various sources shown on this slide as trip inputs to all of the EPWM modules. The EPWM X-bar architecture block diagram shown in this slide is replicated eight times. The tables below show the sources that are used as trip inputs to the EPWM modules.
The code example here shows the selection of one of four possible MUX inputs that will be used as a trip source to the EPWM module along with the MUX enable. Next, we'll discuss the selected peripheral configuration for the ADC, DAC, DMA, and CLA. The F2807x and F2837x devices utilize a starter conversion ADC. Enhancements include the post processing blocks.
The ADC has a maximum clock frequency of 50 megahertz. This diagram shows the internal oscillator at 10 megahertz being multiplied to a system clock of 200 megahertz and then being divided down to 50 megahertz to the ADC core. ADC control register 2 contains the signal mode and resolution bit fields. Neither one should be configured manually, but they should be configured by the ADC set mode function in the source code.
It's important to note that the digital to analog converter output pin and the ADC input pin is the same pin, and it is not multiplex between them. The DMA has various triggers, sources, and destinations. The DMA and CLA have common peripheral access, where common peripherals can be accessed by the CPU and either DMA or CLA. By default, they are connected to the CLA.
The trigger source for each DMA channel is shown in the table on this slide. The code example shows ADCAINT1 being set as a trigger source for DMA Channel 1. The CLA is a 32-bit floating point processor that responds to peripheral triggers and executes code independently of the main CPU. It was designed for a fast trigger response and oriented towards math computations. It has direct access to the various control peripherals, and it frees up the CPU for other tasks such as communications and diagnostics.
Notice that LS0 through LS5 RAM blocks can be used as CLA program memory or CLA data memory. The CLA memory configuration is first set by selecting the LS RAM block to be either dedicated to the CPU or shared between the CPU and CLA. If it is shared between the CPU and CLA, the memory block is then set to either be data memory or program memory.
In this code example, LS0, LS1, LS2, and LS4 memories are used with the CLA. LS4 is configured as CLA program memory, the other memories as data memory. The CLA trigger sources for each task is shown in the table on this slide. In the code example, ADCAINT1 is being set as a trigger source to CLA task 1.
Next, we will discuss the dual code security module. The dual code security module offers protection for two zones. Note, for dual core devices each CPU has its own dual code security module. Each zone has its own dedicated secure OTP, which contains the security settings.
The following on-chip can be secured, flash each sector individually, LS0 through LS5 RAM each block individually, D0 and D1 RAM each block individually, and CLA, including the CLA message RAMs. Data reads and writes from secured memory are only allowed for code running from secured memory. All other data reads and write accesses are blocked. Each securable on-chip memory resource can be allocated to either a zone 1 zone 2, or as non-secure. Secure
Each zone is secured by its own 128-bit user-defined code security module password. The passwords for each zone is stored in its dedicated OTP location. A zone select block contains information about the zone, such as how the memories are allocated and the passwords. There are three link pointers that are used to select the active zone select block. The final link point of value is resolved by comparing all three individual link point values bitwise voting logic.
OTP values ones can be programmed as zeros, but no a erase operation can be performed. This diagram shows that three link pointers need to be programmed with the same value to select the active zone select block. The code security module is always secured after reset. To unsecure the code security module, perform a dummy read of each code security module password register.
Write the correct password to each of the code security module key registers. Passwords are all Fs on new devices. When passwords are all Fs, only a read of each password location is required to unsecure the device. The bootloader does these dummy reads, and hence unsecures the devices that do not have passwords programmed.
Next, we will discuss inter-processor communications. The F2837xD device contains up to 16 blocks of global shared RAM named GS0 through GS5. Each block is 4K words in size, and each block can be configured to be either used by CPU1 or CPU2.
The IPC message registers provide a very simple and flexible scheme for messaging. Dedicated registers are mapped to both CPUs. The definition is up to the application software. Each CPU has 32 flags with four interrupts.
The requesting CPU contains set, flag, and clear registers. The receiving CPU contains status and acknowledge registers. This diagram shows the messaging with IPC flags and interrupts. Basic IPC data transfer requires no software drivers and is easy to use.
The message RAMs, or global shared RAMs, are used to transfer data between the processors at known addresses. The use of the IPC flags tell the other processor that the data is ready. CPU1 writes to the message RAM. CPU1 then writes a 1 to the IPC set bin.
CPU2 sees the IPC status bit is set. CPU2 reads the message, and CPU2 writes a 1 back to the IPC acknowledge bin. This inter-processor communication example is taken from the multi-day workshop.
First, on CPU1, the DAC is configured to generate a sine wave. A jumper wire connecting the output of the DAC is fed into the input of the ADC. The ADC is being triggered by PWM2 at a rate of 50 kilohertz.
ADCA1ISR reads the ADC result register and writes to the IPC1. On CPU2, IPC1_ISR reads IPC1 data and stores it in a circular buffer. Then, it writes the next sine data value to IPC0. 0 CPU1 IPC0_ISR reads IPC0 data and writes the new value to the DAC. And the process repeats.
In CPU1 and CPU2 main, the code being highlighted shows IPC17 being used to synchronize the two processors. This slide shows CPU1 interrupt service routines. The top figure is ADCA1ISR, and notice that the IPC1 flag, the CPU, is highlighted. The lower figure contains the IPC0 ISR, and notice that the IPC0 flag is being cleared.
This slide shows CPU2's interrupt service routine for IPC1_ISR. Notice the highlighted areas for clearing the IPC1 flag and for setting the IPC0 flag for CPU1. The next section discusses the available resources.
The materials used in this presentation were derived from the development of the multi-day workshop. This multi-day workshop is a three day, hands-on class covering the information needed to start designing with the F2807x and F2837xD microcontroller families. Thank you for watching, and I hope this information was useful.
June 30, 2015
This presentation is an overview of designing with the C2000 F2807x/F2837x device family. The presentation will cover device features that are different from the previous C2000 device families. Additionally, code snippets are used to reinforce how the device is programmed. The materials are based on the lessons learned from the development of the F2837xD multi-day workshop. Some knowledge about the device architecture and the peripheral register header files is needed for this presentation.
This course is also a part of the following series