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