• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 99 subscribers
  • Views 489 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.

Strange issue: code runs from internal memory (LL2) but not from external (DDR).

Stefanos A.
Prodigy 150 points
Other Parts Discussed in Thread: TMS320C6472

I have been trying to hunt down the cause of this strange issue for weeks, to no avail, so now I'm turning to the community for help. Maybe someone more experienced than me will have some idea!

Quick background: I am developing an application for a 6-core C6472 connected to 256MB of DDR2 memory. My board configuration is as follows:

L1P$ and L1D$: 32KB each (all L1 is cache)
LL2$: 0KB (all L2 is managed manually)
DDR2: 64MB
DDR2_CORE[0-5]: 32MB
The last 32MB are not used by anyone (contingency plan, in case we run out of memory at the end of the project.)

Each core has 2 heaps configured: one on its LL2 (128KB) and one on its own DDR2 region (4MB). I also configure shared region 0 on SL2 and instruct it to create a 320KB heap. Finally, IPC is configured with ProcSync_ALL.

On startup, I call Ipc_start() on each core - and that's it!

The problem:
If I load all image sections to LL2, then everything appears to be working correctly.
However, if I move all sections to DDR2, then the project fails with a "memory access took more than 100000 cycles" somewhere in a GateAAMonitor_asm file.

Please note that the image for each core is uploaded to a different 32MB region of DDR2 - there should be no overlap to cause corruption!

Here is a simple test case that reproduces the issu: 8284.test.zip

(On my complete project, and when run on actual hardware, I get severe corruption where the image of one core appears to corrupt the image of another core during load time (execution doesn't even reach main). On an emulator I get the same symptoms as this test case.)

Has anyone ever encountered this before? Does anything jump out as wrong in my cfg file? Or any other ideas on how to debug this?

  • 0
    TI__Mastermind 30825 points

    You need to configure the DDR2 memory controller prior to loading to DDR memory.

    Best Regards,
    Chad

  • 0 in reply to Chad Courtney
    Prodigy 150 points

    This makes sense, thanks. From studying spru894j (TMS320C6472/TMS320TCI648x DSP DDR2 Memory Controller User's Guide) and the MCSDK documentation, I need to run a platform-specific initialization function to setup the relevant PLLs. For instance, MCSDK offers a platform_init() function for the evm6472; my board provider also offers an init_PLL() function that appears to do this.

    Here is what I have tried to do:

    1. create an init_PLL() function that contains the initialization code
    2. use #pragma CODE_SECTION(init_PLL, ".board_init") to create a new section for this function
    3. in my .cfg file, ensure that ".board_init" is placed into LL2 (double-checked via the .map file)
    4. in my .cfg file, add xdc.useModule("xdc.runtime.Startup"); Startup.resetFxn = "&init_PLL"; to set the init_PLL function as the reset function.

    I have verified that the init_PLL() function is the first function that is executed on the master core - yet, I am still getting the same error!

    As far as I can tell, there are still two issues at play here:

    First, code is still being loaded to DDR before init_PLL() has any chance to run. Unfortunately, I cannot see how that could be avoided: my image is too big to fit inside LL2 (otherwise we wouldn't be having this discussion!) which means that a part of it *must* be loaded to external memory. Is it even possible to run code before loading this image?

    Second, while the initialization code is running on the master core (as indicated by the MCSDK docs), the other cores are also happily executing their own initialization functions - oblivious to the fact that DDR is still not configured! I'm pretty sure this is not good, but what would be the proper fix? (A busy loop would be prone to race conditions. I guess I might be able to set a flag on SL2 and check that, but without the IPC facilities this sounds rather fragile, too.)

    Please forgive the holes in my understanding - I am still a newbie to this stuff. :) I'd be grateful for any pointers!

  • 0 in reply to Stefanos A.
    TI__Guru* 84110 points

    Stefanos,

    Which boot mode do you use for your application?

    Regards,
    RandyP

  • 0 in reply to RandyP
    Prodigy 150 points

    Right now I am running the code via the CCS debugger, connected to a XDS560+ JTAG emulator. At some point I wish to be able to boot from NAND flash (but one thing at a time).

  • 0 in reply to Stefanos A.
    TI__Guru* 84110 points

    Stefanos,

    Your CCS Target Configuration should have a GEL file named as the initialization script for each of the 6 cores. If not, you can also load the GEL file for each core after launching the Target Configuration and before Connecting to the targets. Look for evmc6472.gel (core0) and evmc6472-MemoryMap.gel (other cores) in your MCSDK installation folder.

    The GEL file will take care of initializing your DDR and PLLs and everything else that needs to be prepared on the C6472 so it can accept and run your executable .out file.

    Regards,
    RandyP

  • 0 in reply to RandyP
    Prodigy 150 points

    Thanks, I just tested this and the issue is resolved!

    If I understand correctly, .gel files are only applied during debugging, correct? In other words, booting from flash would require a different solution. Is this covered in the Bootloader User's Guide or maybe some other document (or FAQ)?

    Thanks!

  • 0 in reply to Stefanos A.
    TI__Guru* 84110 points

    Stefanos,

    You have done excellent work getting your application running.

    Yes, GEL files are only used by CCS when an emulator is connected to the target system.

    Yes, when booting from Flash, you will require a different solution. You can look to the MCSDK for some examples and tools.

    Yes, the Bootloader User's Guide is the best place to start. Then look to the TI Wiki Pages for articles on booting and search this forum for other discussions of booting.

    Regards,
    RandyP