Compiler/TMS320F28069: /tmp Build Error with boot28.inc

I think the discussion in this thread will be helpful.

Thanks and regards,

-George

You need to set the CCS source search path to include the library source directory. This is $(compilerroot)/lib/src, and is present for releases since C2000 6.1.6. This is supposed to happen automatically. What version of the compiler is the user using? (Note: this is not the same as the CCS version.)

Thanks George,

You know...I did a quick search on boot28.inc but did not find this one thread.

Yes, this is what they are looking for. Glad to see it already documented...makes it easy to share.

Thanks again,
Chris

Customer has properly added $(compilerroot)/lib/src in their CCS source search, however, the error is still showing.

Other thoughts?

TY,
CY

What version of the compiler is the user using? (Note: this is not the same as the CCS version.)

Sorry, meant to include that in the last post.  They are telling me they are using v6.2.0 compiler.  I know that's also a CCS version # but it appears by the path the C2000 compiler is in fact 6.2.

Comments welcomed, of course.

Thanks Archaeologist Indiana Jones!

-CY

The "lib/src" directory is not present on the 6.2.x branch until 6.2.4. The customer will need to upgrade to that version or greater to automatically see the library source code.

Alternately, the customer could go into the lib directory and unpack rtssrc.zip into the lib/src directory.

Gotcha! OK that should do it then. Sounds like a plan. Sorry I didn't catch that (version #) earlier today when you replied to the thread.

Thanks Archaeologist!

-CY

Arch,

The customer is running 6.2.11 - I assume the near "November" release update - but still sees the same error after clicking 'debugging'.  Is something else going on here?

Thanks,

Chris

If you mean the error "Can't find a source file at /tmp/TI_MKLIBr6S4KF/SRC/boot28.inc", I cannot explain it. C2000 compiler version 6.2.11 does ship with lib/src/boot28.inc as a flat file, so if the CCS source search path is set correctly (this should be automatic), the user should be able to see that source file in the debugger. Have the user check that the file exists on disk, that CCS is in fact using version 6.2.11 for that project, and that the CCS source search path includes the lib/src directory.

If you mean the error where the PC is off in the weeds, we haven't seen any details that would help us diagnose that issue.

Archaeologist,

If they manually locate the missing files …args_main.c and …boot28.c, the problem is gone. Please see the attachment.

But the illegal_ISR problem is still there.

Any further comments?  Thanks!

-CY

Archaeologist,

If they manually locate the missing files …args_main.c and …boot28.c, the problem is gone.   Please see the attachment.

But the illegal_ISR problem is still there.

Any further comments appreciated!

-CY

Okay, so the source code is present on disk, but it seems that perhaps the automatic method to find it isn't working?  Frankly, I don't think I can further diagnose this problem.  The compiler (C2000 version 6.2.11) is fulfilling its end of the interface, so there's probably nothing more we can do for that issue on the compiler forum.  If the user needs to pursue this issue, I would recommend making a new post in the CCS forum.

As to the interrupt:

1.    Does the user's program attempt to read argc or argv, the arguments to main?
2.    Which interrupt is is handled by Illegal_ISR?  Look at the the interrupt vector table.

I completely understand and agree with you on the compiler stuff. FYI: The search path is still referring to the 6.2.0 lib/src directory. They only locate the src directory of 6.2.11 after the error "Can't find a source file at /tmp/TI_MKLIBr6S4KF/SRC/boot28.inc" pops up. ( They may change it to 6.2.11 if there is no new errors ).

And yes, both 6.2.11 and 6.2.0 src directory exist on disk.

For the Interrupt:
1. No, it does not.
2. The Illegal_ISR could be handled by any of the functions A0, B0,C0, A1,B1 in the HVLLC-Main. It is not certain and they are still tracking it.

Thanks,
CY

Archaeologist,

Here's an accompanying screenshot on the first question, boot28.inc:

And...just to correct the information for the second question (INT):

No interrupt is handled by ISR-ILLEGAL since it is empty except for a ESTOP0 command and a for loop.

Again, any comments more than welcomed!

TY,
CY

Regarding the issue where CCS cannot find the source code of the RTS boot routine ...  Please see the section of this wiki article titled Debugging Library Code.

Thanks and regards,

-George

Thank you for sharing.  Do you have any insight on the Illegal_ISR error as well George?

Thank you,

Chris

When I say "which interrupt is handled by ISR_ILLEGAL," I don't mean what functionality in the program is performed by ISR_ILLEGAL, I mean which interrupt vector slots have the value ISR_ILLEGAL. You've shown us PieVectTableInit, which is clearly filling 116 slots of the PieVectTable with the value ISR_ILLEGAL. This means that ISR_ILLEGAL is the interrupt handler for all 116 distinct interrupts.

Your system has apparently received a PIE interrupt. We need to determine which one. There are twelve PIEIFR registers, one for each CPU interrupt used by the PIE module (INT1−INT12). Please show us the values of PIEIFR1 through PIEIFR12

Please see SPRU078, "TMS320C8x System and Interrupts Reference Guide"

Also see processors.wiki.ti.com/.../Interrupt_Nesting_on_C28x

Archaeologist,

To continue with the ISR_ILLEGAL issue discussion, I have attached the values of INT1 to INT12 from the customer.

Thank you for your input.  Let me know your thoughts please.

-CY

That's the IFR register. INT14 for instance is one bit. We need to see the PIEIFR registers, which are related to but separate from the IFR flags.

Oops, that was my fault.  Here it is.  Sorry about that.

Okay, notice that PIEIFR3 is 0x1, and PIEIER3 is 0x9. This means that the user just got PIE interrupt INT3.1, which is (if I'm not mistaken) EPWM1 (see SPRUHM8E section "PIE Channel Mapping".) The interrupt vector slot for PIE interrupt INT3.1 is 0x0D60. What interrupt handler has the user installed to catch PIE interrupt INT3.1? What is the 32-bit value at address 0xD60?

Archaeologist,

I am sorry for this long delayed reply from the customer due to some other issues.

First off, you are right though, as this address (INT3.1) is referring to EPWM1.  They have checked the 32-bit value at address 0xD60 and it is 32810.  But they don’t think this is the real reason that is causing the Illegal_ISR.  The EPWM1 does an event trigger when counter=0, but the event flag ETFLAG ( please refer to ETFRC typo attachment) is cleared in the subroutine of EPWM4.  The sample asm code doing “clear flag” in EPWM4 was commented in the (I don’t why…..). The IFR and IER should be cleared after putting the asm code back.  Also, do you think there could be a typo in the event-trigger interrupt generator (refer to the last attachment)?

Also, if they click the “Restart” in the debugging tool bar, the code will not trap into the Illegal_ISR.  Do you have insight into this?

TY,

CY

-----

Hi Chris,

I can confirm that is a typo in the second figure. The fix will show up when the F2806x TRM is released next.

The CTRU=CMPB line should have a value of 110

Regards,

Kris

Hi Kris & All,

Understood. Thank you for your confirmation. However, even with the correct configuration (of CTRU=CMPB) the customer finds that even restarting the program in the debugging mode will not make the code trap into the Illegal_ISR as expected.

Thoughts?

TY,
CY

Kris and team,

I am visiting this customer Friday. Can you comment prior to that please?

Thanks,
Chris

Archaeologist,

Thank you very much. We met with the customer face-to-face last Friday and explained your input. They are satisfied for now. Case closed.

Thanks again,

CY

Chris,

Just confirming, does the illegal ISR issue need to be further investigated at this time or is that issue closed now?

Regards,

Kris