9.4. XIP Using Dummy App¶

9.4.2.1. Normal Mode v/s XIP Mode¶

From a SPI protocol perspective, a READ command is composed of three phases: instruction opcode, address and data. XIP mode requires only an address (no instruction) to output data, improving random access time and eliminating the need to shadow code onto RAM for fast execution.

9.4.4.1. Section Placement¶

Attributes: r-x or r– => Load & Run in Flash Attributes: rw-, Init Length: 0 => Load & Run from RAM + Designate “noload” in .bin file Attributes: rw-, Init Length: nonzero => Load in Flash & Run from RAM

Reasons to have separate Load & Run sections 1. To restrict all write accesses to RAM. 2. To have the a tight binary which loads only from RAM.

The graphic below delineates the various section configurations appropriate for different applications.

9.4.4.2. Linker File Usage¶

NOTE: The “entry point” must be set as the (OSPI_base_address + Bin file offset) - e.g. 0x501C0000 for J721E

The graphic below illustrates the bit translation and the memory section placement performed by the linker file.

...
...

--entry_point=_resetvectors

...
...


MEMORY
{
    ...
    ...

    XIP_FLASH_VECS (X)      : origin=0x501c0000 length=0x40
    XIP_FLASH               : origin=0x501c0040 length=0x5C000 - 0x40
    MSMC3_H (RWIX)          : origin=0x70100000 length=0xE2000               /* 1MB -56K */
    OCMRAM  (RWIX)          : origin=0x41C60000 length=0x20000 - 0x1000      /* ~124KB */

    ...
    ...
}

SECTIONS
{
    ...
    ...

    .rstvectors    : {} palign(8)      > XIP_FLASH_VECS
    .text_fast  : {
                    *ti.board*aer5f(.text)
                    *ti.csl*aer5f(.text)
                    *ti.drv*aer5f(.text)
                    *ti.osal.aer5f(.text)
                    *ti.transport*aer5f(.text)
                    *sciclient.aer5f*(.text)
                    *(.text:ti_sysbios_family_arm_v7r_keystone3_Hwi*)
                } palign(8)  load = XIP_FLASH, run = OCMRAM, table(_text_fast_section)

    .text_fast2  : {
                    *profinet_slave_stack_RT_MRP_AM65xx_r5f.lib*(.text)
                } palign(8)  load = XIP_FLASH , run = MSMC3_H, table(_text_fast2_section)

    .text_fast3  : {
                    iPNDrv.obj(.text)
                    iPNLegacy.obj(.text)
                    iPNOs.obj(.text)
                    iPtcpDrv.obj(.text)
                    iRtcDrv.obj(.text)
                    iRtcDrv2.obj(.text)
                    *P_tirtos.obj(.text)
                } palign(8)  load = XIP_FLASH , run = OCMRAM_LOW, table(_text_fast3_section)

    /* This is the region which will have all the copy tables */
    .ovly       : {} palign(128)  load = XIP_FLASH

    ...
    ...
}

/* Needed for copy_in() function */
#include <cpy_tbl.h>

/* extern all the table sections */
extern COPY_TABLE _text_fast_section;
extern COPY_TABLE _text_fast2_section;
extern COPY_TABLE _text_fast3_section;

int main(void)
{
    /* First thing in main - copies by looking at entries from the table _text_fast_section */
    copy_in(&_text_fast_section);
    /* First thing in main - copies by looking at entries from the table _text_fast2_section */
    copy_in(&_text_fast2_section);
    /* First thing in main - copies by looking at entries from the table _text_fast3_section */
    copy_in(&_text_fast3_section);

    :
    :
    /* Rest of the body */
}

9.4.4.3. Map File Usage¶

• Build your application normally (non-xip) and then look at the attributes of different sections.
• Section attributes (R/W/X) tell you exactly what sections can be placed where.

9.4.4.4. How To Flash¶

9.4.4.5. Debug Care Abouts¶

• Always use HW breakpoints

  • Putting a breakpoint in CCS will need to write a BKP instruction and writing to FLASH will cause a crash or the breakpoint will not be activated
  • Sometimes SW breakpoints might work as the code might be in cache
  • Note that there is a limit to the number of HW breakpoints one can set. Essentially the HW breakpoint is writing to some R5F register saying that halt if this address comes. Such registers are limited and hence the number of HW breakpoints.

• Cache needs to be always ON

  • OSPI controller in XIP mode can only do burst accesses and no Byte accesses and hence if there is a char constant (1 Byte) the behavior will be uncertain, but if we have cache in between then it’ll bring in 1 Cache line and hence solve the issue.

• Disable few options in Program/Memory Load Options

  • Software breakpoints are not allowed. But in Program/Memory Load Options for the core (Right clock on core on Debug view→ Open GEL files view → Program/Memory Load Options), few defaults options need software breakpoints. They need to be disabled, otherwise you might see an error while loading symbols for debugging.
  • Uncheck the following:
  • “Halt at program exit for TI compilers (requires a breakpoint)”
  • “Enable CIO function use (requires setting a breakpoint)”

9.4.4.6. CSL startup code¶

Declare a structure “const CSL_ArmR5MpuRegionCfg gCslR5MpuCfg[CSL_ARM_R5F_MPU_REGIONS_MAX] ” to override the default structure present in csl/arch/r5/startup.c . This structure must have the OSPI memory region declared, mark it as cacheable and executable. The linker file must place the “entry point” as “reset vectors” which must be at the bin file location in flash

E2E Thread: https://e2e.ti.com/support/processors/f/791/p/885969/3293718