Because of the holidays, TI E2E™ design support forum responses will be delayed from Dec. 25 through Jan. 2. Thank you for your patience.

  • State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 84 subscribers
  • Views 452 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.

CCS/TMS320F280049: device stand alone run fail

Terry Deng
Intellectual 2485 points
Part Number: TMS320F280049

Tool/software: Code Composer Studio

My customer report that his last version F280049 firmware can run well on both CCS debugging and device stand-alone mode. However the new version firmware only run well on CCS debugging, but run fail on device stand-alone mode. The new version firmware just add some new variable and add some general logical operation code.   

His firmware will toggle a GPIO in the beginning of main function, when the new firmware run fail on device running stand-alone, he cannot check the GPIO action waveform, so we think the problem should happen before main function.

There is only codestartup.asm before main function and customer just use TI example file codestartup.asm without any modify. We notice the defaut setting for watchdog is enable in the codestartup.asm, so we try modify watchdog setting to disable, then new firmware resume running well on stand-alone mode. So we assume codestartup.asm running time in new firmware become longer than old firmware, and even longer than watchdog period so cause watchdog overflow reset? 

However our first problem is why new version firmware will cause the codestartup.asm running time become longer? Because the codestartup.asm just call _C_INIT lib function, we donot know what the function affection in detail before jump to main function.

The another strange that customer happen to add one "NOP" instructions in the new firmware general logical code, then the new firmware also can resume running well on stand-alone mode, no matter the watchdog setting is enable or disable in the codestartup.asm.  we can not understand the reason, does anyone solve similar case and know the possible reason?

  • 0
    TI__Guru* 87105 points

    Terry,

    All of the application's global variables are initialized by the C start up code as part of c_init routine (RTS support library function) to get them ready for use in main().

    The .cinit section in the customer application might be large. This is causing the watchdog to expire even before it is serviced.  Hence, disabling the watchdog before branching to _c_int00 in code_start.asm helped avoid the watchdog reset.  Watchdog can be enabled after reaching main.

    In debugger-connected case gel file disables the watchdog and hence no reset occurred.


    Thanks and regards,
    Vamsi

  • 0 in reply to Vamsi Gudivada
    TI__Intellectual 2485 points

    Hi Vamsi

    Thanks your advice. 

    May I know a possible max running time for _c_int00? Customer feel his variables are not too large, compare with his others project which will not cause Watchdog reset in c_init rountine. 

    And another very strange behavior as I mention at the last, customer happen to add one "NOP" instructions in the new firmware general logical code, then the new firmware can resume running well on stand-alone mode, no matter the watchdog setting is enable in the codestartup.asm. 

    It seem add one "NOP" instructions let the _c_int00 running time become shorten so that watchdog will not overflow? We cannot understand the reason? How do you think? 

  • 0 in reply to Terry Deng
    TI__Guru* 87105 points

    Hi Terry,

    Customer can profile the c_init routine using CCS profile clock feature: http://software-dl.ti.com/C2000/docs/optimization_guide/phase2.html

    They can disable watchdog and count the cycles.

    Regarding additional NOP: Where is this logical code residing (Flash start address for this function)?  And at what part of the application - in main() or before main() etc.?  Does this get executed in an ISR in the application?  Asking these questions to analyze this further.

    Thanks and regards,
    Vamsi  

  • 0 in reply to Vamsi Gudivada
    TI__Intellectual 2485 points

    Hi Vamsi

    For the question about addition "NOP", we add it as the 1st code in main(), it is residing and running on flash, but do not execute in ISR.

    Without add this "NOP", the firmware run fail while enable watchdog before _c_int00 in codestartbranch.asm, and firmware run ok while disable watchdog;

    With add this "NOP", the firmware run ok for either enable or disable watchdog before _c_int00 in codestartbranch.asm.

  • 0 in reply to Terry Deng
    TI__Guru* 87105 points

    Terry,

    Does the behavior change by adding additional NOPs (2, 3, 4, 5, 6 etc.)?

    Does the behavior change when main() is moved by a few addresses?

    Please try and let me know.

    Thanks and regards,
    Vamsi

  • 0 in reply to Vamsi Gudivada
    TI__Intellectual 2485 points

    Hi Vamsi

    Customer is busying on project development, before he spend more times to try many testing case, he hope to know any suspect for the behavior so far?

    May we get your advice what possible reasons maybe, if the behavior indeed changed by adding additional NOPs or moving main() a few addresses?   So that we can do the validation according the suspect and confirm it more quickly and efficiency.

    how do you think?

  • 0 in reply to Terry Deng
    TI__Guru* 87105 points

    Terry,

    I don't think there is anything wrong with this.  I think the watchdog timer is right around the corner to expire and adding/deleting/moving a few instructions can effect the code placement by linker and hence Flash fetches will result in more or less cycles to get to the watchdog disable or watchdog service code in main().

    Flash fetch/read bus width is 128-bit wide and fetches 128-bit aligned memory content from Flash at any time.  Depending on how the linker moves the code around, the instructions can move at the edge of the 128-bit segment causing it to slip to the next 128-bit segment, which needs the next set of wait-states to get fetched.  In other case, the instructions might be placed by linker at the front of the 128-bit segment and hence may not need extra wait-states to get to the required code.  

    It depends a lot on the pipeline/Flash prefetch/wait-states etc. to explain the exact scenario.  

    If you really want to get to the details, I can connect you to our design experts and they may ask you to provide the test case so that they can simulate and explain the behavior.

    Let me know.

    Thanks and regards,
    Vamsi

  • 0 in reply to Vamsi Gudivada
    TI__Intellectual 2485 points

    Hi Vamsi

    Thanks your advice, I discuss with customer and he basically agree your analyze. Customer will try do more test when he are free, to measure his code c_init routine period in different condition, for example original code, new code, add several "NOP" and so on.  And compare with the watchdog default expire period to validate the result. May let you know later once has some updated.    

  • 0 in reply to Terry Deng
    TI__Guru* 87105 points

    Terry,

    Sounds good. I will close this ticket for now. Once you have the update, you can reply here if the thread is unlocked OR you can open a new related thread if the thread is locked.

    Thanks and regards,
    Vamsi