• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 100 subscribers
  • Views 117 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

AM6422: Load Cortex R5 application into DDR memory via XDS110 Debug Probe

AM6442: Trouble running example projects from DDR instead of MSRAM (MCU+ SDK v10.01, CCS v12.8.1, XDS110 probe)

Dawn Foran
Prodigy 90 points
Part Number: AM6442

Tool/software:

I'm currently experimenting with the AM6442 EVM board using CCS. I'm trying to get an example project (FreeRTOS based) from the MCU+ SDK v10.01, which I've enhanced, to run from DDR on the R5F0_1 Core as I've exceeded the MSRAM space. The project builds fine, but when I load it to the Core in the XDS110 Debug interface I get nothing. The program is in run state, breakpoints dont hit, when I suspend it is stuck in a prefetch_abort_addr call in HwiP_armv7r_vectors_freertos_asm: 

So far in my research I followed the SoC Peripheral Drivers --> DDR part of the SDK help files to create and load the board_ddrReginit.h file, but haven't found anything else specific which is helping.

Any help on this matter would be greatly appreciated, my syscfg and linker information is as follows: 

syscfg settings related to DDR:

The Memory Summary shows:

My modifications to the Memory Configurator->Section result in the following in my linker.cmd file:

SECTIONS
{
    .vectors  : {
    } > R5F_VECS   , palign(8) 


    GROUP  :   {
    .text.hwi : {
    } palign(8)
    .text.cache : {
    } palign(8)
    .text.mpu : {
    } palign(8)
    .text:abort : {
    } palign(8)
    } > DDR_5RF01  


    GROUP  :   {
    .text : {
    } palign(8)
    .rodata : {
    } palign(8)
    } > DDR_5RF01  


    GROUP  :   {
    .data : {
    } palign(8)
    } > DDR_5RF01  


    GROUP  :   {
    .bss : {
    } palign(8)
    RUN_START(__BSS_START)
    RUN_END(__BSS_END)
    .sysmem : {
    } palign(8)
    .stack : {
    } palign(8)
    } > DDR_5RF01  


    GROUP  :   {
    .irqstack : {
        . = . + __IRQ_STACK_SIZE;
    } align(8)
    RUN_START(__IRQ_STACK_START)
    RUN_END(__IRQ_STACK_END)
    .fiqstack : {
        . = . + __FIQ_STACK_SIZE;
    } align(8)
    RUN_START(__FIQ_STACK_START)
    RUN_END(__FIQ_STACK_END)
    .svcstack : {
        . = . + __SVC_STACK_SIZE;
    } align(8)
    RUN_START(__SVC_STACK_START)
    RUN_END(__SVC_STACK_END)
    .abortstack : {
        . = . + __ABORT_STACK_SIZE;
    } align(8)
    RUN_START(__ABORT_STACK_START)
    RUN_END(__ABORT_STACK_END)
    .undefinedstack : {
        . = . + __UNDEFINED_STACK_SIZE;
    } align(8)
    RUN_START(__UNDEFINED_STACK_START)
    RUN_END(__UNDEFINED_STACK_END)
    } > MSRAM  


    GROUP  :   {
    .ARM.exidx : {
    } palign(8)
    .init_array : {
    } palign(8)
    .fini_array : {
    } palign(8)
    .text.boot : {
    } palign(8)
    } > MSRAM  

    .bss.user_shared_mem (NOLOAD) : {
    } > USER_SHM_MEM    

    .bss.log_shared_mem (NOLOAD) : {
    } > LOG_SHM_MEM    

    .bss.ipc_vring_mem (NOLOAD) : {
    } > RTOS_NORTOS_IPC_SHM_MEM    

    .bss.nocache (NOLOAD) : {
    } > MSRAM    
}


