This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

LP-AM263: Boot-Time Copy Tables not initialized when application is booted through QSPI SBL

Part Number: LP-AM263

Hi, I'm hitting a problem where it appears that boot-time copy tables are not processed when the application boots through the QSPI SBL. If I load the application image through the JTAG debug port, then the copy tables are processed.

I have a minimal project that reproduces this issue that I can deliver as a .zip on request. I'm having difficulty sharing the entire example through the forum.

The example is based on the hello_world nortos example with two main changes.

First, I change hello_world.c to print a data string stored in a special program section allocated in RAM instead of a fixed string:

    // Initialize some data in a special .data.test section
    __attribute__((section(".data.test")))
    static char data_section_string[] = "Hello World from .data.test!";

    // ...

    DebugP_log("[%s]\r\n", data_section_string);

Second I change linker.cmd to declare the .data.test section with a boot time copy table. I set up the load and run locations for this section to point to different addresses in OCRAM to keep the example simple.

SECTIONS
{
    .binit > OCRAM
    /* This is my special section that's initialized by a boot-time copy table */
    GROUP: load = OCRAM1, run = OCRAM, table(BINIT) {
        .data.test:   {} palign(8)
    }
...
}

Memory
{
   ...
    OCRAM     : ORIGIN = 0x70040000 , LENGTH = 0x40000
    OCRAM1    : ORIGIN = 0x70140000 , LENGTH = 0x40000
}

I expect __TI_auto_init() to initialize the .data.test section on boot in any case, but when I load the application from the QSPI SBL packaged with MCU+SDK, I see the following output which shows that this data was not initialized.

Image loading done, switching to application ...
[]

I'm using LP-AM263 hardware, tiarmclang v3.2.0 and MCU+SDK 9.0.0.35

Thanks for taking a look