• State Resolved
  • Locked Locked
  • Replies 9 replies
  • 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.

Linking problems with TMS320C6701

tbriseb
Intellectual 355 points

Hi there,

My original problem is that my code section is nearing the 64Kbyte mark. I'm trying to add some code that is about 160 bytes and the linker complains. When I review the map file, I see that there is room for the sysinit section but the problem is that the hwi_vec section leaves a large gap between itself and the bios section. the linker then tries to place the sysinit section next but the 64K mark is exceeded. I looked at the cmd file and it has the following:

 

        .hwi_vec: {

            HWI_A_VECS = .;

            *(.hwi_vec)

        } align = 0x400 > CODE_ROM

 

I do not remember why the 0x400 value was used. It was provided by Tim Harron (SR #1-629511745, Aug 18/09 email attachment, in the bootcfg.cmd file).  Can it be made smaller? Or could I add something to the cmd file so that the sysinit section follows the bios section? That may allow the hwi_vec to leave a gap but still fit.

 

Here is the map file before I add my code:

 

.text 0 00003000 00009fc0 00003000 000013c0 tcdplsrcnt.obj (.text) 000043c0 000013c0 tcdpsendxxxmsg.obj (.text) 00005780 00000ee0 tcdpeeprom.obj (.text) 00006660 00000ba0 tcdpfpga.obj (.text) 00007200 00000ae0 tcdprxdac.obj (.text) 00007ce0 00000900 tcdpprcscmd.obj (.text) 000085e0 00000780 tcdpisr.obj (.text) 00008d60 00000720 tcdpeeputil.obj (.text) 00009480 00000700 tcdplaser.obj (.text) 00009b80 000006e0 tcdpuart.obj (.text) 0000a260 00000600 tcdpmsghandler.obj (.text) 0000a860 00000500 tcdpmain.obj (.text) 0000ad60 000004e0 tcdputil.obj (.text) 0000b240 00000380 tcdptimer.obj (.text) 0000b5c0 00000320 rts6700.lib : frcdivd.obj (.text:__frcdivd) 0000b8e0 00000280 : divd.obj (.text:__divd) 0000bb60 00000240 : log.obj (.text:_log) 0000bda0 00000240 : memcpy62.obj (.text:_memcpy) 0000bfe0 000001a0 : divf.obj (.text:__divf) 0000c180 00000160 csl6701.lib : csl_timer.obj (.text:_TIMER_open) 0000c2e0 00000160 : csl.obj (.text:__CSL_init) 0000c440 00000160 rts6700.lib : frexp.obj (.text:_frexp) 0000c5a0 00000120 csl6701.lib : csl_timer.obj (.text:_TIMER_reset) 0000c6c0 00000120 : csl_irq.obj (.text:_mux2Tables) 0000c7e0 00000100 rts6700.lib : frcdivf.obj (.text:__frcdivf) 0000c8e0 000000e0 : modf.obj (.text:_modf) 0000c9c0 000000c0 : fixfu.obj (.text:__fixfu) 0000ca80 000000c0 csl6701.lib : csl_irq.obj (.text:_getMux) 0000cb40 00000080 : csl_emif.obj (.text:_EMIF_config) 0000cbc0 00000080 : csl_timer.obj (.text:_TIMER_close) 0000cc40 00000080 : csl_irq.obj (.text:__IRQ_init) 0000ccc0 00000060 tcdpdelay.obj (.text) 0000cd20 00000060 csl6701.lib : csl_timer.obj (.text:_TIMER_config) 0000cd80 00000060 rts6700.lib : ceil.obj (.text:_ceil) 0000cde0 00000040 csl6701.lib : csl_irq.obj (.text:_IRQ_enable) 0000ce20 00000040 : csl_irq.obj (.text:_IRQ_resetAll) 0000ce60 00000040 : csl_timer.obj (.text:_TIMER_start) 0000cea0 00000040 ErtSwcfg_csl.obj (.text:cslCfgInit) 0000cee0 00000020 csl6701.lib : csl_irq.obj (.text) 0000cf00 00000020 : csl.obj (.text:_CSL6701_LIB_) 0000cf20 00000020 : csl_irq.obj (.text:_IRQ_globalDisable) 0000cf40 00000020 : csl_irq.obj (.text:_IRQ_globalEnable) 0000cf60 00000020 rts6700.lib : _lock.obj (.text:__nop) 0000cf80 00000020 : _lock.obj (.text:__register_lock) 0000cfa0 00000020 : _lock.obj (.text:__register_unlock) .bios 0 0000cfc0 000027e0 0000cfc0 00000520 bios.a67 : swi.o67 (.bios) 0000d4e0 00000440 : hwi_disp_asm.o67 (.bios) 0000d920 000002c0 : sem_pend.o67 (.bios) 0000dbe0 000002a0 : knl_run.o67 (.bios) 0000de80 00000260 : knl_tick.o67 (.bios) 0000e0e0 00000200 : sem_dopo.o67 (.bios) 0000e2e0 00000200 : tsk_setu.o67 (.bios) 0000e4e0 000001c0 : knl_swit.o67 (.bios) 0000e6a0 000001c0 biosC6000.a67 : clk.o67 (.bios) 0000e860 000001a0 bios.a67 : tsk_exit.o67 (.bios) 0000ea00 00000180 : autoinit.o67 (.bios) 0000eb80 00000140 : tsk_stup.o67 (.bios) 0000ecc0 00000140 : knl_chec.o67 (.bios) 0000ee00 000000e0 : knl_exit.o67 (.bios) 0000eee0 000000e0 : sem_post_asm.o67 (.bios) 0000efc0 000000e0 : sem_post.o67 (.bios) 0000f0a0 000000c0 : knl_post.o67 (.bios) 0000f160 000000c0 : lck.o67 (.bios) 0000f220 000000c0 : sys_exit.o67 (.bios) 0000f2e0 000000c0 : knl_ipos.o67 (.bios) 0000f3a0 00000080 : sts.o67 (.bios) 0000f420 00000080 : fxn.o67 (.bios) 0000f4a0 00000080 : log.o67 (.bios) 0000f520 00000060 : utl_putc.o67 (.bios) 0000f580 00000060 : sys_abor.o67 (.bios) 0000f5e0 00000060 : sem_pend_counting.o67 (.bios) 0000f640 00000060 : hwi_c.o67 (.bios) 0000f6a0 00000040 : utl_doab.o67 (.bios) 0000f6e0 00000020 : gbl_vers.o67 (.bios) 0000f700 00000020 : utl_doer.o67 (.bios) 0000f720 00000020 : sts_set.o67 (.bios) 0000f740 00000020 : fxn_c.o67 (.bios) 0000f760 00000020 : idl.o67 (.bios) 0000f780 00000020 : utl_halt.o67 (.bios) .hwi_vec 0 0000f800 00000200 0000f800 00000200 ErtSwcfg.obj (.hwi_vec) .sysinit 0 0000fa00 00000420 0000fa00 000001e0 ErtSwcfg.obj (.sysinit) 0000fbe0 000000e0 bios.a67 : mem_init.o67 (.sysinit) 0000fcc0 000000c0 : boot.o67 (.sysinit) 0000fd80 00000080 : tsk_init.o67 (.sysinit) 0000fe00 00000020 : obj_init.o67 (.sysinit)

  • 0
    TI__Guru 62975 points

    I don't think it is safe to make the HWI Vector Table section smaller.  If you refer to the ROM/Vector Table app note ( www.ti.com/litv/pdf/spra544d ), it says that there are 32 vectors, with each vector allocated 32 bytes in the table.  32 vectors x 32 bytes = 1024 bytes = 0x400h

    -Tommy

  • 0 in reply to tlee
    Intellectual 405 points

    my bad. should have been more specific.

            .hwi_vec: {

                HWI_A_VECS = .;

                *(.hwi_vec)

            } align = 0x400 > CODE_ROM

     Are you saying that the "align" directive is the same as saying the size of the section should be 0x400?

    That is not my understanding. I think it means align the section on addresses 0x000, 0x400, 0x800, 0xc00. So that the LS 10 bits of the address field are zeroes. So my query was, can the alignment be made any smaller?

    Thx, Bill.

  • 0 in reply to willshad
    TI__Guru 62975 points

    Bill,

    I agree with your understanding of align.  You should be able to reduce the alignment size as long as the table falls into the expected address range.

    -Tommy

  • 0 in reply to tlee
    Intellectual 405 points

    The command file "cfg.cmd" that has the following expressions was generated by the configuration tool. I can not modify this file. I cannot find a spot in the configuration editor to change this parameter either. Any ideas?

            .hwi_vec: {

                HWI_A_VECS = .;

                *(.hwi_vec)

            } align = 0x400 > CODE_ROM

  • 0 in reply to willshad
    TI__Guru 62975 points

    Hm.  I'm not too sure about that.  Can you post this question in the Embedded Software -> BIOS forum?  They will be more familiar with how to modify the configuration settings.

    -Tommy

  • 0 in reply to willshad
    TI__Mastermind 18130 points

    willshad said:
     Are you saying that the "align" directive is the same as saying the size of the section should be 0x400?
    That is not my understanding. I think it means align the section on addresses 0x000, 0x400, 0x800, 0xc00. So that the LS 10 bits of the address field are zeroes. So my query was, can the alignment be made any smaller?

    No they are not the same, and no this alignment cannot be made smaller. The size of the section is determined by the compiler, and the alignment does indeed specify to the linker that it must start at a 0x400 boundary (0x000, 0x400, etc.) as you said. The .align directive does not mean that this section it must fit inside a 0x400 size block of memory; however, as is mentioned on page 10 of the document Tommy linked,

    The IST is relocatable and may be moved to any 0x400-byte boundary.
    This is a hard requirement, and it is the reason why BIOS hard-codes the 0x400 byte alignment into auto-generated command file.

    One thing you might want to do is place the CODE_ROM memory segment at the beginning of your memory (0x000) or the end of memory (0xFC00) to ensure that the rest of your memory map is contiguous. You can do this inside the MEM module in your BIOS config file.

  • 0 in reply to TimHarron
    Intellectual 405 points

    Tim,

    Its been awhile since you helped me tackle the nasty issue (SR #1-629511745) where I was trying to run all my code from IPRAM & IDRAM because the operating environment would not allow us to use an external RAM on the platform. In that issue, we had to put the BOOT_RAM section at 0x0000 to 0x400 and the CODE_ROM section from 0x3000 to 0xFFFF. We had to generate to binary files, 1 for the data section and 1 for the code section. The data section consumed FLASH space from 0 to 0x3000. It had the boot table in it to relocate all the data sections into IDRAM so it had to start at address 0. I then used a merge tool to merge the data binary file and the code binary file into 1 binary file that I could program into the onboard FLASH. It was a very convuluted process that you, Greg, Sam (TI Tech support) and I battled with before we finally derived.

    So, I think moving the CODE_ROM section is not a do-able. The CODE_ROM section has all the executable code in it.

    I doubt this issue can be resolved but it was worth a try.

    Thx.

  • 0 in reply to willshad
    TI__Mastermind 18130 points

    Will,

    I do remember bits and pieces of this issue, but I do think this is something you can still work around. Instead of placing the vector table in CODE_ROM, how about you create a different memory segment for the ISTP (call it VECS) and place that from 0x3000-0x3FFF, then resize CODE_ROM from 0x3400-0xFFFF?

    Please correct me if I am wrong, but my understanding of the issue you are facing stems from the fact that your 1K vector table is being located somewhere in the middle of your CODE_ROM segment thus preventing you from fitting another section in memory? Doing this would allow you to place it at an edge of memory and allow the linker to hopefully squeeze everything else in.

  • 0 in reply to TimHarron
    Intellectual 405 points

    The changes recommended by TI were incorporated. Before the changes, the unused code space was 704(0x2c0) bytes. After the changes, the unused code space is 1248(0x4e0) bytes. The change has definetly packed the sections with less gaps.

    Ran the code on the target and the target runs fine.

    Thanks for your assistance, Bill.