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/TMS320F28379D: Undesired reset of the CPU1 while CPU2 keeps running

Part Number: TMS320F28379D

Tool/software: Code Composer Studio

Hi,

I am using this microcontroller to control two power converters, each one with each CPU and its CLA. The CPUs are in charge of the communications and the state machine, while the CLAs execute the control loops of the converters.

My problem is that the CPU1 resets itself without order or apparent cause, but the CPU2 does not reset. Firstly, I programmed everything in both RAMs, and I was able to know that CPU1 reset because it returned to main () (before the while(1)) and it tried to run the program again and when it reached the EINT; instruction it reset again and again. I took a look into the RESC register and the only bit set (apart from the TRSn and XRSn bits) was the WDRSn, but I never configured the watchdog, indeed I always disable it. Then, I realized that sometimes when a program the microcontroller this bit is set from the beginning. I also took a look into the NMIFLG register of the CPU2 but everything seemed fine, all the bits were cleared. The problem was random, maybe one day it happened two times and the next two did not happen. I have to say also, that the problem always happen when the converter was running, it has never happened when the converter was in standby without switching. Could it be something related with electromagnetic interferences?

Having all these problems and thinking that it was due to a problem in the .cmd, I changed it and now I am programming in FLASH but this time the problem is a little different because CPU1 loses control and it seems that it has no program. At some time, when switching and testing the converters, it luckily open the switches, but its output GPIOs start to change constantly; and moreover, when I am debugging, all the variables have random values changing constantly and when I try to stop the program to know what is happening, the CCS says that there is no symbol in this CPU. What may the problem be? Could it be some power supply error? 

I always debugged the code without the Real-time mode. I tried to debug enabling it, but the code stopped and I got the error -1142 (see the image below).This time, the converter stopped in an unwanted and dangerous way, and I decided not to try to repeat the error. 

Best regards, 

Lucas B.

  • Hi Lucas,

    On this device, CPU2 always gets reset when CPU1 gets reset. So if you are not seeing CPU2 getting reset then it could be that CPU1 is also not getting reset but for some reason jumping to main. Have you tried setting the breakpoint at BOOTROM entry point for CPU1 and CPU2 to see if it halts there (and not on main) ?

    Regards,

    Vivek Singh

  • Hi Vivek, 

    Thank you for the response. Good to confirm that if the CPU1 resets, CPU2 does.

    What may it make the program jump to the main? 

    No, I have not tried setting a breakpoint at BOOTROM, but when I was using only the RAM memory, all the variables seemed to be reset to their initial value (defined when the variables are declared). The problem using the FLASH is that the program seems to disappear, all the variables start to change their value, and when I try to stop the code, the CCS says that there are no symbols. 

    Regards,

    Lucas B.

  • It could be reset only and even CPU2 is getting reset. After reset if you have not set the emulation boot properly then device will not jump to your flash code. It'll remain in BOOTROM hence you see the message that there is no symbol. Please set the emulation boot properly then it should jump to you code in flash. Also on WD reset, all the RAMs get cleared on this device so if your running the code from RAM and a WD reset happens, it'll clear all the RAMs so no valid code will be there after reset.

    Regards,

    Vivek Singh

  • Hi Lucas,

    Any further update on this issue?

    Regards,

    Vivek Singh