• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 336 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.

Basic Code Composer project for 5510a

philament
Prodigy 20 points
Other Parts Discussed in Thread: TMS320VC5510A

We have designed and embedded appliance that is using a TMS320VC5510A connected to the peripheral bus of the processor.  The DSP is configured to boot from EHPI.  We are currently using a Third party DSP image and download algorithm that is working.

What we would like to do though is create a DSP image that does production level testing of the external connections to the DSP.  After reading through mounds of  CCS documentation, bootloader documentation, chip documentation, we are still unable to come up with the most basic project that can test External RAM and/or toggle GPIO lines. We do not have a JTAG/USB downloader/debugger, which most documentation assumes, all transactions are done through the host port.

Is there an example project for this type of situation?

Having tried some of the DSK5510 examples, it seems that you have to define all Memory locations in a .cmd file, for custom hardware, do you have to create this file yourself? 

What is required to setup the External RAM (512Kx32x4banks 32-bit data bus) in code composer/hex55?

How do you control the HPI port in code after downloading the DSP image?

What exactly does “entry point” mean and how do you define it (ccs/hex55)?

 

Regards

 

  • 0
    TI__Expert 8065 points

    I am not sure if I understood your questions correctly. Fist of all, I highly recommend to use an emulator to debug your code. Without it, it would be very time consuming.

    - The .cmd file includes memory map informaiton and code allocation information. you can use the example .cmd file for your own project. Internal memory (RAM) should be the same, you just need to check your external memory map on your board and modify the .cmd file accordingly.

    - I don't understand "setup the external RAM in code composer/hex55". Do you want to use an exteranl SRAM? If then, you need to configure EMIF peripheral registers for the SRAM. It is not part of CCS or Hex55. It should be a part of your code. The EMIF user's Gudie would be the a good start point. http://focus.ti.com/lit/ug/spru590/spru590.pdf

    - For HPI, please review the HPI User's guide. http://focus.ti.com/lit/ug/spru588b/spru588b.pdf

    - "Entry point" is the address the bootloader jumps to after loading the boot-image. In other words, it is the starting address of your boot-image.

    In case you are new to the device, you may want to get a local assistance from our local TI office.

    Best Regards,

    Peter Chung

     

  • 0 in reply to Peter Chung
    Prodigy 20 points

    Thank you for the response. I guess I'm just getting confused with the few example projects I'm working with

    From the Bootloader reference guide SPRA763, on page 7, when outlining the algorithm for boothing through EHPI "After the RESET bit in the HPIC is set, the CPU tranfers executino to byte address 0x010000h and the loaded application begins".  To me, this means that somewhere in the code and/or linker you have to specify somehow exactly what is downloaded to 0x010000h, but I haven't seen that in any of the example linker cmd files.  It appears similar to this thread: http://e2e.ti.com/support/dsp/tms320c5000_power-efficient_dsps/f/109/p/11051/43035.aspx#43035, but in my case I'm not using DSP/BIOS because I'm trying to keep the POST tests as small as possible and I don't have a full grasp of what DSP/BIOS does for me.

    I have created a basic .cmd file to try to allow me to control what is linked to 0x010000 (SARAM), but I when I look at the .map file generated, I'm not sure exactly what I should see at 0x10000.

    -stack 0x2000 /* Primary stack size */

    -sysstack 0x1000 /* Secondary stack size */

    -heap 0x2000 /* Heap area size */

     

    -c /* Use C linking conventions: auto-init vars at runtime */

    -u _Reset /* Force load of reset interrupt handler */

     

    /* SPECIFY THE SYSTEM MEMORY MAP */

     

    MEMORY

    {

    PAGE 0: /* ---- Unified Program/Data Address Space ---- */

     

    MMR (RWIX): origin = 0x000000, length = 0x0000c0 /* Memory Mapped Registers */

    DARAM0 (RWIX): origin = 0x0000c0, length = 0x00ff40 /* 64KB - MMRs */

    SARAM0 (RWIX): origin = 0x010000, length = 0x010000 /* 64KB */

    SARAM1 (RWIX): origin = 0x020000, length = 0x020000 /* 128KB */

    SARAM2 (RWIX): origin = 0x040000, length = 0x010000 /* 64KB */

    ExtSDRAM0 (RWIX): origin = 0x050000, length = 0x200000 /* 2MB (2048 COL x 256 ROW x 4 Bank CE0*/

     

     

     

    PDROM (RIX): origin = 0xff8000, length = 0x008000 /* 32KB */

     

    PAGE 2: /* -------- 64K-word I/O Address Space -------- */

     

    IOPORT (RWI) : origin = 0x000000, length = 0x020000

    }

     

    /* SPECIFY THE SECTIONS ALLOCATION INTO MEMORY */

     

    SECTIONS

    {

    .text >> SARAM0 /* Code */

     

    /* Both stacks must be on same physical memory page */

    .stack > DARAM0 /* Primary system stack */

    .sysstack > DARAM0 /* Secondary system stack */

     

    .data >> DARAM0 /* Initialized vars */

    .bss >> DARAM0 /* Global & static vars */

    .const >> DARAM0 /* Constant data */

    .sysmem > DARAM0 /* Dynamic memory (malloc) */

    .switch > SARAM1 /* Switch statement tables */

    .cinit > SARAM1 /* Auto-initialization tables */

    .pinit > SARAM1 /* Initialization fn tables */

    .cio > SARAM1 /* C I/O buffers */

    .args > SARAM1 /* Arguments to main() */

     

    vectors: 0xffff00 /* Interrupt vectors */

    ------------------------------------------------------------------------------------------------------------------------------

    I just have one source file in the project (main.c) and it toggles a GPIO line, so I would have thought that at 0x10000 I would see a reference to _c_int00, but the map file (shown below) says that it's at 0x000100d6, am I just not understaing something basic simple?

    .text 0 00010000 [ 00008000 ] 00000137 *

    00010000 [ 00008000 ] 0000004d * rts55x.lib : autoinit.obj (.text)

    0001004d [ 00008026+] 0000004b * : args_main.obj (.text)

    00010098 [ 0000804c ] 0000003e * : exit.obj (.text)

    000100d6 [ 0000806b ] 00000034 * : boot.obj (.text)

    0001010a [ 00008085 ] 00000012 * : _lock.obj (.text)

    0001011c [ 0000808e ] 00000011 * main.obj (.text)

    0001012d [ 00008096+] 00000007 * rts55x.lib : exit.obj (.text:CIO_breakpoint)

    00010134 [ 0000809a ] 00000002 * : vectors.obj (.text)

    00010136 [ 0000809b ] 00000001 * --HOLE-- [fill = 20]

     

     

     

  • 0 in reply to philament
    TI__Genius 13045 points

    Philament,

    You need to force c_int00 to be located at address 0x10000.  I believe this E2E Forum post addresses this issue: http://e2e.ti.com/support/dsp/tms320c5000_power-efficient_dsps/f/109/p/11051/43035.aspx#43035.

    Regards.