• Locked Locked
  • Replies 8 replies
  • Subscribers 100 subscribers
  • Views 1262 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.

Memory fill holes going to RAM, not FLASH - 28035, DSP BIOS 5.42.1.09, Compiler 6.2.0, CCS 5.5

BadMonkey
Expert 2090 points

Our DSP BIOS project runs from FLASH. There are few functions that are stored in FLASH but run from RAM. This all seems to OK.

However, there are two holes that are filled and these are being located directly to RAM in the hex file output. These holes are related to the idle task in the DSP BIOS.

Here is a snippet from the top of the output file:

:209B4200000000000000000000000000000000000000000000000000000000000000000003  //RAM
:209B52000000000000000000000000000000000000000000000000000000000000000000F3  //RAM
:089B8C000000000000000000D1                                                  //RAM
:02000004003EBC                                                              //ADDRESS EXTENDER 0x3E
:20800200C879003EC879003EC879003EC879003EC879003EC879003EC879003EC879003E66  //FIRST FLASH LINE 0x3F8002

These zeros going to RAM are from these directives. Look for "--HOLE-- [fill = 0000]"::

..TSK_idle$stk
*          0    000099b6    00000098     UNINITIALIZED
                  000099b6    00000098     TargetBioscfg.obj (.TSK_idle$stk)

.prd       0    00009a4e    00000030     UNINITIALIZED
                  00009a4e    00000030     TargetBioscfg.obj (.prd)

.bss       0    00009a7e    00000002     UNINITIALIZED
                  00009a7e    00000002     AsmRoutines.obj (.bss)

.tsk       0    00009a80    0000006a     UNINITIALIZED
                  00009a80    0000006a     TargetBioscfg.obj (.tsk)

.sts       0    00009aea    00000030     UNINITIALIZED
                  00009aea    00000030     TargetBioscfg.obj (.sts)

.swi       0    00009b1a    00000028     UNINITIALIZED
                  00009b1a    00000028     TargetBioscfg.obj (.swi)

.trace     0    00009b42    00000020     
                  00009b42    00000020     --HOLE-- [fill = 0000]

.sem       0    00009b62    00000016     UNINITIALIZED
                  00009b62    00000016     TargetBioscfg.obj (.sem)

.sys       0    00009b78    00000008     UNINITIALIZED
                  00009b78    00000008     TargetBioscfg.obj (.sys)

.idl       0    00009b80    00000006     UNINITIALIZED
                  00009b80    00000006     TargetBioscfg.obj (.idl)

.idlcal    0    00009b86    00000006     UNINITIALIZED
                  00009b86    00000006     TargetBioscfg.obj (.idlcal)

.args      0    00009b8c    00000004     
                  00009b8c    00000004     --HOLE-- [fill = 0]

I don't think I really need these holes filled but I am not sure.

Do I need these filled as it seems to be in a DSP BIOS area?

If not, how do I disable the fill?

The value in,

CCS Build->C2000 Linker->Advanced Options->Runtime Environment->Default fill value

is blank. However, I don't think that this enables\disables fill, rather only dictates a value other than the default value which appears to be zero.


Any ideas,

Regards,

Jim

  • TI__Expert 3520 points
    Hi Champs,

    Since this appears to potentially be more related to DSP/BIOS rather than C2000 should the question be moved to the TI-RTOS forum (e2e.ti.com/.../tirtos) or, due to the underlying architecture, is this a question that should remain here?

    Any guidance is appreciated!

    Best Regards,

    Mark-
  • in reply to Mark Swanson
    TI__Guru* 92120 points
    Jim, Mark,

    I think the BIOS team will likely have some insight and I've asked them to take a look. Unfortunately it looks like thread moves to their forum isn't working at the moment.

    Regards
    Lori
  • in reply to Lori Heustess
    TI__Mastermind 20805 points
    The .trace section is used for SYS_printf() output. SYS_printf() put characters into a circular buffer. This buffer is in the .trace section. If you don't use SYS_printf() in your app, you shoudl be OK. And if you do use SYS_printf() in your app, it should also be OK except that you might have some garbage characters in the buffer.

    The .args section is used to support 'argc/argv' arguments to main(). If your main() function doesn't reference the 'argc' or 'argv' parameters, you should be OK not filling that section.

    -Karl-
  • in reply to Karl Wechsler
    Expert 2090 points
    Hi Karl,
    I am OK with filling the holes. The issue for me is that the holes end up going to RAM in the HEX file. Our application is configured for FLASH. Our bootloader is not expecting data to go to RAM. It doesn't seem to hurt it. But, if the configuration is for FLASH, the holes should be filled in FLASH, not RAM. That is, they become a filled part of some data descriptor table for the C environment to be copied to RAM at boot up.

    Jim
  • in reply to BadMonkey
    Expert 2090 points
    Any ideas?

    Jim
  • in reply to BadMonkey
    TI__Expert 3520 points

    Hi Jim,

    According to this post, the .trace and .args are hard coded to be located in RAM and filled with 0s according to a template file. A workaround appears in the thread to allow for the .trace section to be left uninitialized, but a separate part of the build process/tool is leaving the .args section intitialized. Section 3.2 of the Running and Application from Flash application note also identifes SYS/BIOS projects should place the .args section in RAM.

    As Karl identified earlier, your application will run fine assuming you do not reference the argc/argv parameters and the applicatoin tolerates invalid characters initially loaded in to the SYS_printf() buffer assuming the buffer is utilized.

    Based on the above, my understanding is that the behavior you are seeing is expected and valid for an application running from Flash. Karl wil hopefully correct me if my understanding is incorrect!

    Best Regards,

    Mark-

  • in reply to Mark Swanson
    Expert 2090 points
    Hi Mark,

    I do not understand how this can be expected behavior for an application running from FLASH. The memory fill in the .hex file so it will only be valid from the first run after programming.

    So, I understand now that my application should run OK. But, our boot loader is returning "Out of Bounds" error messages on download. We can have the download tool (configurator) ignore the messages for specific address ranges I guess. Or, we could run a tool to strip the file of RAM located data. Currently, the download tool & boot loader expects that a FLASH based app. will be completely located in FLASH at programming.

    Curiously, though, what IF my application DID need to reference the argc/argv parameters? It seem to me that a program built to run from FLASH should initialized the holes as part of initialization from FLASH.

    Am I wrong in assuming that that makes sense?

    Jim
  • in reply to BadMonkey
    Expert 2090 points

    Any update\clarification?