How to specify entry point of a DSP/BIOS based application when using a secondary bootloader

Thanks Mariana for your reply.

The post suggests that c_int00 address will suffice to start the execution. But in my case, when I point a function pointer to c_int00 and then call it, the main() routine is not called subsequently and the PC then goes in to memory with all NOPs. I have tried this with a very simple application which blinks LEDs....

Can you please suggest some thing?

Thanks,

Amit

(amitkumar.solanki@einfochips.com)

Amitkumar Solanki said:

I am working on a board based on a 64x+ dsp.

Which C64x+ DSP? It could be important.

Amitkumar Solanki said:

Using this boot loader I was able to run a simple LED blink application from NAND on boot-up. The nand bootloader simply copies the binary image of the application from NAND to DDR2 and calls the main() function using a function pointer. The offset of main from loading address needs to be specified when writing to the NAND.

Now I want to run a somewhat complex application which is build using DSP/BIOS. My question is how to specify the execution start address.

If I specify the address of _cint_00_, then it does not execute. Same is the case with the LED blinking application, where in I need to specify the address of the main() function as starting point.

If your LED blink application is a C program, it should be started by going to c_int00 and not main(). The fact that it works probably means that there is no C environment needed, like a stack pointer or such, although any local variables would be placed at whatever location the SP happens to be pointing. So maybe you are using only global variables? It may be easiest to figure out the big app's problem by figuring out what using c_int00 as the entry point for the LED blink app did not work.

For example, if you load the LED blink app using CCS/JTAG and do not start it running, where is the Program Counter immediately after loading? It should be at the specified entry point, and that should be c_int00. If it is at main() then you might have an option checked to automatically GoMain, which for this debugging should be turned off (Option->Customize / Debug Properties / uncheck "Perform Go Main automatically"). Even after loading, you should be able to use the Debug->Restart to get back to the entry point.

If what you see does not fit the descriptions from Mariana's posting and my description here, upload your .map file to your reply to this posting (in the reply window, Options tab, File Attachment click Add/Update).

Amitkumar Solanki said:

The post suggests that c_int00 address will suffice to start the execution. But in my case, when I point a function pointer to c_int00 and then call it, the main() routine is not called subsequently and the PC then goes in to memory with all NOPs. I have tried this with a very simple application which blinks LEDs....

When you "point a function point to c_int00 and then call it", what does happen? Do you start executing at c_int00 and can you single-step from there in CCS?

Thanks Randy for your reply,

RandyP said:

Which C64x+ DSP? It could be important.

I am working on a TCI6486 DSP.

RandyP said:

If your LED blink application is a C program, it should be started by going to c_int00 and not main(). The fact that it works probably means that there is no C environment needed, like a stack pointer or such, although any local variables would be placed at whatever location the SP happens to be pointing. So maybe you are using only global variables? It may be easiest to figure out the big app's problem by figuring out what using c_int00 as the entry point for the LED blink app did not work.

Yes. My application does not use any variables.

RandyP said:

For example, if you load the LED blink app using CCS/JTAG and do not start it running, where is the Program Counter immediately after loading? It should be at the specified entry point, and that should be c_int00. If it is at main() then you might have an option checked to automatically GoMain, which for this debugging should be turned off (Option->Customize / Debug Properties / uncheck "Perform Go Main automatically"). Even after loading, you should be able to use the Debug->Restart to get back to the entry point.

If what you see does not fit the descriptions from Mariana's posting and my description here, upload your .map file to your reply to this posting (in the reply window, Options tab, File Attachment click Add/Update).

Please find attached a rar file with the source file, linker file, map file, out file, rmd file use to generate the bin file and bin file.

RandyP said:

When you "point a function point to c_int00 and then call it", what does happen? Do you start executing at c_int00 and can you single-step from there in CCS?

I am able to single step from c_int00 there in CCS, but then it jump to some unknown location.

Thanks,

Amit

(amitkumar.solanki@einfochips.com)

Adding to my question: Does this mean that the bin files generated by hex6x are not relocatable?

The binary image file is generated with following options in the .rmd file for hex6x utility:

simple.out
-b
-e _c_int00
-order M 
-image

Thanks,

Amit

(amitkumar.solanki@einfochips.com)