>> By my understanding, the _auto_init function
initializes C++ objects
>> that have been statically allocated (compiled in). The other
functions
>> are initializing data memory segments such as .data
and .bss.
> Don't recall exactly about .data section, but TI
linker never
initializes
> .bss, unless vars declared there were explicitly
initialized.
I thought that the .bss segment was filled with 0's by the
initialization code. All explicitly initialized variables should be in
the .data section anyway.
>> My guess at your problem is that you have allocated
some memory
segment
>> over the top of some registers. Note that any memory
that is not
>> explicitly allocated will be allocated at the lowest possible
address.
>> This may overwrite memory-mapped registers, causing
the incorrect
>> behaviour that you have seen.
> If that were this simple. I've been working with
TI processors for a
> long time, and this problem was always there, appearing between
builds.
> The reason might be anywhere except the allocation
strategy, which
works
> fine even if there were no .cmd file specified, in
that case a default
> allocation rules (see description of lnk6x) are applied.
I'm fairly new to TI, but I've worked with other processors/tool
chains
that have similar problems, and it has usually related either to the
link map or to an ISR modifying unprotected variables. I have found
such a problem several times when a new section is created by the
compiler and implicitly linked at the lowest possible location. For
example, trampoline code for switch statements can be allocated into a
special section, or new library functions may have data in named
sections which are then allocated automagically.
> In fact the
> linker knows processor memory map and would never overwrite memory
> mapped registers region, unless a memory section was erroneously
mapped
> there in the project's .cmd/.lcf file using an
absolute address of the
> peripheral bus.
I have not specifically worked with the c6x, but the c5x linker does not
seem to protect the register section in any way, and the registers are
mapped to the main memory, not the peripheral memory.
> I've never fought over the problem of "not
reaching the main()
function"...
> Sometimes it may happen, so I usually reset the
processor, or restart
CCS,
> or increase amount of .stack memory, or reload the
binary image
several times.
I don't like the sound of that. If reloading the image multiple times
actually fixes a problem, then I shudder to think what is going to
happen when I do some serious development and debugging with CCS!
>> I think this should be written down somewhere as the
#1 trap for
>> beginners on TI DSPs!
> So do I, although there are several more problems
which could also be
> good candidates for the #1 traps :) E.g. sometimes stdout would
strangely
> refuse to work (printf(),puts() do not print
anything, and even
fflash()
> does not help).
> Sorry that my email actually poses more questions
instead of giving
> answers.
All good background for me.
Thanks,
Timothy
RE: Re: Execution never reaches the 'main' function unless I do several
Started by ●December 4, 2006