MEMORY
{
    R5F_VECS   : ORIGIN = 0x0 , LENGTH = 0x40 
    R5F_TCMA   : ORIGIN = 0x40 , LENGTH = 0x7FC0 
    R5F_TCMB0   : ORIGIN = 0x41010000 , LENGTH = 0x8000 
    NON_CACHE_MEM   : ORIGIN = 0x70040000 , LENGTH = 0x8000 
    MSRAM   : ORIGIN = 0x70000000 , LENGTH = 0x40000 
    USER_SHM_MEM   : ORIGIN = 0x70050000 , LENGTH = 0x4000 
    LOG_SHM_MEM   : ORIGIN = 0x70054000 , LENGTH = 0x4000 
    RTOS_NORTOS_IPC_SHM_MEM   : ORIGIN = 0x70048000 , LENGTH = 0x8000 
    FLASH   : ORIGIN = 0x60180000 , LENGTH = 0x80000 
    DDR_5RF01   : ORIGIN = 0x80000000 , LENGTH = 0x800000 
}

  • 0
    Prodigy 90 points

    Forgot to add: after I've loaded the program via the XDS110 probe, I used the memory browser to view the DDR space and all I see are "????" in the viewer.

    Also, running the program entirely from MSRAM has no problems at all, so I'm confident that my overall setup for my EVM board is functional.

    Thanks again!

  • 0 in reply to Dawn Foran
    TI__Guru* 86180 points

    If you are seeing "????", it appears the DDR is not getting initialized.  Are you running any boot code before loading the application?  Is there a DDR_Init() function that is getting executed somewhere?  You may want to see if the memory is accessible after that function, if not, need to do some debugging

    Regards,

    James

  • 0 in reply to JJD
    Prodigy 90 points

    Hi James,

    Thanks for the reply. I'm not calling it explicitly from my code, but I see that it is being called within the ti_drivers_config.c->System_Init() which is the first call in my main(), and it is using the gDdrParams struct that was generated by the online Ti tool and resides within the board_ddrReginit.h file.

    Answering your reply made me realize that yes, I do have a program loaded to the board which automatically boots in OSPI mode, I hadn't considered that this could possibly interfere with what I was loading to the r5f01 in CCS, so I reflashed the board with the default_sbl_null.cfg. Unfortunately didn't help.

    I have the EVM set to OSPI boot mode, I power on the board -> launch target configuration -> connect to r5f01 -> issue CPU reset -> load my .out file

    I notice that when I load the .out file, I see "MAIN_Cortex_R5_0_1: GEL Output: CPU reset (soft reset) has been issued through GEL." in the Console window in CCS.

    The r5f01 core goes into running state and I get no other feedback. When I hit suspend, it's at that prefetch_abort_addr line.

    also note, I put a breakpoint at the first call within my main() (which is the call to system_init()) and it never arrives there.

    While the Core is in running state, I see it's not just DDR memory which isn't initialized, it appears nothing is. MSRAM, R5F_VECS, R5F_TCMA, etc, everything is "????"

    Incase it matters, for this project I started from the "empty_am64x-evm_r5fss0-1_freertos_ti-arm-clang" project, and added the code from one of the gpio projects (toggle the TEST_LED1) as well as an IPC_spinlock shared memory example project. 

    open to any suggestions!

  • 0 in reply to Dawn Foran
    TI__Guru* 86180 points

    Hi Dawn, let me get someone who works with these projects more often.  SBL_null may be doing some init which is in conflict with the application init.

    Regards,

    James

  • 0 in reply to JJD
    Prodigy 90 points

    Thanks a lot James, appreciate it!

  • 0 in reply to Dawn Foran
    Prodigy 90 points

    Hi James,

    I had a good learning / debugging session with Stuart and managed to find the issue!. Posting here to help future people who may stumble across this one day.

    First off, I realize that my memory browser was showing "????" for memory spaces because I wasn't in a suspended state while looking, my oversight completely.

    Next, while debugging, we discovered that all of the MPU functions (starting with MPU_init()) were loaded into DDR, which creates the problem because DDR needs to be fully setup with the MPU before we can access it. 

    In examining all of my memory sections closely, I realize that the .text.mpu output section was pointing to DDR space, I modified this region to be loaded into MSRAM space and I could get my actual code to run out of DDR space

    Now when I breakpoint in main(), I can verify that my actual code is properly loaded in DDR space.

    Of course now it's crashing in new and exciting ways, but at least we're past the hump of getting code running from DDR space :).

    Thanks for your time, and hope this helps someone in the future!