This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

EVM5515 and Codegen 3.36

Other Parts Discussed in Thread: CCSTUDIO

Hello Everyone,

I have been attempting to modify the "SpO2_System_v5_0" codebase that ships with the SpO2 AFE board so that it will compile and run on my Spectrum Digital EVM5515.

Whilst trying to figure out how to go about this, I came across a previous thread on this forum in which it was mentioned that a newer version of the codebase ( "SpO2_System_v5_1") has been released for the C5505 eZdsp development tool. I have managed to download the "SpO2.out" file to my EVM5515, and it seems to be running as expected.

What I would like to be able to do now is to compile the codebase. The release notes that ship with the "SpO2_System_v5_1" codebase state that Codegen version 3.36 should be used to build the project, and alas I have been unable to find any mention of this legacy version on the TI website. Could someone please inform me how I can get hold of a copy of this version?

Thanks for any help.

 - Rodney

  • Rodney,

    It sounds like the Release Notes need to be updated.  You should use 4.3.6 or newer release of the Code Gen Tools.

    Regards.

  • Hi Tommy,

     

    Thanks for your reply. As stated previously, I have managed to get the "SpO2.out" file to run on my 5515EVM board, but have been unable to compile the codebase (as downloaded from the C5505-eZdsp Google code page)successfully.

     

    It seems that the compiler is unable to find "std.h", which does not form part of the project codebase. A quick search of my computers "..\Texas Instruments" directory reveals a number of different versions of "std.h", and I am unsure which one I should be using.

     

    Some versions appear in BIOS directories, and others in xdctools directories. I am quite certain that the "SpO2_System_v5_1" codebase is not a DSP/BIOS application, and am fairly certain that it is also not using xdctools. This leaves me scratching my head as to which "std.h" to use.

     

    If you can clarify this issue I would certainly appreciate it.

     

  • Rodney,

    Let me look into this.  What version of CCS and Compiler are you using?  What versions of BIOS and XDCTools are configured for your CCS installation.

    Regards.

  • Rodney,

    I am able to build successfully using CCSv3.3.  However when I import this project into CCSv4, I see the same error with std.h as you report.  The file std.h is a DSP/BIOS file.  Not sure why this is being included in a non-BIOS project.  To resolve that error I found it easier to add a path to the file which is located in folder \packages\ti\bios\include in the BIOS install folder than delete std.h from all the project files.  Define the search path in Build Properties -> c/C++ Build -> C5500 Compiler -> Include Options.  Even after this I am seeing errors with TRUE and FALSE not being defined.  Haven't figured this one out yet.

    Regards.

  • Hi Tommy,

    With regards to the toolchain, I am using CSS version 4.1.2.00027, as shipped with my 5515EVM. The following bitmap shows the contents of my ..\Texas Instruments folder:

    Having included the 5.41.02.14 BIOS path as described, my error list mirrors yours - 44 different errors reporting that TRUE and FALSE have not been defined. Interestingly enough, commenting-out references to "std.h" in the primary project files (SpO2_Functions.c etc) results in a cascade of errors that makes the TRUE and FALSE list look quite tame by comparison.

     

    Regards,

     - Rodney

     

  • Rodney,

    OK, so commenting out std.h is not an option.  Again, not sure why BIOS header is being used here.

    I am still researching these error messages for TRUE and FALSE.  I use the same release of the compiler between CCS3.3 (no errors) and CCS4.1 (many errors).  So, it is confusing to me why one builds clean and the other doesn't. 

    Regards.

  • Rodney,

    Ok, with the help of a colleague who is pretty knowledgeable about CCSv4 we were able to figure out the problem.  It turns out that CCSv4 has a different definition on Include file search path than CCS3.3.  CCSv4 is having compiler search the local project header files last.  So for instance in my build dda_uart.c is generating the TRUE/FALSE error messages.  However, if you look in the file you will see that header file psp_common.h contains a reference to tistdtypes.h where TRUE/FALSE are defined.  Then in psp_common.h True/False are defined.  Sounds good, right? 

    Well what is actually happening is that CCSv4 defines the include file search path order under Build Properties -> C5500 Compiler -> Include Options.  CCSv4 has the local folders for the project defined last in the search list.  Unfortunately, there is a tistdtypes.h file in both BIOS and CSL folders (first on the search list).  In my case the BIOS folder was listed first and the Compiler thought it had found the correct header file.  The BIOS tistdtypes.h does not have a definition for TRUE/FALSE so we get the error message.  You see which version of a file is being used by the compiler using the tabs in the editor window for the C/C++ mode.  If you hover over dda_uart.c you will see the location of the this file - it is correct.  Now if you highlight the line #include <psp_common.h> and right click you will see the option to open the file psp_common.h.  Select that option and psp_common.h will open in a new tab in the editor window.  Hover over the tab and you will see the path is correct.  Now do the same thing to #include <tistdtypes.h> line in psp_common.h.  Once the file is open, hover over the tab and you will see that this is not pointing to the correct version of tistdtypes.h.  That's why the build is failing.

    To correct this issue open Build Properties -> C/C++ Build option -> Tool Settings tab -> Include Options.  You will see the search paths defined and the order that CCSv4 will search them.  Take the 4 locally defined folders: \inc, \common_inc, \src and \common_src (doesn't actuall exist in this project) and move them to the top of the search list.  You can do that by using the Move UP and Move DOWN icons across the top of the definition window.  Once you do this you should be able to get the build to complete successfully (but with 20 warnings).

    Let me know if this works for you.  And don't forget about the std.h BIOS header that needs to be pointed to.

    Regards.

  • Hi Tommy,

    That did the trick. Thank you very much for your help and the input from your colleague.

    Regards

     - Rodney

  • Rodney,

    Glad that worked for you.  Hopefully, this exercise will help some other folks also.

    Regards.

     

  • Hi  Rodney,

    I got the problem you have met a few months ago,I am using the SpO2 MDK now, and when i compile  the code SpO2_System_v5_1.

    I got 44 errors,they are all that the TRUE and FAISE undefined,I read your post on the Forums ,and I need your kind help,where can i found the

    Build properties? Can your show me step by step?Thank you for your details!

    Regards

  • Hi Rodney,

    Your tips were very helpful in getting the SpO2 to build in CCStudio_v4 without errors.  Thank you.

    However, the code displays noise instead of signal.  Did you do anything else to fix the code?

    Should I be paying attention to any of the warnings?  The only on ones that look significant are listed below.  Does the v3.36 build produce these warnings?

    • entry-point symbol other than "_c_int00" specified: "reset_isr"
    • warning: function declared implicitly for functions IIC_WRITE, lcd_clear, SpO2_C5505Init, LLC_SPI_WLenGet, strlen
    • integer conversion resulted in a change of sign
    • missing return statement at end of non-void function "PAL_osGetCurrentTick"

    Thanks, Berwyn

  • Others: please also refer to my post here on a very nasty workaround to use the codegen v3.36 tools.

    Note to TI: this is not a good situation.  We'd really love to be able to build a *working* SpO2 with the tools it ships with.  It seems that the codegen v4 tools make it output noise. Thanks.

  • Hi Hoyt:

        I am having the same problem as you are having ( noisy signal) using VC5505 EVM and CCStudio V3.3.

    I have tried too much changing the code, but no gain.

    In last when i studied the schematic diagram of  PO card, i came to know that there are two amplifiers

    the second amplifier has one input coming from first amplifier and the other input from DAC0_C, and i think here

    is the problem. If you want to remain this DAC output fix at some value in software and recompile, you may observe

    clear signal, although that does not resemble standard PPG signal, but the noise is removed up to some extent.

    Please do work in this direction, also inform me as i am also working at this point.

        Regards

       FAYAZ