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/TMS320F28377D: STRANGE BEHAVIOURAL ISSUE IN FLASH_STANDALONE EXECUTION [28377D]

Part Number: TMS320F28377D

Tool/software: Code Composer Studio

Hi.

I’m struggling with a strange issue when I execute CPU1&CPU2 (28377D) code in Flash Standalone mode. I could say with certainty that code, in particular its functional power behaviour (complex modular ups), works well either in RAM and FLASH debug session if I start them with emulator. Consider that code is loaded, mainly except the configuration initial function, from flash to ram because PWM interrupt/CLA and background task have a critical timing: I want to execute code after bootstrap from reset, possibly, in the same way done in RAM debug session. So, I modify my .cmd linker file to load, by memcpy function, code in RAM and if I check that in FLASH session, when I’m going step-by-step in disassembly window, I can see correct opcode RAM address consistently with .map file and linker section. I know my harder job in explaining the boundary condition of my issue because I use CLA, IQmath and a lot of peripheral in a large code with complex interaction between CPU1/CPU2).

By the way, I try to identify a strategy to found a behavioural culprit through the use of an HW test point (TP) and oscilloscope and so I can tell you that the problem is only about CPU2 (inverter/static switch code): unfortunately, flash standalone code execution forces me to be kept in the dark about internal event. So, I tracing the PWM interrupt by putting my toggling TP (low-high L/H edge at the begin of interrupt and H/L edge in different place of interrupt function) moving forward step-by-step in the interrupt code. I notice that RAM/FLASH session and FLASH_STANDALONE session, with bootstrap event from reset, have the same behaviour (time high level duration and H/L gitter edge) until I’m going to come in the first IQNmpy fuction (I know that is a macro that use the intrinsic function __IQmpy(A,B,n); in fact, in .map file I can see only IQ19int.obj and IQ16int.obj object linker using as result of a good loading of IQmath library): it’s like the FLASH_STANDALONE execution code was more short; while RAM/FLASH code generate correct PWM activity (power control loop), in FLASH_STANDALONE mode this activity is absent (ePWM reg refresh are closest the end of interrupt). Of course, if I put my TP closest end of interrupt I can see the H/L edge also in FLASH_STANDALONE session (this occur first and without gittering than the other good session). Also, if there was any issue with bad function allocation an ITRAP will occur preventing a lot of different observable activity (board CPU led blinking, external communication, etc.).

Finally, I ask you a confirmation if intrinsic function like IQmpy was treated by compilator/linker independently than IQmath.lib (in FLASH mode I saw assembler code IQMPY loaded in RAM as expected) also when I try to bootstrap code by FLASH from reset (FLASH_STANDALONE mode). Furthermore, is it any issue that can justify this different behaviour (FLASH/FLASH_STANDALONE) since in the second case I suffer of possibility of data lost event caused by reset ? Consider that I use an Init function in FLASH to init all CPU2 loop variables and I can see also a correct initialization of global var (cinit) by a software (console) connected with my developed DualDSPboard (FW vers., etc.).

Thanks a lot for your help.

