migration to SYS/BIOS (legacy)

Do you have
#include <sem.h> at the top of the file?
SEM_pend() is defined as static inline in <SYS/BIOS>/packages/ti/bios/include/sem.h. Can you check that file and confirm?

Sasha

I have narrowed down the problem a little. Correcting my initial question, the call that is being flagged as implicitly defined is LCK_pend() (not SEM_pend).
All of my SEM calls compile without error or warning. All of my HWI, MEM, TSK, etc.. config items compile without error or warning. Only the LCK calls are flagged:

"C:/7000/DSP1/annotate.c", line 702: warning #225-D: function declared implicitly

As I look (grep) through the generated files in <myProj>/Debug I see that all of the xxx.obj files include the proper headers for <sem.h>, <hwi.h>, <mem.h> and <tsk.h> etc... BUT NOT FOR <lck.h> and that is why the calls are being flagged in the compile.

So the question now is, in the build process, why is <lck.h> NOT being made part of the compile ?
Here are two of approx 40 LCK items in my <proj>.cfg file:

bios.LCK.create("LCK_UartRx");
bios.LCK.create("LCK_UartTx");

and here is the output from the build - making the <proj>.cfg

**** Build of configuration Debug for project test4 ****

"C:\\ti\\ccsv5\\utils\\bin\\gmake" all
'Building file: C:/7000/DSP1/SYS1.cfg'
'Invoking: XDCtools'
"C:/ti/xdctools_3_23_04_60/xs" --xdcpath="C:/ti/bios_6_33_06_50/packages;C:/ti/dsplib_c66x_3_1_0_0/packages;C:/ti/ndk_2_23_00_00/packages;C:/ti/ccsv5/ccs_base;C:/7000/platforms;" xdc.tools.configuro -o configPkg -t ti.targets.C64P -p SYS1 -r release -c "C:/ti/ccsv5/tools/compiler/c6000_7.4.4" --compileOptions "-g --optimize_with_debug" "C:/7000/DSP1/SYS1.cfg"
making package.mak (because of package.bld) ...
generating interfaces for package configPkg (because package/package.xdc.inc is older than package.xdc) ...
configuring SYS1.x64P from package/cfg/SYS1_p64P.cfg ...
bios.enableRealTimeAnalysis is not supported
bios.enableRtdx is not supported
warning: ti.bios.GBL: "C:/ti/bios_6_33_06_50/packages/ti/bios/GBL.xs", line 180: ti.bios.GBL : bios.GBL.SPECIFYRTSLIB not supported ...
warning: ti.bios.GBL: "C:/ti/bios_6_33_06_50/packages/ti/bios/GBL.xs", line 169: ti.bios.GBL : bios.GBL.C64PLUSL1PCFG is not supported. Set Cache sizes using the Platform wizard. See BIOS 6.x User Guide for more details
warning: ti.bios.GBL: "C:/ti/bios_6_33_06_50/packages/ti/bios/GBL.xs", line 169: ti.bios.GBL : bios.GBL.C64PLUSL1DCFG is not supported. Set Cache sizes using the Platform wizard. See BIOS 6.x User Guide for more details
warning: ti.bios.GBL: "C:/ti/bios_6_33_06_50/packages/ti/bios/GBL.xs", line 169: ti.bios.GBL : bios.GBL.C64PLUSL2CFG is not supported. Set Cache sizes using the Platform wizard. See BIOS 6.x User Guide for more details
warning: ti.bios.MEM: "C:/ti/bios_6_33_06_50/packages/ti/bios/MEM.xs", line 307: ti.bios.MEM : bios.MEM.USERCOMMANDFILE is not supported.
warning: ti.bios.MEM: "C:/ti/bios_6_33_06_50/packages/ti/bios/MEM.xs", line 312: ti.bios.MEM : bios.MEM.HWIVECSEG is not supported.
warning: ti.bios.TSK: "C:/ti/bios_6_33_06_50/packages/ti/bios/TSK.xs", line 134: ti.bios.TSK : bios.TSK.CALLSWITCHFXN not supported
warning: ti.bios.TSK: "C:/ti/bios_6_33_06_50/packages/ti/bios/TSK.xs", line 138: ti.bios.TSK : bios.TSK.SWITCHFXN not supported
warning: ti.bios.TSK: "C:/ti/bios_6_33_06_50/packages/ti/bios/TSK.xs", line 266: ti.bios.TSK.Instance#0 : 'order' not supported
<snipped a few more <order> warnings>
warning: ti.bios.CLK: "C:/ti/bios_6_33_06_50/packages/ti/bios/CLK.xs", line 281: ti.bios.CLK : bios.CLK.HIRESTIME not supported
warning: ti.bios.CLK: "C:/ti/bios_6_33_06_50/packages/ti/bios/CLK.xs", line 281: ti.bios.CLK : bios.CLK.CONFIGURETIMER not supported
warning: ti.bios.CLK: "C:/ti/bios_6_33_06_50/packages/ti/bios/CLK.xs", line 281: ti.bios.CLK : bios.CLK.SPECIFYRATE not supported
warning: ti.bios.CLK: "C:/ti/bios_6_33_06_50/packages/ti/bios/CLK.xs", line 281: ti.bios.CLK : bios.CLK.INPUTCLK not supported
warning: ti.bios.PRD: "C:/ti/bios_6_33_06_50/packages/ti/bios/PRD.xs", line 79: ti.bios.PRD.Instance#0 : 'order' not supported
warning: ti.bios.PRD: "C:/ti/bios_6_33_06_50/packages/ti/bios/PRD.xs", line 79: ti.bios.PRD.Instance#1 : 'order' not supported
warning: ti.bios.RTDX: "C:/ti/bios_6_33_06_50/packages/ti/bios/RTDX.xs", line 54: ti.bios.RTDX : RTDX is not supported
cl64P package/cfg/SYS1_p64P.c ...
'Finished building: C:/7000/DSP1/SYS1.cfg'

