Part Number: TMS320F28P650DK
Other Parts Discussed in Thread: C2000WARE, , LAUNCHXL-F28P65X
**Title:** [F28P65x] C2000Ware 26.02 driverlib Debug build: Flash_initModule() calls Flash_writeTrims() from .text; and four documentation questions (errata prefetch advisory, MCUCNF1, RAM ECC vs parity)
**Software / documents:** C2000Ware 26.02.00.00, C2000 CGT 25.11.1.LTS (EABI), TRM SPRUIZ1B (revised August 2024), data sheet SPRSP69D (revised August 2025), silicon errata SPRZ545D (revised April 2025).
Hello,
While designing the memory map and linker command files for an F28P650DK product, we found the following. Paths are relative to the C2000Ware 26.02.00.00 root.
**1. driverlib Debug library: `Flash_initModule()` calls functions that are in `.text`, not `.TI.ramfunc`**
The TRM (section 12.1.4) says: "Software that configures Flash settings like wait-states, cache/prefetch features, and so on, must be executed only from RAM memory, not from Flash memory." `Flash_initModule()` is placed in `.TI.ramfunc` (`driverlib/f28p65x/driverlib/flash.c`, line 46), and `flash.h` lines 74-79 place six helper functions in `.TI.ramfunc` as well.
However, `Flash_writeTrims()` (`flash.h`, line 563) is `static inline` but has no `CODE_SECTION` pragma. The Debug library (`driverlib/ccs/Debug/driverlib.lib`) is built with `--opt_level=off`, so the inline functions are not expanded. We extracted `flash.obj` from the Debug library and checked its sections and relocations:
- `.TI.ramfunc:Flash_initModule` calls `Flash_writeTrims` (three times, `flash.c` lines 86, 92, 98), `Flash_isCtrlBaseValid`, `Flash_isECCBaseValid` and `__error__`.
- `Flash_writeTrims`, `Flash_isCtrlBaseValid` and `Flash_isECCBaseValid` are in `.text:` sections, so in a FLASH build they are executed from flash.
- In the Release library, `Flash_initModule` has no external calls (everything is inlined), so the Release library is not affected.
`Flash_writeTrims()` writes the TRIM registers at `FLASHCONFIG_BASE + 0x1600/0x1604/0x1608`. It is called after `Flash_setWaitstates()` and before cache/prefetch are re-enabled, so with the Debug library this flash configuration step runs from flash. The empty project template uses the Debug library in its FLASH configurations (`driverlib/f28p65x/examples/c28x/empty_projects/CCS/empty_driverlib_project.projectspec`, lines 18, 20 and 35).
Questions / suggestions:
- (a) Is executing `Flash_writeTrims()` from flash at this point safe? If not, could `#pragma CODE_SECTION(Flash_writeTrims, ".TI.ramfunc")` be added (and, for completeness, for `Flash_isCtrlBaseValid()` / `Flash_isECCBaseValid()`, which `Flash_initModule()` also calls)?
- (b) The TRIM registers (`TRIMCTL`, `TRIMLOCK`, `TRIMCOMMIT`) are not described in the TRM. From the boot ROM source in C2000Ware (`libraries/boot_rom/f28P65x/rev0/rom_sources/cpu1/F28P65x_ROM/bootROM/source/cpubrom_boot.c`, lines 1711 and 1783-1785) we see that the boot ROM sets `TRIMCTL.ENABLE` and locks the READ and OTHER trims, with the comment "Not comitting the READ and OTHER trims", and that `Flash_initModule()` then commits them. Could you explain what committing does, why it is left to the application, and whether it must be done from RAM?
**2. Errata SPRZ545D, "Memory: Prefetching Beyond Valid Memory"**
- (a) The text says that for flash "the prefetch queue is 16 x16 words in depth. Therefore, code should not come within 16 words of the end of valid memory", but Table 3-4 lists the flash addresses as `0x0011 FFF8–0x0011 FFFF`, which is only 8 words. Which is correct (we assume 16 words, `0x0011 FFF0–0x0011 FFFF`)?
- (b) Table 3-4 lists LS9 (`0x0002 5FF8–0x0002 5FFF`, CPU1). The C2000Ware 26.02 linker command files `device_support/f28p65x/common/cmd/28p65x_generic_ram_lnk_cpu1.cmd` and `28p65x_generic_flash_lnk_cpu1.cmd` reserve the end of M1 (lines 7-8) but define `RAMLS9` with the full length `0x002000` (line 27). With the default SECTIONS no code is placed in LS9, so there is no immediate problem, but users who add code to LS9 would not be protected. Should `RAMLS9` also be shortened by 8 words, like `RAMM1`?
- (c) When flash banks are split between the CPUs with `BANKMUXSEL`, is a bank allocated to the other CPU considered "valid memory" for this advisory? For example, if CPU1 code ends at the end of Bank 2 and Bank 3 is allocated to CPU2, should CPU1 leave the last 16 words of Bank 2 unused? (We currently do, to be safe.)
**3. TRM: `MCUCNF1` (D2-D5 allocation) is documented as read-only**
- Table 3-113 (section 3.18.11.8) shows `MSEL_D2` to `MSEL_D5` as type "R" with reset value "X". However, driverlib writes this register from CPU1 (`SysCtl_allocateDxRAM()`, `driverlib/f28p65x/driverlib/sysctl.h`, line 5355, and `SysCtl_lockDxRAMConfig()`, line 5377), and the dual-core example mentions it (`driverlib/f28p65x/examples/c28x_dual/dma/dma_ex1_shared_periph_cpu1.c`, lines 101-112). We assume the fields are writable from CPU1 until locked with `MCUCNFLOCK`. Could the TRM be corrected?
- What is the D2-D5 ownership after a power-on reset (CPU1 or CPU2), and does the boot ROM change it? The reset value "X" does not tell us.
- Minor: the register summary names `MCUCNF1` "MCU Configuration register for LockStep Feature", while Table 3-15 (section 3.16) describes it as "D2 - D5 CPU1/CPU2 memory allocation". The `BANKMUXSEL` description (section 3.18.11.6) contains the text "Internal note : This register is accessible (read-only) by CPU2, for devices with CPU2", which looks like an internal comment.
**4. RAM error detection: ECC or parity?**
The TRM says "All dedicated RAMs have the ECC feature" (section 3.12.1) and that LSx RAMs "have the ECC feature" (section 3.12.2). The data sheet memory map (SPRSP69D, Table 7-1) lists D0-D5, LS0-LS9 and GS0-GS4 as "Parity" (only M0/M1 as "ECC"). Which is correct? This matters to us for RAM initialization and for the diagnostic design.
Thank you.
