Stay updated with the TI C2000 Real-time Microcontroller blogs
TI C2000 Real-Time Microcontroller: Control, Sensing, and Communication
- TMS320F28x7x Memory Map
- TMS320F2837xD Memory Map
- TMS320C28x C/C++ COFF and EABI Data Types
- TMS320F28x7x Linker Command File
TMS320F28x7x Memory Map
The F28x7x MCU utilizes a memory map where the unified memory blocks can be accessed in either program space, data space, or both spaces. This type of memory map lends itself well for supporting high-level programming languages. The memory structure consisting of dedicated RAM blocks, shared local RAM blocks, shared global RAM blocks, message RAM blocks, Flash, and one-time programmable (OTP) memory. The Boot is factory programmed with boot software routines and standard tables used in math related algorithms.
The C28x CPU core contains no memory, but can access on-chip and off-chip memory. The C28x uses 32-bit data addresses and 22-bit program addresses. This allows for a total address reach of 4G words (1 word = 16-bits) in data memory and 4M words in program memory.
The F28x7x MCU utilizes a memory map where the unified memory blocks can be accessed in either program space, data space, or both spaces. This type of memory map lends itself well for supporting high-level programming languages. The memory structure consisting of dedicated RAM blocks, shared local RAM blocks, shared global RAM blocks, message RAM blocks, Flash, and one-time programmable (OTP) memory. The Boot is factory programmed with boot software routines and standard tables used in math related algorithms.
The C28x CPU core contains no memory, but can access on-chip and off-chip memory. The C28x uses 32-bit data addresses and 22-bit program addresses. This allows for a total address reach of 4G words (1 word = 16-bits) in data memory and 4M words in program memory.
There are four dedicated RAM block (M0, M1, D0, and D1) which are tightly coupled with the CPU, and only the CPU has access to them. The PIE Vectors are a special memory area
containing the vectors for the peripheral interrupts. The six local shared memory blocks, LS0 through LS5, are accessible by its CPU and CLA. Global shared memory blocks GS0 through GS15 on the F2837x and through GS7 on the F2807x are accessible by CPU and DMA.
There are two types of message RAM blocks: CPU message RAM blocks and CLA message RAM blocks. The CPU message RAM blocks are used to share data between CPU1 subsystem and CPU2 subsystem in a dual-core device via inter-processor communications. The CLA message RAM blocks are used to share date between the CPU and CLA.
The user OTP is a one-time, programmable, memory block which contains device specific calibration data for the ADC, internal oscillators, and buffered DACs, in addition to settings used by the flash state machine for erase and program operations. Additionally, it contains locations for programming security settings, such as passwords for selectively securing memory blocks, configuring the standalone boot process, as well as selecting the boot-mode pins in case the factory-default pins cannot be used. This information is programmed into the dual code security module (DCSM). The flash memory is primarily used to store program code, but can also be used to store static data. Notice that the external memory interface is assigned a region within the memory map. The boot ROM and boot ROM vectors are located at the bottom of the memory map.
There are two types of message RAM blocks: CPU message RAM blocks and CLA message RAM blocks. The CPU message RAM blocks are used to share data between CPU1 subsystem and CPU2 subsystem in a dual-core device via inter-processor communications. The CLA message RAM blocks are used to share date between the CPU and CLA.
The user OTP is a one-time, programmable, memory block which contains device specific calibration data for the ADC, internal oscillators, and buffered DACs, in addition to settings used by the flash state machine for erase and program operations. Additionally, it contains locations for programming security settings, such as passwords for selectively securing memory blocks, configuring the standalone boot process, as well as selecting the boot-mode pins in case the factory-default pins cannot be used. This information is programmed into the dual code security module (DCSM). The flash memory is primarily used to store program code, but can also be used to store static data. Notice that the external memory interface is assigned a region within the memory map. The boot ROM and boot ROM vectors are located at the bottom of the memory map.
TMS320F2837xD Memory Map
| MEMORY | SIZE | START ADDRESS | END ADDRESS |
|---|---|---|---|
| M0 RAM | 1K × 16 | 0x0000 0000 | 0x0000 03FF |
| M1 RAM | 1K × 16 | 0x0000 0400 | 0x0000 07FF |
| PieVectTable | 512 × 16 | 0x0000 0D00 | 0x0000 0EFF |
| CPUx.CLA1 to CPUx | 128 × 16 | 0x0000 1480 | 0x0000 14FF |
| CPUx to CPUx.CLA1 | 128 × 16 | 0x0000 1500 | 0x0000 157F |
| UPP TX MSG RAM | 512 × 16 | 0x0000 6C00 | 0x0000 6DFF |
| UPP RX MSG RAM | 512 × 16 | 0x0000 6E00 | 0x0000 6FFF |
| LS0 RAM | 2K × 16 | 0x0000 8000 | 0x0000 87FF |
| LS1 RAM | 2K × 16 | 0x0000 8800 | 0x0000 8FFF |
| LS2 RAM | 2K × 16 | 0x0000 9000 | 0x0000 97FF |
| LS3 RAM | 2K × 16 | 0x0000 9800 | 0x0000 9FFF |
| LS4 RAM | 2K × 16 | 0x0000 A000 | 0x0000 A7FF |
| LS5 RAM | 2K × 16 | 0x0000 A800 | 0x0000 AFFF |
| D0 RAM | 2K × 16 | 0x0000 B000 | 0x0000 B7FF |
| D1 RAM | 2K × 16 | 0x0000 B800 | 0x0000 BFFF |
| GS0 RAM | 4K × 16 | 0x0000 C000 | 0x0000 CFFF |
| GS1 RAM | 4K × 16 | 0x0000 D000 | 0x0000 DFFF |
| GS2 RAM | 4K × 16 | 0x0000 E000 | 0x0000 EFFF |
| GS3 RAM | 4K × 16 | 0x0000 F000 | 0x0000 FFFF |
| GS4 RAM | 4K × 16 | 0x0001 0000 | 0x0001 0FFF |
| GS5 RAM | 4K × 16 | 0x0001 1000 | 0x0001 1FFF |
| GS6 RAM | 4K × 16 | 0x0001 2000 | 0x0001 2FFF |
| GS7 RAM | 4K × 16 | 0x0001 3000 | 0x0001 3FFF |
| GS8 RAM | 4K × 16 | 0x0001 4000 | 0x0001 4FFF |
| GS9 RAM | 4K × 16 | 0x0001 5000 | 0x0001 5FFF |
| GS10 RAM | 4K × 16 | 0x0001 6000 | 0x0001 6FFF |
| GS11 RAM | 4K × 16 | 0x0001 7000 | 0x0001 7FFF |
| GS12 RAM | 4K × 16 | 0x0001 8000 | 0x0001 8FFF |
| GS13 RAM | 4K × 16 | 0x0001 9000 | 0x0001 9FFF |
| GS14 RAM | 4K × 16 | 0x0001 A000 | 0x0001 AFFF |
| GS15 RAM | 4K × 16 | 0x0001 B000 | 0x0001 BFFF |
| CPU2 to CPU1 RAM | 1K × 16 | 0x0003 F800 | 0x0003 FBFF |
| CPU1 to CPU2 RAM | 1K × 16 | 0x0003 FC00 | 0x0003 FFFF |
| CAN A MSGRAM | 2K × 16 | 0x0004 9000 | 0x0004 97FF |
| CAN B MSGRAM | 2K × 16 | 0x0004 B000 | 0x0004 B7FF |
| Flash | 256K × 16 | 0x0008 0000 | 0x000B FFFF |
| Secure ROM | 32K × 16 | 0x003F 0000 | 0x003F 7FFF |
| Boot ROM | 32K × 16 | 0x003F 8000 | 0x003F FFBF |
| Vectors | 64 × 16 | 0x003F FFC0 | 0x003F FFFF |
TMS320C28x C/C++ COFF and EABI Data Types
Even though pointers are 32-bits, the compiler assumes that the addresses of global variables and functions are within 22-bits.
Even though pointers are 32-bits, the compiler assumes that the addresses of global variables and functions are within 22-bits.
- COFF: Common Object File Format
- EABI: Embedded Application Binary Interface
| COFF (Legacy) | EABI (Modern) | |
|---|---|---|
| char | 16 bits | 16 bits |
| enum | 16 bits | 16 bits |
| int | 16 bits | 16 bits |
| long | 32 bits | 32 bits |
| float | 32 bits | 32 bits |
| pointers | 32 bits | 32 bits |
| double | 32 bits | 64 bits |
| wchar_t | 16 bits (int) | 32 bits (long) |
TMS320F28x7x Linker Command File
Numerous modules are joined to form a complete program by using the linker. The linker efficiently allocates the resources available on the device to each module in the system. The linker uses a command (.CMD) file to identify the memory resources and placement of where the various sections within each module are to go. Outputs of the linking process includes the linked object file (.OUT), which runs on the device, and can include a .MAP file which identifies where each linked section is located.
There are many linker options but these four handle all of the basic needs
Numerous modules are joined to form a complete program by using the linker. The linker efficiently allocates the resources available on the device to each module in the system. The linker uses a command (.CMD) file to identify the memory resources and placement of where the various sections within each module are to go. Outputs of the linking process includes the linked object file (.OUT), which runs on the device, and can include a .MAP file which identifies where each linked section is located.
There are many linker options but these four handle all of the basic needs
- -o
specifies the output (executable) filename - -m
creates a map file. This file reports the linker’s results - -c tells the compiler to auto initialize your global and static variables
- -x tells the compiler to exhaustively read the libraries. Without this option libraries are searched only once, and therefore backwards references may not be resolved
Back to top of the page
