• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 53 subscribers
  • Views 1000 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Compiler: PRU Compiler: PRU Compiler 2.1.5 : Discrepancy in the number of instructions generated in the listing file using (--asm_listing) & the binary file (.b00) generated by hexpru.exe tool

Garvit Jain
Prodigy 100 points

Tool/software: TI C/C++ Compiler

Hi

I am compiling my CLPRU firmware using PRU Compiler 2.1.5 and I see that the generated firmware header has certain block of instructions repeated which shouldn't ideally be there. How can I be sure? Because the generated listing file using (--asm_listing) doesn't account for these instructions. Further, the file containing the repeating instructions is under an if def as shown it should feature only once in the firmware headers, right?

.if !$defined(file)
file .set 1

..

block of instructions

..

.endif ; file

I generate the binary file .b00 using the hexpru.exe tool included in the PDK package & even this shows the extra block of instructions.

Improper firmware header files is badly affecting my application performance.Can somebody suggest a fix for this issue?

  • 0
    TI__Prodigy 100 points

    I have got an update here as follows. The problem seems to be fixed, but I would like to know how. One of my .asm file was being accessed via .copy from the main file. Also the same file was included into the project via -ccs.linkFile command.

    When I tried to right click on the file name & select "Exclude from build", it resolved the above mentioned issue.

    So I would like to know what exactly I was doing? And how it got resolved by the above change?

  • 0 in reply to Garvit Jain
    TI__Guru**** 244300 points

    I'm not completely certain.  But it appears you effectively had one file in the project two times.  First, as a typical source file in the project.  Second, it is included within a different typical source file in the project via the .copy directive.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    TI__Prodigy 100 points
    Correct. Since this behavior doesn't flag any errors or warnings, it is very difficult to debug. If possible, I would like to place a requirement for the compiler to issue a warning in this case.
  • 0 in reply to Garvit Jain
    TI__Guru**** 244300 points

    Garvit Jain said:
    If possible, I would like to place a requirement for the compiler to issue a warning in this case.

    Unfortunately, it's not possible.  The assembler is the tool which processes the .copy directive.  When that occurs, the assembler does not know how it has been invoked.  From CCS, a makefile, the command line, something else?  Therefore, there is no way to know whether the file given in the .copy directive is part of the larger project.

    Thanks and regards,

    -George