C542 CALLing to Different Section

You should no doubt force .vectors into INTR_TABLE; you really don't want it to go anywhere else, and you don't want anything else landing in INTR_TABLE.

SECTIONS {
        .vectors: > INTR_TABLE
}

Hmm, true, but it appears it was loading into INTR_TABLE anyway.  I still can't get anything to work properly.  I'm not even sure what I've screwed up at this point, it's just continuously rebooting (I can see it reading and re-reading my EPROM on scope).  The very first line in my core code is 'rsbx XF', and it isn't even doing that.  All interrupts vectors just branch to the core code, though clearly I never even get a chance to set IPTR to point at my vectors.  It's like it never even goes to my entry address.

I have noted one oddity--the doc SPRU102f, TMS320C54x Assembly Language Tools User’s Guide page 6-23 says that the linker's command file requires all addresses and sizes to be in bytes.  It seems to me that this is a lie: when I load my 128-word vector table to INTR_TABLE (origin 0x0080, length 0x0080) the linker map says it fits with no unused space.  ...?!

Here are my memory maps:

******************************************************************************
              TMS320C54x Linker PC v4.2.0                      
******************************************************************************
>> Linked Sun May 20 02:29:58 2012

OUTPUT FILE NAME:   <spectest.out>
ENTRY POINT SYMBOL: "RXDSP_START"  address: 00000100


MEMORY CONFIGURATION

         name            origin    length      used     unused   attr    fill
----------------------  --------  ---------  --------  --------  ----  --------
  INTR_TABLE            00000080   00000080  00000080  00000000  R IX
  PROG_MAIN             00000100   00000700  000006b5  0000004b  R IX
  SBUFFER               00000800   00000400  00000000  00000400  RW  
  PROG_MINI             00000c00   00000400  000001ed  00000213  R IX
  DATA                  00001000   00000800  00000000  00000800  RW  
  PROG                  00001800   00000f00  00000d2c  000001d4  R IX
  STACK                 00002700   00000100  00000000  00000100  RW  


SECTION ALLOCATION MAP

 output                                  attributes/
section   page    origin      length       input sections
--------  ----  ----------  ----------   ----------------
.vectors   0    00000080    00000080     
                  00000080    00000080     spectest.obj (.vectors)

.text      0    00000100    0000061d     
                  00000100    0000061d     spectest.obj (.text)

.log10_p   0    0000071d    0000005d     
                  0000071d    0000005d     log_10.obj (.log10_p)

.cbrev_p   0    0000077a    0000003b     
                  0000077a    0000003b     cbrev.obj (.cbrev_p)

.cfft_p    0    00000c00    000001ed     
                  00000c00    000001ed     cfft1024.obj (.cfft_p)

.smon_p    0    00001800    0000073f     
                  00001800    0000073f     serial_monitor.obj (.smon_p)

.sintab    0    00001f3f    000005ed     
                  00001f3f    000005ed     cfft1024.obj (.sintab)

********************************************************************************
TMS320C54x Hex Converter                                                  v4.2.0
********************************************************************************

INPUT FILE NAME: <spectest.out>
OUTPUT FORMAT:   Intel

PHYSICAL MEMORY PARAMETERS
   Default data width   :  16
   Default memory width :   8 (MS-->LS)
   Default output width :   8

BOOT LOADER PARAMETERS
   Table Address: 0x0000, PAGE 0
   Entry Point  : 0x0100


OUTPUT TRANSLATION MAP
--------------------------------------------------------------------------------
00000000..00003fff  Page=0  Memory Width=8  ROM Width=8  "EPROM1"
--------------------------------------------------------------------------------
   OUTPUT FILES: spectest.hex [b0..b7]

   CONTENTS: 00000000..00002cb9   BOOT TABLE
                         .vectors : dest=00000080  size=00000080  width=00000002
                            .text : dest=00000100  size=0000061d  width=00000002
                          .smon_p : dest=00001800  size=0000073f  width=00000002
                          .cfft_p : dest=00000c00  size=000001ed  width=00000002
                         .cbrev_p : dest=0000077a  size=0000003b  width=00000002
                         .log10_p : dest=0000071d  size=0000005d  width=00000002
                          .sintab : dest=00001f3f  size=000005ed  width=00000002
             00002cba..00003fff   FILL = 00000000

I'll also note that if I make up a test file with a single hex converter section .smon_p paddr=boot, it loads my monitor code just fine.  It's seems like it's something about having multiple sections and functions?  I don't know.  The docs explicitly state that named sections can contain executable code, what am I doing so wrong?

Micah Dombrowski said:

I have noted one oddity--the doc SPRU102f, TMS320C54x Assembly Language Tools User’s Guide page 6-23 says that the linker's command file requires all addresses and sizes to be in bytes.

Yes, that is an erratum.  I've submitted SDSCM00044089 so that this issue can get fixed.

Can you load your executable file onto the device in Code Composer Studio without going through the hex converter? Does it work?

You can certainly have code in multiple sections, we do it all the time.

I don't have fancy stuff like a working CCS or emulator.  We actually tried the XDS100v2, but apparently it doesn't support older 54x chips.  Meh.  My only way of testing is to burn to the EPROM and run it.  Fun times.

Anyway, I'm not sure I'm doing the boot loading right.  Most of the documentation seems to imply that the built-in bootloader can copy multiple sections into RAM, so I've just been running hex500 with the -boot option.  However, Example 3 of Appendix C in SPRU102f implies that you can only actually load one section (or "block"?) to RAM with the built-in bootloader?  Unless it's an LP chip?  Is this true?  Do I have to copy a bunch of sections manually from the EPROM?  I'm not even sure how to do that, I'm using parallel loading from an 8-bit EPROM.

I'm not even sure how to properly build a hex file for a single 8-bit EPROM with one section in the boot table, and the rest...not?  I just tried fiddling with it, but hex500 keeps complaining.  Blargh.

I'm sorry, but the hex converter and the C54x bootloader are outside of my area of expertise.  We'll need someone else to look over your hex converter usage.