• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 82 subscribers
  • Views 424 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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/TMS320F28069: Unexpected behavior with code addition

_Lina
Expert 3305 points
Part Number: TMS320F28069

Tool/software: TI C/C++ Compiler

Team,

I’m hoping that you can give me some guidance on an issue that is very similar to what is described here:

https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/405784

But obviously based on a newer version of CCS (my guess is 6.x but I can confirm).

When we integrate some new functions into the code, and don’t even call those functions, it causes some CLA tasks to not operate (i.e. not trigger interrupts when they’re done). When we remove the new segment and rebuild/load, the problem is gone. Also, when we remove random parts of the code it seems to work as well.  I have linker and map files that I can share offline, but nothing stands out as problematic. RAML2 is the only part that changes and it seems .ebss and .esysmem are allocated there, but there is still plenty of unused space.

Can you provide any guidance on potential compiler bugs or red flags that I should look for in the code?

Best,

  • 0
    TI__Mastermind 20850 points
    Lina,

    On the 28069, the CLA code needs to be in RAML3, while CLA data sections can go into RAML0,L1,L2. Are you assigning Cla1Prog exclusively to RAML3? Does the new code somehow move the CLA sections around. I would do a diff of the map files before and after the code change and see how the CLA sections are affected.
  • 0 in reply to Vishal_Coelho
    TI__Expert 3305 points
    Hi Vishal,

    I appreciate the quick response.

    The Cla1Prog is exclusively tied to RAML3, while data sections are in RAML1. .scratchpad is in RAML1 as well.

    The origin of CLAProg1 does change between the working map file and the non-working map file, specifically from 003ea0fa to 003ea1ec (same length, run address and object files). Could you help me understand what this means and how it could be affecting the program?

    Best,
    Lina
  • 0
    TI__Mastermind 20850 points

    Hi Lina,

    The load address is moved around in sector G and that shouldn't cause any problems. The memcpy should work just fine.

    Could you send me the before and after .map, .cmd files offline. Let me see if i can figure out what is going on. 

  • 0
    TI__Expert 3305 points
    This issue has been resolved.

    The cause was related to the F28069 CLA default interrupt trigger values that was causing an erroneous interrupt with an unused task i.e. PERINT2SEL = ADCINT2 on reset. Meaning, if you initialize the peripherals (i.e. ADC) before you initialize the CLA, there could be an ADC interrupt flag waiting which will be serviced by the CLA, which might cause unwanted behavior.

    Solution is to (in general):
    1. Initialize CLA before peripherals such as ADC and PWM modules
    2. After setting PERINTxSEL registers in cla_init(), clear the current interrupt flags in the system before enabling CLA interrupts (MIER).

    NOTE: These characteristics don't apply to some newer devices that reset to software triggers rather than ADCINTx.

    This will be documented in the TRM.

    Thanks Vishal!