Thanks

Sasha, no I am NOT linking 100% yet, as the reply says. In order to get around the issue in THIS thread, I added the #include <lck.h> to the <proj>cfg.h file that the conversion from TCONF created. That fixed the compile issue for the 20 or so files that have LOCKS in them.
So the question has not been answered. Yes, adding an explicit #include does solve the problem BUT I should not need that according to the migration documents. So I would still request that we try to solve the problem.
This will be the third time I have had to bypass issues in order to get close to a complete build. I am guessing that the final product will not work correctly and I would prefer to not have these issues looming over me when I go to debug the executable. I would like to request this forum's help with these issues so I can end up with a good build "by the book".
So, any idea what might be causing the <lck.h> header to be excluded from the legacy build ??
Thanks

The warning is coming from annotate and that's where you call LCK_pend, right? Then, you should add #include <lck.h> to that file, not any of the generated files. If any other of your source files calls LCK_pend, there should be an include statement in each of them. These include statements should have been there already. It's possible you were getting them indirectly through <proj>cfg.h, but that was by chance. A "by the book" build is the one where among other things you include directly a header file that defines a function invoked in that file.

Sasha, with all due respect I am going to reject your answer. The headers were included (by TI) into the <proj>cfg.h file on purpose, because they were then followed by the declarations of all the generated SEMs, LCK, etc.. so saying that I lucked out by including this one central file instead of explicitly including each needed header into each file is just silly.
And then, I guess that while my LOCKS are breaking, my SEMs and TSKs are compiling fine - is that 'by chance' also ? I would have to believe that the whole process of converting the TCONF file into the CFG file would have been created to handle ALL of the DSP/BIOS modules, not just some.
You are correct in saying the a good piece of code includes each and every header it needs to compile correctly and that will be my goal as this project matures but I believe the issue at hand is a BUG and I am reporting it as such.
Thanks

Richard,
the headers were included in <proj>cfg.h to support declarations of the generated objects, as you said. They are not there to include header files for all functions that can be invoked from source files. In fact, DSP/BIOS does not parse application source files, and cannot know which functions were invoked in these source files, so it cannot include appropriate header files in <proj>cfg.h.

For example, if you created only one DSP/BIOS object, a LOG instance let's say, the only header included in <proj>cfg.h would be log.h because a LOG instance declaration requires types defined in log.h. If in your source file you call a function from sys.h, SYS_printf() for example, you would get that same warning you were getting for LCK_pend.

I don't mind filing a bug and I'll talk with someone from the SYS/BIOS team to figure out where to file that bug because DSP/BIOS is in a maintenance mode and only critical bugs are fixed. However, I can see only two solutions for that request. One is to include all header files in <proj>cfg.h, while another would be to parse application source files looking for DSP/BIOS function calls. I don't think any of them is really an acceptable solution.

