• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 97 subscribers
  • Views 1224 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.

Boot sequence, DSP/BIOS 6

Mark Takatz
Intellectual 360 points

I'm getting close to booting from FLASH but one problem stands in my way.  I'm using DSP/BIOS v6.21, CCS v4.1, and XDC v3.16.  I have my own platform built, though it is actually on an ezdsp28335 board.

The default boot sequence calls functionality from boot_cg.asm to initialize the CPU and copy a few sections based on some symbols defined, presumably, in the user linker command file.  With Dave Russo's help, I have successfully extended the template linker command file (linker.cmd) to include load and run statements, as well as my own symbols for section start and size, e.g., _text_loadstart, _text_size, etc.  However, I intend to use Tim Love's boot code example to copy the sections over to RAM from FLASH and I have targeted the standard "codestart" application to 0x33FFF6 in memory, which holds the boot to flash vector.  This vector is mapped properly to my boot code.

The problem arises with the location of boot_cg's functionality.  The library address to boot.a28FP is forced into the reset vector at 0x3FFFC0 through myriad configuration calls that I have been unable to trace.  I don't mind the code on my build (it is small), but I cannot get the CPU to fetch the boot to flash vector nor can I place my code address in the reset location when I'm connected to the board through the USB emulator.  I would imagine that if I ran from a standalone (no emulator) it would work properly, but I'm not ready to do that as I need the debug capability to verify the copy operations are working properly.

Is there a way to override the .reset vector value?  If not, what do I have to do to re-build the target library in ${XDC_INSTALL}\packages\ti\targets\rts2800 using my own assembly code for the copy functions (as well as XINTF enables)?

Thanks,

Mark Takatz

  • 0
    TI__Expert 4125 points

    Sorry, I cannot answer the "reset vector" question, but ...

    Rebuilding the xdc.runtime packages is documented here: http://rtsc.eclipse.org/docs-tip/Working_with_xdc.runtime

    Mark

  • 0 in reply to MarkGrosen
    Intellectual 360 points

    Thanks.  I actually resolved the reset vector problem: the ezdsp data sheet appears to be incorrect regarding the direction of the switch settings.

    Mark Takatz

  • 0 in reply to MarkGrosen
    Intellectual 360 points

    Um, problem with this answer: the targets definitions (rts2800 in my case) do not contain a config.bld script and thus I get this warning:

    Warning: no config.bld file was found along the package path.  The config.bld file specifies the location of the compiler tool-chains required to compile runtime content.  Without this file, the XDC tools assume no targets are to be used.

    and the libraries do not update.

    Thoughts?

    Mark

  • 0 in reply to Mark Takatz
    Intellectual 360 points

    Never mind, I figured it out.  I created a config.bld script in the target directory (not the best way, but it was the quickest) that contains:

    var tools = java.lang.System.getenv("TI_DIR");

    var Build = xdc.module("xdc.bld.BuildEnvironment");

    var C28_float = xdc.module("ti.targets.C28_float");

    C28_float.rootDir = tools + "/tools/compiler/c2000";

    Build.targets = [C28_float];

    Now I can customize the boot_cg.asm file to do what I need.

    Mark

  • 0 in reply to Mark Takatz
    TI__Expert 4125 points

    Mark,

    Dave added a section to the page I cited earlier to make it clear(er) how to add a config.bld, which you figured out yourself. Hopefully, this will help the next guy. Thanks for researching this yourself and solving the problem.

    http://rtsc.eclipse.org/docs-tip/Working_with_xdc.runtime#Setup_for_xdc_builds

    Mark

  • 0 in reply to MarkGrosen
    Intellectual 360 points

    Thanks.

    I'm now at the point at which I can boot to FLAH and begin to copy my sections to various RAM locations.  I have yet to verify the copy operation, however, though I'm confident I'm over the cusp on the problem.

    At some point I'll need to create my own platform and target overrides (I'm rec-compiling existing code now) but I'll post the results when I get done.

    Mark