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.

ccs_base PRU Include Directory Contains Conflicting Content

Other Parts Discussed in Thread: AM3358

Gentlemen,

Windows 7 64-bit PC
AM3358 on the AM335x Starter Kit
CCS Version: 6.1.2.00015   (for Sitara processors)
Processor SDK RTOS AM335x v2.00.02.11 with SYS/BIOS 6.45.01.29
XDCtools 3.32.00.06
PRU Support Package v4.0.2

I would like to call to the attention of the CCS engineers a conflict I recently encountered regarding the *.H file contents of the  C:\ti\ccsv6\ccs_base\pru\include  directory.

I encountered the conflict after a previously compiling PRU example started having errors compiling after I had switched the target device from "Beaglebone Black" to "SK_AM3358".

Investigating this, I found that the change caused

C:\ti\ccsv6\ccs_base\pru\include

to be (silently) inserted at the top of the Include directory list.

Investigating further, I found that some files in that directory are expressed only once (e.g. pru_cfg.h and pru_intc.h) whereas the contents of these files appear to change widely depending on which Sitara family is used.  Specific example, the pru_cfg.h file differences between the AM335x vs AM437x are considerable (there appears to be a whole set of registers that exist for the AM437x and not for the AM335x).  Furthermore, there a few minor bit-field width differences, for example the HIEISR.HINT_EN_SET_IDX field width in the INTC group of registers should be 4 bits for the AM335x, but the <ccs6>\ccs_base\pru\include\pru_intc.h files has this field width as 10 bits.

It would appear that the  PRU Support Package v4.0.2  corrects these problems, but has no instructions about where to install it, and it would seem that once this is installed that it should somehow supplant the *.H files in the  C:\ti\ccsv6\ccs_base\pru\include  directory, especially since CCS6 is silently (probably correctly) ensuring that include directory is in a PRU project.  Furthermore, the  PRU Support Package v4.0.2  also includes different copies of 8 PRU .H files in separate directories for each Sitara processor family (am335x, am437x, am571x, etc.).

In case these things were not already on the list for resolution for the next CCS update, I thought I would bring them to your attention.

Kind regards,
Vic

  • Vic,

    Thanks for reporting this. Regarding the first part of your post (changing the target device at the project level), I was able to reproduce this only with PRU projects - GCC projects for Cortex A8 and Cortex M3 of the Sitara devices preserved the original order. I will get back to you on that.

    I will ask for someone from the Sitara team to comment about the PRU header files.

    Regards,
    Rafael
  • Vic,

    Please apologize for the delay.

    Victor Wheeler said:
    I found that some files in that directory are expressed only once (e.g. pru_cfg.h and pru_intc.h) whereas the contents of these files appear to change widely depending on which Sitara family is used.

    You are right; when the PRU support was implemented in CCS the only device supported was AM335x and the only include files available were in the pru/include directory. However, the addition of new devices required heavy modifications by the package maintainers and therefore the main directory became outdated.

    Victor Wheeler said:
    It would appear that the  PRU Support Package v4.0.2  corrects these problems, but has no instructions about where to install it, and it would seem that once this is installed that it should somehow supplant the *.H files in the  C:\ti\ccsv6\ccs_base\pru\include  directory, especially since CCS6 is silently (probably correctly) ensuring that include directory is in a PRU project.

    There is a Getting Started guide at:

    http://processors.wiki.ti.com/index.php/PRU-ICSS_Getting_Started_Guide

    Although the placement of files and directories are pretty arbitrary in Windows.

    Also, as it is stated at that page, the PRU support package is part of a larger package named Processors SDK 2.x, which will most probably be a lot more consistent in terms of install instructions and such.

    Despite this I am in conversations with the package maintainers to see what can be done to streamline the use of this package.

    I apologize for the inconvenience,

    Rafael

  • Hi, Rafel!

    Thanks for the detailed reply.

    I may have created a misunderstanding in how I worded my statements: I had no problem with the fact that it let you install it wherever you wanted (I chose C:\ti\pru_4_0_2 for the 4.0.2 version, in keeping with the pattern I see being used by other TI products).

    My confusion is that it when I examine the fact that CCSv6 adds the C:\ti\ccsv6\ccs_base\pru\include directory as an include path in the project for you when making a new PRU project (or when making certain changes to the project properties), it almost LOOKS like the C:\ti\pru_4_0_2\include contents (including sub-dirs) should replace the .H files in the C:\ti\ccsv6\ccs_base\pru\include directory. (Note I specify only the .H files since there are other files which should undoubtedly remain.) Doing so would make the action of including that directory in the include path list correct, and make it work as intended.

    However, reading the above, I know this is in good hands and will be sorted out. Meanwhile, I have no problem with keeping an eagle eye out for C:\ti\ccsv6\ccs_base\pru\include include path being automatically added in PRU projects, and will replace such occurrences with C:\ti\pru_4_0_2\include, and C:\ti\pru_4_0_2\include\am335x. :-)

    Kind regards,
    Vic
  • Vic,

    One thing you can do is simply replace the contents of the existing pru/include directory with the files inside the include directory of the PRU support package. That is one route we are considering for future versions of CCS.

    Cheers,
    Rafael
  • Hi, Rafael!

    It certainly looks like an appropriate step. Thanks for confirming. :-)

    Kind regards,
    Vic