Diego

  • Hi Diego,

    I am not able to completely understand the issue you are facing. Can you please explain with some capture or memory screen shot?

    Also can you clarify couple of questions to assist you better:

    1. Are you seeing issue with IQmpy function when you execute the code from RAM or Flash?

    2. Are you saying that when you execute the code from Flash as Standalone, IQmpy function does not execute, and you do not see any toggle activity?

    Regards,

    Nirav

  • Hi Nirav and thank for your support.

    I apologize to you for my bad english if I given rise to misunderstanding.

    1) I don't think there will be an issues with flash IQmpy assembler instruction execution in FLASH or particular in 2) FLASH_STANDALONE mode. While I controlling my code execution, step-by-step in FLASH debug session, I notice that same critical function (TI rts/peripheral function used) was loaded and ran in FLASH causing problem with timing execution (interaction between background task & many interrupt). I try to load all no init begin function in FLASH and all the rest one developed in RAM for a timing execution as similar as possible like in RAM debug session started by ccs/xds emulator. So, for now is a little hard for me and a waste time for you if I starting to attach screen shoot of pieces of memory/disassembly window.

    I hope to found a way to tell a linker (.cmd file) how load from flash and run in ram .TI.ramfuncs in the case of specific object file (.obj) beloging rts library (rts2800_fpu32.lib) about .text section like just I doing for my critical time code (memcpy using etc.). Meanwhile I'm studying and doing a debug test for this task.

    I ask you detail, in the future, if necessary. Thanks a lot.

    Diego

  • Hi Diego,

    Looks like you have found a way around the issue. Sure, let us know if you need any assistance in future. For now I will go ahead and close this thread.

    Thanks,

    Nirav

  • Hi Nirav.

    Finally, I found the wonder solution: FLASH_STANDALONE code now run like in RAM Debug Session with the same time behavioural execution. In a few word, I adapt my linker file .cmd to load all code from FLASH to RAM, also rst library function used or third library OBJ module. Moreover, I check in dept all function call both in C and in assembler code (for all symbol created by linker) to make sure that in the end it will work good.

    This is the snipet linker directives used:

       /* Allocate program areas [PAGE0]: */
       .cinit           : > FLASHB      				PAGE = 0, ALIGN(4)
       .pinit           : > FLASHB,     				PAGE = 0, ALIGN(4)
    
       #if __TI_COMPILER_VERSION__ >= 15009000
       .DB.ramfunc 		: {}
    						 LOAD = FLASHH | FLASHJ,
    						 RUN = RAMGS0TO5,
    						 RUN_START(_RamLoopRunStart),
    						 LOAD_START(_RamLoopLoadStart),
    						 LOAD_SIZE(_RamLoopLoadSize),
    					 	 PAGE = 0, ALIGN(4)
       #endif
    
       #ifdef __TI_COMPILER_VERSION__
       #if __TI_COMPILER_VERSION__ >= 15009000
       .TI.ramfunc 		:        {
       						 rts2800_fpu32.lib<fd_mpy28.asm.obj>(.text)
       						 rts2800_fpu32.lib<fd_add28.asm.obj>(.text)
       						 rts2800_fpu32.lib<fd_sub28.asm.obj>(.text)
     						 rts2800_fpu32.lib<fd_tol28.asm.obj>(.text)
     						 rts2800_fpu32.lib<i_div28.asm.obj>(.text)
     						 rts2800_fpu32.lib<u_div28.asm.obj>(.text)
    						 rts2800_fpu32.lib<u_tofd28.asm.obj>(.text)
    						 rts2800_fpu32.lib<l_tofd28.asm.obj>(.text)
    						 rts2800_fpu32.lib<ll_aox28.asm.obj>(.text)
       					  }
    						 LOAD = FLASHH | FLASHJ,
    					 	 RUN = RAMGS6,
    						 RUN_START(_RamfuncsRunStart),
    						 LOAD_START(_RamfuncsLoadStart),
    						 LOAD_SIZE(_RamfuncsLoadSize),
    					 	 PAGE = 0, ALIGN(4)
       #else
       ramfuncs 		:	 LOAD = FLASHH | FLASHJ,
    					 	 RUN = RAMM0,
    						 RUN_START(_RamfuncsRunStart),
    						 LOAD_START(_RamfuncsLoadStart),
    						 LOAD_SIZE(_RamfuncsLoadSize),
    						 PAGE = 0, ALIGN(4)
       #endif
    
       .text            : >> FLASHB | FLASHC | FLASHD | FLASHE, PAGE = 0, ALIGN(4)

    Bye.

    Diego

  • Diego,

    Glad that you are able to execute fine now in standalone mode.

    While you are at editing your linker cmd, I would suggest you do one more thing:  Please reserve the last 16 addresses of the Flash bank and do not map any section to those locations.  This is to avoid ECC errors and/or ITRAPs that may occur due to prefetch mechanism fetching beyond implemented Flash memory.

    Thanks and regards,
    Vamsi

  • Diego,

    Please follow your latest post at https://e2e.ti.com/support/microcontrollers/c2000/f/171/p/857382/3170881#3170881

    I am closing this post.

    Thanks and regards,
    Vamsi