Very weird problem running a test program

Miguel Torres said:

 The goal of my poject  is to use a software called GNU-Radio to a Davinci 64+ DSP,

Which particular device are you using, DM6437?

Miguel Torres said:

+ When I run one test program that includes something defined in the A library , not even reach the main function, before it starts it goes to this position:

              80953004 0001A120            BNOP.S1       0x80953004 (PC+4 = 0x80953004),5

This is a fairly simple branch to self statement, if it is not getting to main() than chances are that something went wrong in initialization, BIOS has an option to run a user init function before main, if this is happening than it could mean some problem there which may be worth investigating.

Miguel Torres said:

+ The .out  generated in the test program of the A library is veri big 14k in relation with other test programs 1k5, regardless the fact that they are both very simple.

This is not all that unusual, the linker will not link in objects that are not referenced, so if the A library is large it could dramatically increase the .out file size if it is used.

When you say 14k do you mean your .out file size or the library size? I ask because the offset into external memory of the assembly statement mentioned above is almost 10MB into the memory map, implying either a much larger .out file or offsets at the linking stage from the .tcf file. Normally I would expect such a small project to be closer to 0x80000000.

Miguel Torres said:

+ If there is any kind of problem with the memory distribution it should be noticed during the linking,  shouldn´t it?

Generally yes, if you have any static memory issues they should be reported during linking, such as if you have overlapping sections or sections that do not fit. The linker cannot detect if you have dynamic memory issues, such as stack overflows or bad pointers.

   Hi Bernie,

              First of all thank you for your time. The device I am using is Dm6446. The .out file generated is the one of the big size.  I have already checked the stack issue

  and it seems to be OK, there is not an overflow taking place here. Do you think it could be a problem of pointer when it collapses eve before reaching tne main function?

 I have runned the cfg.s64 file setting breakpoints in the _BIOS_init  function and it collapse on the     GBL_postamble  function.

There is no easy reason to guess why your program would be failing in BIOS_init.

Can you get any example program to run okay?

I would recommend either adding to a working example to build up to your full application, or else commenting out portions of your application until you get it to at least run all the way to main() and then exiting main() and still maintaining control.

That the reason that th makes this problem  very weird, if i comment the part of the code that made any reference to elements

defined on the A library , the program runs perfectly well. Otherwise it fails on the BIOS_init. Thats makes me very confused

That means there is most likely something wrong in the A library.

If you have all the source files for the A library, build the project with those source files instead of just pulling in from the library. Make sure you have some debug information on, or even better turn off all optimization until you get this figured out.

If you do not have the source files for the A library, it will be more difficult.

BIOS_init will be trying to create BIOS objects, so there may be problems with stack size for function calls, as Bernie has already suggested, and also for heap space. Check and increase the sizes of both of these, stack and heap. And check where you have allocated memory space for BIOS objects - this will be in the GUI.

Make sure you have "No dynamic heaps" unchecked and have created a heap in one of the memories and have selected the one you want to use for all of the BIOS objects.