• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 55 subscribers
  • Views 1422 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.

PRU Compiler/Assembler v2.1.2 INTERNAL ERROR!

Prashant Nandakumar
Intellectual 810 points
Other Parts Discussed in Thread: AM5718

Hello Team,

Iam trying to port a project assembled in PASM to the PRU- compile/assembler v2.1.2

When compiling one of the sources, I run into the below issue.

Building file: ../switch_MII_Rcv.asm'
'Invoking: PRU Compiler'
"C:/ti/ccsv6/tools/compiler/ti-cgt-pru_2.1.2/bin/clpru" -v3 --include_path="C:/ti/ccsv6/ccs_base/pru/include" --include_path="C:/ti/ccsv6/tools/compiler/ti-cgt-pru_2.1.2/include" -g --define=am5718 --define=icss1 --define=pru0 --diag_wrap=off --diag_warning=225 --display_error_number --endian=little --hardware_mac=on --preproc_with_compile --preproc_dependency="switch_MII_Rcv.pp" "../switch_MII_Rcv.asm"
"../switch_MII_Rcv.asm", INTERNAL ERROR!: FB_CHECK_QUEUE_2 defined differently in each pass

This may be a serious problem. Please contact customer support with a
description of the problem and a sample of the sourcefile that caused this
message to appear.

Though this compiles fine on PASM, Iam unable to do so in the PRU assembler.

Let me know if further diagnostic information is necessary(and how to retrienve the same).

The label FB_CHECK_QUEUE_2 is uniquely defined in the source.

Please let me know if a fix/workaround is possible.

Appreciate your help!

Thanks,

Prashant.

  • 0
    TI__Guru**** 232670 points

    I suspect you are experiencing a bug in the assembler.  Please submit a test case.  In this instance, that means we need the source file switch_MII_Rcv.asm.  Hopefully, it doesn't include any other files.  But if it does, we'll need those files as well.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    TI__Intellectual 810 points

    Attached is the source file along with the related headers.

    Till we get a fix in the assembler, do let me know if there is a workaround, say by using some assembler directive.

    Thanks,

    Prashant.

    test_case.zip

  • 0 in reply to Prashant Nandakumar
    TI__Guru**** 232670 points

    Thank you for the test case.  I can reproduce the same results.  I filed SDSCM00052796 in the SDOWP system to have this investigated.  You are welcome to follow it with the SDOWP link below in my signature.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    TI__Mastermind 42550 points
    Hi,
    Any update on this bug reported ? I see that SDOWP status is still open.
  • 0 in reply to PratheeshGangadhar
    TI__Intellectual 2560 points

    No updates yet.  The issue has just been assigned to an engineer.

  • 0
    TI__Prodigy 615 points

    Hi Prashant. I'm J.B. Nagurne, the engineer assigned to this issue.

    I've determined that this error is related to forward declarations of symbols via the .set directive. The workaround is to ensure that all symbols used as sources for .set directives are defined before they are used. Specifically, I've attached a revised icss_switch.h file that fixes the error you're seeing. I also had to add definitions of TASK_EXECUTION_FINISHED and XMT_QUEUE to avoid undefined symbol errors.

    I do not consider this issue fully closed, since forward references are commonly used in hand-coded assembly and should not be causing internal errors without a good reason. However, my goal is to help get your code compiling as quickly as possible.

    icss_switch_fix.tar.gz

    Below is a more detailed analysis of the problem, if you're inclined to read it.

    In icss_switch.h, provided in your test case, I see the following definitions, copied here in the order they are found within the source file:

    Line 82: P0_BUFFER_DESC_OFFSET    .set   SWITCH_SPECIFIC_SRAM_START_OFFSET

    Line 83: EOF_48K_BUFFER_BD .set       P0_BUFFER_DESC_OFFSET + HOST_BD_SIZE + PORT_BD_SIZE

    Line 336: SWITCH_SPECIFIC_SRAM_START_OFFSET    .set ...

    Line 599: HOST_Q1_RX_CONTEXT_OFFSET    .set           EOF_48K_BUFFER_BD

    Line 640: HOST_BD_SIZE    .set ...

    Line 641: PORT_BD_SIZE    .set ...          

    The references to SWITCH_SPECIFIC_SRAM_START_OFFSET, HOST_BD_SIZE, and PORT_BD_SIZE on lines 82 and 83 are forward symbol references. The assembler is failing to fully define the symbol HOST_Q1_RX_CONTEXT_OFFSET because of these forward references. HOST_Q1_RX_CONTEXT_OFFSET is then used in the LDI on line 462 of switch_MII_Rcv.asm.

    The result is that the LDI instruction is effectively skipped as though it weren't there. This skip causes the label FB_CHECK_QUEUE_2 to be defined at some segment offset, let's say 0x0 for simplicity's sake.

    When the assembler processes the assembly code to actually encode the instructions into the resulting object file, HOST_Q1_RX_CONTEXT_OFFSET is now fully defined, and the LDI instruction is encoded correctly. This causes FB_CHECK_QUEUE_2 to be defined at a different segment offset, 0x4, which triggers an internal sanity check in the assembler to fail.