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.

Can't access DDR memory (0x8000_0000) on TMDSSK3358

Other Parts Discussed in Thread: AM3358

I have been trying to load, single step and execute the UART echo example in the StarterWare package.  I am using the TI TMDSSK3358 board and CCS Version: 5.3.0.00090 .  

The problem I am having is this: 

CortxA8: Trouble Setting Breakpoint with the Action "Finish Auto Run" at 0x80002244: (Error -1066 @ 0x333C) Unable to set requested breakpoint in memory. Verify that the breakpoint address is in writable memory. (Emulation package 5.1.45.0)

I can see that even after running the GEL initialization file I cannot physically write to any memory at 0x8000_0000 .  According to my linker script, this is where the program will load.  I have tried just about every GEL initialization file from both the ccs_base directory as well as the StarterWare/tools.... directory.  None of them fix the problem.  I have searched this forum and TI for an answer and cannot find one.  I have tried everything (I think).   I can see the boot memory and other areas, but the DDR3 memory at 0x8000_0000 shows the symbols of where the code SHOULD be, but the memory is 'offline' .   I think that if I can read/write this memory area, the breakpoint issue above should be solved. 


Any help is greatly appreciated. 

Kind regards, 

Paul

  • Update

    If I first load the bootloader image and then load my application, everything works fine.  I thought the GEL file was supposed to take the place of the BL and set up the hardware correctly.  Or am I missing something. 

    -Paul

  • Hello Paul,

    You are right in saying that the GEL file replaces the Bootloader in functionality.

    Make sure you are using the most recent StarterWare release package, that is, 02.00.00.07.

    Since TMDSSK3358 uses DDR3, a GEL file in the release package meant for it should be used. Depending on the revision of your board (Rev. 1.1 or Rev. 1.2), use the appropriate GEL file present in the path ‘tools/gel/’ in the package. No other GEL files in the package can be used since they are either for EVM or Beaglebone which uses DDR2.

    In general, if a memory is not clocked, then it is not possible to write to it or apply breakpoint. I suspect that DDR3 is not getting its clocks in your experiment. Thus CCS is not permitting to apply breakpoint in that memory area.

    Do revert for any query.

     

    Thanks and Regards.

    Gurudutt

  • Good morning,

    I have the same problem, the difference is that I see the application symbols at 0x8000_0000 address but after some time ( like several seconds ) the memory begin to be corrupted, it show me 0x0000_0000 value at random addresses.


    If I run linux or other distribution or I use a bootloader to charge the application everything is OK.

    I tried all gel files from latest StarterWare and ti, nothing help me, I am unable to debug applications.

    I have Rev 1.2D .

  • Iulian,

    What is your Starterware version? Also, you are using the AM335x Starter Kit EVM? Is this your custom hardware?

    Lali
  • Hardware: TMDSSK3358 Rev 1.2 D
    StarterWare gel: 02_00_01_01.
  • Iulian,

    I'm unable to observe the behaviour you are describing. What is the GEL version you are using? The one that's running on my SK is located at C:\ti\ccsv6\ccs_base\emulation\boards\sk_am3358\gel\AM3358_StarterKit.gel

    Lali

  • I use the same gel file, I attached some print screens.

  • I solve the problem:

    To initiate GPIO ports I use this function:

    /*#####################################################*/
    void _gpio_init(unsigned int GpioModuleNr)
    {
    unsigned int BaseAddr = 0;
    switch (GpioModuleNr)
    {
    case 0:
    BaseAddr = GPIO0_addr;
    break;
    case 1:
    BaseAddr = GPIO1_addr;
    break;
    case 2:
    BaseAddr = GPIO2_addr;
    break;
    case 3:
    BaseAddr = GPIO3_addr;
    break;
    }
    GPIOModuleClkConfig(GpioModuleNr);
    GPIOModuleReset(BaseAddr);
    GPIOModuleEnable(BaseAddr);
    }

    But for some reason this function: GPIOModuleReset(BaseAddr); is the rason of this issue.

    This function is created when I use an older StarterWare and GCC, but now generate this issue.