This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Execution of constructors in at91


Nick Garnett wrote:

Rubén Pérez de Aranda Alonso <rperez@sidsa.es> writes:



Hello,






I am working with the at91 eb40 porting of eCOS to develop another
port for a prototype based on the same microcontroller. I now use
the EmbeddedIce pod to debug the eCOS and execute the tests of the
different parts and layers, but I would like use the Redboot and its
GDB stub because it allows me write the falsh chips and the
comunication with the host is faster. I have installed a redboot
image in flash. With the load command in GDB I upload the
application in the RAM memory that has been compiled to be executed
in RAM and with a ROM monitor. The problem is when the eCOS startup
code calls to the cyg_hal_invoke_constructors() function. This
function uses the symbols allocated by the linker, __CTOR_LIST__ and
__CTOR_END__, to know the address of the constructors belonging to
*.ctors binary sections of the different object files. The function
calls to these constructors without verify if the function pointer
points to NULL, so the pc register branch to the 0x0 address and
execute the reset vector.



There should not be NULL pointers in the constructor table. So the thing to do is find out why they are there. Make sure you have not corrupted the linker script in some way. Also, add the option "-Wl,-Map,map" to the linker options, take a look at the map file produced and see where the sections being added to the constructor table are coming from.






Yesterday I found the problem.
When the firmware is configured with RAM startup the vectors.S does not contains the code to initialize the .data section
and the .ctors and .dtors sections of the object files are allocated in the .data section of the final binary file. I had configured
the linker script with LMA != VMA and RAM startup.
Another problem is when the the stack pointer of the stub code overlaps the .bss and/or .data sections of the application which
are being debugged. I resolved this adding a bigger offset in the sram shared by the stub and the application. I seen this
behaviour debugging the ROM monitor throught the Embedded ICE at the same time I was debugging the application with the
ROM monitor throught the serial port of the target.





-- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]