Sasha
Thanks for the explanation. I do understand that the static header <proj>cfg.h may not contain header references to modules that are not explicitly declared within. In this case, almost every module that is used in the build was declared statically, in the TCF file, including all of the LOCKs that are in question now. Looking at the TCF file from the DSP/BIOS build, and the output <proj>cfg.h file, after a DSP/BIOS build, I see that the header <lck.h> is included. So I would assume this to be a bug in the legacy XGCONF conversion step.

I will be happy to provide any project/build files, if that will help. In fact I looked through <PROJ>_p64P.h in my project tree and saw references to the LOCKs in question - I just do not know enough about the project build process to understand all the conditional defines and how to determine what state they would / should be in. For example, here is an entry for a SEM:

#ifndef ti_sysbios_knl_Semaphore__include
#ifndef __nested__
#define __nested__
#include <ti/sysbios/knl/Semaphore.h>
#undef __nested__
#else
#include <ti/sysbios/knl/Semaphore.h>
#endif
#endif

extern ti_sysbios_knl_Semaphore_Struct SEM_InitFinished;

**And here is an entry for a LCK;

#ifndef ti_bios_support_Lck__include
#ifndef __nested__
#define __nested__
#include <ti/bios/support/Lck.h>
#undef __nested__
#else
#include <ti/bios/support/Lck.h>
#endif
#endif

extern ti_bios_support_Lck_Struct LCK_UartRx;

Where are * ti_sysbios_knl_Semaphore__include * and * ti_bios_support_Lck__include * defined (or not defined). Is the difference in naming significant ? Does this help you ?

Thanks

Richard,
in the DSP/BIOS build, the generated header file <proj>cfg.h contained lck.h because that header file was needed for the declaration of LCK instances. In the SYS/BIOS legacy support, LCK instances are represented with ti_bios_support_Lck instances, as you can see in <proj>_p64P.h. These new instances do not need lck.h, but they need ti/bios/support/Lck.h so that's the header file included in the code above. The two mentioned header files are different; lck.h declares LCK_pend, while ti/bios/support/Lck.h does not.
The macros 'ti_sysbios_knl_Semaphore__include' and 'ti_bios_support_Lck__include' do not matter that much because in your source files they all disappear and you only get
#include <ti/bios/support/Lck.h>
extern ti_bios_supportLck_Struct LCK_UartRx;

I still don't see a bug. In DSP/BIOS, the header file contained includes that were needed for that header file. In the SYS/BIOS legacy support, the same principle holds - only what's needed in the header file is included.

Sasha, this will be my last post on this matter. I have a work around and that's what's important to me.

I called this issue a bug because
1) both constructs SEM_pend() and LCK_pend() were available to DSP/BIOS.
2) both constructs exist in my TCF file and the TCONF output file, for inclusion into my code.
3) both constructs ran through the XGCONF conversion process without error or warning.
4) both constructs are shown as supported in the Bios_Legacy_App_Note
5) based on that App Note:

Most DSP/BIOS 5 legacy C APIs still exist in SYS/BIOS 6, and may be called without making
any C code changes. However, a small number of modules and their APIs are no longer
supported, either because they are no longer part of SYS/BIOS or because support for them did
not make sense. The number of these deprecated modules and APIs was kept to a minimum.

6) The table of supported/unsupported APIs show both Legacy APIs as supported.
7) There are no additional notes that single out LCKs as any different that SEMs in this legacy support.
8) SEMs in my SYS/BIOS build compile correctly, no error, no warning, without a specific #include <sem.h>
9) LCKs in my SYS/BIOS build throw the warning.

That's the best I can do to outline this as a bug. If LCKs require additional work to compile then there should be some document or note in the Bios_Legacy_App_Note that outlines what that work is. If modules labeled (in the App note) as "SYS/BIOS 6 Legacy Module: ti.bios.SEM" are treated different than modules labeled "SYS/BIOS 6 Legacy Module: ti.bios.support.LCK" for example then there should be instructions for handling the difference - but all the note says:

Most DSP/BIOS 5 legacy C APIs still exist in SYS/BIOS 6, and may be called without making
any C code changes. However, a small number of modules and their APIs are no longer
supported, either because they are no longer part of SYS/BIOS or because support for them did
not make sense. The number of these deprecated modules and APIs was kept to a minimum.

Thanks for listening
Richard