How to avoid "warning: entry point other than _c_int00 specified"?

You can use the linker option --display_error_number to get the diagnostic id for the above warning, then use the --diag_suppress=id option to suppress the diagnostic.

This particular warning is diag id 10063, so using --diag_suppress=10063 will suppress it.

Thanks for the input.

When looking at the documentation, these are compiler (not linker) options. The short equivalent is -pds (and -pden to enable message number output)

Unfortunately, this does not work for the cgtools 4.1.3 at all. The warning is not suppressed or I get "invalid option".

It works for cgtools 5.1.2 when calling the linker via compiler and -z option:

cl2000 -pden -pds10063 -z <real linker options>

It does not work for cgtools 5.1.2 when calling the linker directly ("invalid option"):

lnk2000 -pden -pds10063 <real linker options>

So is there a real difference between the 2 calling methods (linker or compiler with -z)?
Why do we have these 2 calling methods?

I do not like the 5.x cgtools so far. They are slow and documentation is still preliminary (spru514c).
So it seems as if I have to live with the warning or live with cgtools 5.x - or is there another way to suppress linker warnings?

Stephan,

In general I would say to supress a warning is not a very wise decision. Actually there is no need to specify an entry point at all when you develop an embedded solution, which I assume is true in your case. In this circumctance the sequence after reset follows the boot sequence. Let's assume you have set the start condition to 'Jump to flash entry point' (4 GPIO's). This will force the DSP to branch directly into the FLASH entry point address (a slot of 32 bits). All you have to do is to place a long branch into this very memory slot. In case of a C based code this is usually a LB _c_int00. If you prefer to execute another code section before _c_int00, just place another LB into the flash entry point. Of course your additional code must branch into _c_int00 at the end to continue with the C environment setup and a call of main. Have a look into the TI function "DSP28xxCodeStartBranch.asm", which places either a branch to _c_int00 or to wd_disable into the code entry point. When you adapt this principle to your code, you can easily squeeze any other code section between a start and _c_int00.

If you specify an explicit entry point in CCS, it is used by the command "Restart" to force the PC to this very address point.

Regards

Suppressing warnings - agreed; normally I want to get every warning to be able to avoid it.

In this case I took the examples for the F28335 ezDSP which specify a different entry point!

The problem is not the "jump to flash", but the "jump to SARAM" boot option (to debug and run out of internal/external ram and do not have to flash the device).

When trying to debug with this configuration, my startup code is not executed with the normal c_int00 entry point.

The only possibility I see to keep the default c_int00 entry point AND execute my startup code during "jump to SARAM" debugging is to add something like "PC=0" to the OnFileLoaded() GEL function.
This will force the DSP to start at the SARAM start point, not at c_int00.

Do you agree?

Stephan,

as long as you are JTAG-connected with CCS you can use any means to control the startup sequence, including the GEL featuers. Preferences are users choice.

However it makes no difference if you branch into FLASH or into SARAM when you use the CodeStartBranch.asm solution. If you connect section "codestart"  to physical address 0 ( just mofidy a single line in the corresponding cmd-file), your "LB wd_disable" will be placed into the right memory spot. This way you can right start from RESET into RUN(F5), because the sequence is caused by hardware.  Furthermore, if your watchdog causes a reset, this setup will bring your code right back into the correct sequence, which would not be the case in a GEL setup.

If you prefer to stay in a RAM debug environment and your final goal is a FLASH version, please also keep in mind the different timing performance of your control code.

Regards

Frank Bormann said:

However it makes no difference if you branch into FLASH or into SARAM when you use the CodeStartBranch.asm solution. If you connect section "codestart"  to physical address 0 ( just mofidy a single line in the corresponding cmd-file), your "LB wd_disable" will be placed into the right memory spot. This way you can right start from RESET into RUN(F5), because the sequence is caused by hardware.  Furthermore, if your watchdog causes a reset, this setup will bring your code right back into the correct sequence, which would not be the case in a GEL setup.

Hmmm, here it makes a difference:
code_start is at physical address 0, I have a breakpoint at the first statement (LB wd_disable) and the debugger stops there when specifying code_start as entry-point, but does not stop when having default c_int00 as entry point.
This is a difference compared to the 2812 that we also use. On the 2812, we never had to specify a special entry point, but the debugger always correctly went to code_start.

The boot mode that is selected also plays a factor here when debugging through CCS. Whenever you select Debug -> Reset CPU, execution will start in RAM or flash depending on your boot mode. This may be the reason you never encountered this on the F281x.

Regards,

Tim Love

Frank Bormann said:

Actually there is no need to specify an entry point at all when you develop an embedded solution

I cannot agree here. I have my own entry point too, it clears out the memory to 0 or 0xdead, depending on the location (stack, heap, bss).

I also get this warning ever since, but if I could switch it off, this would be welcome.

Regards, ThomasZ

I think the best way is to modify the "boot.asm" file which includes the reset vector and _c_int00 function. The source can be found in the "rts.src" included with CCS. After modifying the file, make your own library, say MyBoot.lib. Then include MyBoot.lib in front of other libraries (including rts_xxxx.lib). You will not get any more warning messages and you can do whatever necessary at startup.

i think there is no effect when we run in real application rite? am I

ck.hk said:

I think the best way is to modify the "boot.asm" file which includes the reset vector and _c_int00 function. The source can be found in the "rts.src" included with CCS. After modifying the file, make your own library, say MyBoot.lib. Then include MyBoot.lib in front of other libraries (including rts_xxxx.lib). You will not get any more warning messages and you can do whatever necessary at startup.

This seems to be a good way - we did something similar on the 2407A already.

So we either have to modify the boot asm or have to use the (very sloooow) cgtools 5.1.2 and suppress the warning.... (sigh)