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.

TMS320F28379D: Application execution after forced software reset

Part Number: TMS320F28379D
Other Parts Discussed in Thread: CONTROLSUITE,

Hello,

After issuing a forced "software reset" (through watchdog as I have seen discussed in other questions) my application stops executing but never starts again and I haven't modified any vector interrupt.

Code for reset:

volatile Uint16 temp;
EALLOW;
temp = WdRegs.WDCR.all & 0x0000;
WdRegs.WDCR.all = temp | 0x28; // write bit 6 as 0, 5:3 as 0x5, enabling watchdog
WdRegs.WDCR.all = temp | 0x20; // write bit 6 as 0, 5:3 as 0x4, enabling watchdog and forcing reset
EDIS;

Anyone knows why this could happen? I need my application to start executing again right after software reset.

Best regards,

Adria

  • Adria,

    If your application code programmed in flash (or) RAM? If it is RAM, doing a software reset would clear the RAM contents by BOOTROM.

    Where is your program stuck when you do software reset?

    Regards,
    Manoj
  • Hi Manoj,

    I am running it in FLASH. I have checked it with "Memory Allocation" view in CCS.

    I just realized it is getting reset by exception before I exec the forced software reset. It resets when I use routine "DELAY_US(1000000)" to sleep for 1 second.

    Do you know why this could happen?

    Best regards,

    Adria
  • Adria,

    If you wait for 1sec, then device watchdog will trip and reset the device. If your application demands waiting for 1sec, you need to either service the watchdog (or) disable watchdog.

    Regards,
    Manoj
  • Manoj,

    I have removed any watchdog related line of code and just have a little example.
    If I compile it with RAM cmd I have no problem with waiting for 1 sec. It only causes a reset when I compile it with FLASH cmd.
    Do you know what is going on?

    Best regards,

    Adria
  • Hello,

    I disable watchdog by executing next lines of code:

    volatile Uint16 temp;
    EALLOW;
    temp = WdRegs.SCSR.all & 0x0007;
    WdRegs.SCSR.all = temp | 0x0001;
    temp = WdRegs.WDCR.all & 0x0007;
    WdRegs.WDCR.all = 0x0068 | temp;
    EDIS;

    at the beginning of my app and then when I execute "DELAY_US()" routine execution stops and a new editor tab appears in code warrior:

    Is it possible that routine "DELAY_US()" is not being found when I run code in FLASH? Otherwise, can anyone tell me what is going on?

    Best regards,

    Adria

  • Adria,

    RAM is 0-wait state memory. Flash is not a 0-wait state memory. So, flash is relatively slower than RAM.

    Regards,
    Manoj
  • Adria,

    DELAY_US function should be running from RAM and not Flash. This DELAY_US function needs to linked to flash but run from RAM like Flash API functions.

    Regards,
    Manoj
  • Hi Manoj,

    my customer has already done what you suggested but it still doesn't work.
    He takes default command linker files for both RAM and FLASH compilation and he compiles the same example with both of them. With RAM it works perfect, but with FLASH it resets when execution reaches "DELAY_US()" routine. And after this UNWANTED reset the CPU doesn't even start again executing the app.

    Could you please advice?

    Thanks a lot for your fast reply.

    Best regards,
    Massimiliano De Cristofaro
    TI Staff Field Application Engineer - WEU
  • Massimiliano,

    Can you provide the configuration details of watchdog? Is the watchdog being serviced within 1sec? If so, at what frequency?

    Regards,
    Manoj
  • Hi Manoj,

    Please find attached the source code file (it is a very short and simple example) where you can find exactly what I do with watchdog configuration and more.

    This source code file, if executed in RAM works perfect, but if executed in FLASH it stops in the first "DELAY_US(10000000)" routine.

    Best regards,

    Adria

    //###########################################################################
    //
    // FILE:    Example_2837xDSci_Echoback.c
    //
    // TITLE:   SCI Echoback.
    //
    //! \addtogroup cpu01_example_list
    //! <h1>SCI Echoback (sci_echoback)</h1>
    //!
    //!  This test receives and echo-backs data through the SCI-A port.
    //!
    //!  The PC application 'hyperterminal' or another terminal
    //!  such as 'putty' can be used to view the data from the SCI and
    //!  to send information to the SCI.  Characters received
    //!  by the SCI port are sent back to the host.
    //!
    //!  \b Running \b the \b Application
    //!  -# Configure hyperterminal or another terminal such as putty:
    //!
    //!  For hyperterminal you can use the included hyperterminal configuration
    //!  file SCI_96.ht.
    //!  To load this configuration in hyperterminal
    //!    -# Open hyperterminal
    //!    -# Go to file->open
    //!    -# Browse to the location of the project and
    //!       select the SCI_96.ht file.
    //!  -# Check the COM port.
    //!  The configuration file is currently setup for COM1.
    //!  If this is not correct, disconnect (Call->Disconnect)
    //!  Open the File-Properties dialogue and select the correct COM port.
    //!  -# Connect hyperterminal Call->Call
    //!  and then start the 2837xD SCI echoback program execution.
    //!  -# The program will print out a greeting and then ask you to
    //!  enter a character which it will echo back to hyperterminal.
    //!
    //!  \note If you are unable to open the .ht file, or you are using
    //!  a different terminal, you can open a COM port with the following settings
    //!  -  Find correct COM port
    //!  -  Bits per second = 9600
    //!  -  Date Bits = 8
    //!  -  Parity = None
    //!  -  Stop Bits = 1
    //!  -  Hardware Control = None
    //!
    //!  \b Watch \b Variables \n
    //!  - LoopCount - the number of characters sent
    //!
    //! \b External \b Connections \n
    //!  Connect the SCI-A port to a PC via a transceiver and cable.
    //!  - GPIO28 is SCI_A-RXD (Connect to Pin3, PC-TX, of serial DB9 cable)
    //!  - GPIO29 is SCI_A-TXD (Connect to Pin2, PC-RX, of serial DB9 cable)
    //!
    //
    //###########################################################################
    // $TI Release: F2837xD Support Library v210 $
    // $Release Date: Tue Nov  1 14:46:15 CDT 2016 $
    // $Copyright: Copyright (C) 2013-2016 Texas Instruments Incorporated -
    //             http://www.ti.com/ ALL RIGHTS RESERVED $
    //###########################################################################
    
    //
    // Included Files
    //
    #include "F28x_Project.h"
    
    //
    // Globals
    //
    Uint16 i;
    
    //
    // Function Prototypes
    //
    void scib_test_init(void);
    void scib_fifo_init(void);
    void scib_xmit(int a);
    void scib_msg(char *msg);
    
    //
    // Main
    //
    void main(void)
    {
    //
    // Step 1. Initialize System Control:
    // PLL, WatchDog, enable Peripheral Clocks
    // This example function is found in the F2837xD_SysCtrl.c file.
    //
       InitSysCtrl();
    
    //
    // Step 2. Initialize GPIO:
    // This example function is found in the F2837xD_Gpio.c file and
    // illustrates how to set the GPIO to it's default state.
    //
       InitGpio();
    
    //   EALLOW;
    //   DevCfgRegs.CPUSEL5.bit.SCI_B = 1; //ASSIGN SCIB to CPU2
    //   ClkCfgRegs.CLKSEM.all = 0xA5A50001;  //Allows CPU2 bootrom to take control
    //                                            //of clock configuration registers
    //   ClkCfgRegs.LOSPCP.all = 0x0007;
    //
    // For this example, only init the pins for the SCI-A port.
    //  GPIO_SetupPinMux() - Sets the GPxMUX1/2 and GPyMUX1/2 register bits
    //  GPIO_SetupPinOptions() - Sets the direction and configuration of the GPIOS
    // These functions are found in the F2837xD_Gpio.c file.
      GPIO_SetupPinMux(70, GPIO_MUX_CPU2, 6);
      GPIO_SetupPinOptions(70, GPIO_OUTPUT, GPIO_ASYNC);
    //  EDIS;
    
    //
    // Step 3. Clear all __interrupts and initialize PIE vector table:
    // Disable CPU __interrupts
    //
       DINT;
    
    //
    // Initialize PIE control registers to their default state.
    // The default state is all PIE __interrupts disabled and flags
    // are cleared.
    // This function is found in the F2837xD_PieCtrl.c file.
    //
       InitPieCtrl();
    
    //
    // Disable CPU __interrupts and clear all CPU __interrupt flags:
    //
       IER = 0x0000;
       IFR = 0x0000;
    
    //
    // Step 4. User specific code:
    //
       i = 0;
    
       scib_fifo_init();       // Initialize the SCI FIFO
       scib_test_init();   // Initialize SCI for echoback
    
       {
           volatile Uint16 temp;
    
           //
           // Grab the clock config first so we don't clobber it
           //
           EALLOW;
    
           temp = WdRegs.SCSR.all & 0x0007;
           WdRegs.SCSR.all = temp | 0x0001;
           temp = WdRegs.WDCR.all & 0x0007;
           WdRegs.WDCR.all = 0x0068 | temp;
           EDIS;
       }
    
       scib_msg("\r\nCPU1 START!!!");
    
       DELAY_US(1000000);
    
       IpcRegs.IPCSET.bit.IPC0 = 1;
    //   while(true){}
       while(true) {
           char msg[50];
           const char str[] = "\r\nCPU1: ";
           memcpy(msg, str, sizeof(str));
           msg[sizeof(str) - 1] = i + '0';
           msg[sizeof(str)] = '\0';
           scib_msg(msg);
    
           DELAY_US(1000000);
    
           i = (9 <= i) ? 0 : (i + 1);
       }
    
    }
    
    //
    //  scib_echoback_init - Test 1,SCIB  DLB, 8-bit word, baud rate 0x000F,
    //                       default, 1 STOP bit, no parity
    //
    void scib_test_init()
    {
        //
        // Note: Clocks were turned on to the SCIB peripheral
        // in the InitSysCtrl() function
        //
    
        ScibRegs.SCICCR.all = 0x0007;   // 1 stop bit,  No loopback
                                        // No parity,8 char bits,
                                        // async mode, idle-line protocol
        ScibRegs.SCICTL1.all = 0x0003;  // enable TX, RX, internal SCICLK,
                                        // Disable RX ERR, SLEEP, TXWAKE
        ScibRegs.SCICTL2.all = 0x0003;
        ScibRegs.SCICTL2.bit.TXINTENA = 1;
        ScibRegs.SCICTL2.bit.RXBKINTENA = 1;
    
        //
        // SCIA at 9600 baud
        // @LSPCLK = 50 MHz (200 MHz SYSCLK) HBAUD = 0x02 and LBAUD = 0x8B.
        // @LSPCLK = 30 MHz (120 MHz SYSCLK) HBAUD = 0x01 and LBAUD = 0x86.
        //
        ScibRegs.SCIHBAUD.all = 0x0002;
        ScibRegs.SCILBAUD.all = 0x008B;
    
        ScibRegs.SCICTL1.all = 0x0023;  // Relinquish SCI from Reset
    }
    
    //
    // scib_xmit - Transmit a character from the SCI
    //
    void scib_xmit(int a)
    {
        while (ScibRegs.SCIFFTX.bit.TXFFST != 0) {}
        ScibRegs.SCITXBUF.all =a;
    }
    
    //
    // scib_msg - Transmit message via SCIA
    //
    void scib_msg(char * msg)
    {
        int i;
        i = 0;
        while(msg[i] != '\0')
        {
            scib_xmit(msg[i]);
            i++;
        }
    }
    
    //
    // scib_fifo_init - Initialize the SCI FIFO
    //
    void scib_fifo_init()
    {
        ScibRegs.SCIFFTX.all = 0xE040;
        ScibRegs.SCIFFRX.all = 0x2044;
        ScibRegs.SCIFFCT.all = 0x0;
    }
    
    
    //
    // End of file
    //
    

  • Hello,

    I have no problems with watchdog, I have examples which disable it and perfectly work without it as well as I also have examples which enable it and perfectly work with it.

    I also don't have problems with forced reset, I have got to reset the CPU and execute again my app (and so on).

    The PROBLEM is that when I use DELAY_US from code executed in FLASH (compiled using flash default linker command file) execution jumps to ILLEGAL_ISR routine which means illegal operation, but I don't know why. See bellow my source code:

    //
    // Included Files
    //
    #include "F28x_Project.h"
    
    //
    // Define
    //
    
    //
    // Globals
    //
    
    //
    // Function Prototypes
    //
    void Reset(void);
    void scib_test_init(void);
    void scib_fifo_init(void);
    void scib_xmit(int a);
    void scib_msg(char *msg);
    
    //
    // Main
    //
    void main(void)
    {
    //
    // Step 1. Initialize System Control:
    // PLL, WatchDog, enable Peripheral Clocks
    // This example function is found in the F2837xD_SysCtrl.c file.
    //
        InitSysCtrl();
    
    //
    // Step 2. Initialize GPIO:
    // This example function is found in the F2837xD_Gpio.c file and
    // illustrates how to set the GPIO to it's default state.
    //
        InitGpio();
    
    //
    // For this example, only init the pins for the SCI-A port.
    //  GPIO_SetupPinMux() - Sets the GPxMUX1/2 and GPyMUX1/2 register bits
    //  GPIO_SetupPinOptions() - Sets the direction and configuration of the GPIOS
    // These functions are found in the F2837xD_Gpio.c file.
        GPIO_SetupPinMux(70, GPIO_MUX_CPU2, 6);
        GPIO_SetupPinOptions(70, GPIO_OUTPUT, GPIO_ASYNC);
    
        EALLOW;
        DevCfgRegs.CPUSEL5.bit.SCI_B = 0;
        EDIS;
    
    //
    // Step 3. Clear all __interrupts and initialize PIE vector table:
    // Disable CPU __interrupts
    //
        DINT;
    
    //
    // Disable CPU __interrupts and clear all CPU __interrupt flags:
    //
        IER = 0x0000;
        IFR = 0x0000;
    
    //
    // Initialize PIE control registers to their default state.
    // The default state is all PIE __interrupts disabled and flags
    // are cleared.
    // This function is found in the F2837xD_PieCtrl.c file.
    //
        InitPieCtrl();
    
    //
    // Initialize the PIE Vector Table To a Known State:
    // This function is found in F2837xD_PieVect.c.
    // This function populates the PIE vector table with pointers
    // to the shell ISR functions found in F2837xD_DefaultIsr.c.
    //
        InitPieVectTable();
    
    //
    // Enable CPU and PIE __interrupts
    // This example function is found in the F2837xD_PieCtrl.c file.
    //
        EnableInterrupts();
    
        {
            //
            // Grab the clock config first so we don't clobber it
            //
            EALLOW;
    #if WDG_ENABLED == 1
            WdRegs.WDCR.all = 0x002F; /* Watchdog enabled */
    #else
            WdRegs.WDCR.all = 0x006F; /* Watchdog disabled */
    #endif
            WdRegs.SCSR.all = 0x0000;
            WdRegs.WDKEY.all = 0x0055;
            WdRegs.WDKEY.all = 0x00AA;
            WdRegs.WDCNTR.all = 0x00FF;
            EDIS;
        }
    
    //
    // Step 4. User specific code:
        scib_fifo_init();       // Initialize the SCI FIFO
        scib_test_init();   // Initialize SCI for echoback
    
        uint16_t i = 0;
        scib_msg("\r\nCPU1 START!!!");
        while (true)
        {
            {
                char msg[50] = "\r\nCPU1: ";
                msg[sizeof("\r\nCPU1: ") - 1] = i + '0';
                msg[sizeof("\r\nCPU1: ")] = '\0';
                scib_msg(msg);
            }
            DELAY_US(1000000);
            if (9 <= i) Reset();
            else i++;
        }
    }
    
    //
    // IssueSCCReset - This function will generate SCC Reset for the specified
    //                 CPU timer instance number
    //
    void Reset(void)
    {
        volatile Uint16 temp;
        EALLOW;
        //Grab the clock config so we don't clobber it
        temp = WdRegs.WDCR.all & 0x0007;
        WdRegs.WDCR.all = temp | 0x28; // write bit 6 as 0, 5:3 as 0x5, enabling watchdog
        WdRegs.WDCR.all = temp | 0x20; // write bit 6 as 0, 5:3 as 0x4, enabling watchdog and forcing reset
        EDIS;
        while (true)
        {
    //        DELAY_US(1000000);
            asm(" NOP");
        }
    }
    
    //
    //  scib_echoback_init - Test 1,SCIB  DLB, 8-bit word, baud rate 0x000F,
    //                       default, 1 STOP bit, no parity
    //
    void scib_test_init()
    {
        //
        // Note: Clocks were turned on to the SCIB peripheral
        // in the InitSysCtrl() function
        //
    
        ScibRegs.SCICCR.all = 0x0007;   // 1 stop bit,  No loopback
                                        // No parity,8 char bits,
                                        // async mode, idle-line protocol
        ScibRegs.SCICTL1.all = 0x0003;  // enable TX, RX, internal SCICLK,
                                        // Disable RX ERR, SLEEP, TXWAKE
        ScibRegs.SCICTL2.all = 0x0003;
        ScibRegs.SCICTL2.bit.TXINTENA = 1;
        ScibRegs.SCICTL2.bit.RXBKINTENA = 1;
    
        //
        // SCIA at 9600 baud
        // @LSPCLK = 50 MHz (200 MHz SYSCLK) HBAUD = 0x02 and LBAUD = 0x8B.
        // @LSPCLK = 30 MHz (120 MHz SYSCLK) HBAUD = 0x01 and LBAUD = 0x86.
        //
        ScibRegs.SCIHBAUD.all = 0x0002;
        ScibRegs.SCILBAUD.all = 0x008B;
    
        ScibRegs.SCICTL1.all = 0x0023;  // Relinquish SCI from Reset
    }
    
    //
    // scib_xmit - Transmit a character from the SCI
    //
    void scib_xmit(int a)
    {
        while (ScibRegs.SCIFFTX.bit.TXFFST != 0)
        {
        }
        ScibRegs.SCITXBUF.all = a;
    }
    
    //
    // scib_msg - Transmit message via SCIA
    //
    void scib_msg(char * msg)
    {
        int i;
        i = 0;
        while (msg[i] != '\0')
        {
            scib_xmit(msg[i]);
            i++;
        }
    }
    
    //
    // scib_fifo_init - Initialize the SCI FIFO
    //
    void scib_fifo_init()
    {
        ScibRegs.SCIFFTX.all = 0xE040;
        ScibRegs.SCIFFRX.all = 0x2044;
        ScibRegs.SCIFFCT.all = 0x0;
    }
    
    //
    // End of file
    //
    

    Best regards,

    Adria

  • Adria,

    When reset function gets executed, it enables watchdog and forces as WD reset by writing wrong key value in WDCR register using below statement

    WdRegs.WDCR.all = temp | 0x20; // write bit 6 as 0, 5:3 as 0x4, enabling watchdog and forcing reset.

    Forced WD reset will trigger DCSM (code security) and subsequent instruction following above instruction "EDIS" is triggering illegal ITRAP because device gets secured. So, instead of executing opcode of EDIS, it executes 0x0000 that is the reason for illegal itrap.

    Regards,
    Manoj
  • Manoj,

    In my last answer I said that I had no problem with neither watchdog nor forced reset. So when I execute the line you are saying device successfully resets and my app starts running again from the beginning. This is possible because I execute a CCS script right in the moment when m app start executing. The script is in "scripts - EMU Boot Mode Select - EMU_BOOT_FLASH".

    My actual problem is neither about watchdog nor about forced reset. MY ACTUAL PROBLEM IS with "DELAY_US()" routine because when I call it executing my app in FLASH then execution jumps to ILLEGAL_ISR. If I call it executing my app in RAM I have no problem, it works perfect.

    So, could you please explain me why this is happening when I execute my app in FLASH and propose me a solution?

    Thanks in advance.

    Best regards,

    Adria

  • Hi Manoj,

    could you please answer the last post of Adria?
    Any suggestion please?

    Thanks a lot in advance.

    Best regards,
    Massimiliano
  • Adria,

    I'm currently busy working on important project. I will try to find sometime and try to get back to you in next 3 - 4 business days.

    Regards,
    Manoj

  • Adria,

    Please change your reset function as shown below. I have just added "repeat NOP" statement immediately after watchdog force reset. This will ensure that watchdog force reset propagates properly whether code is executed from RAM (or) Flash. Since RAM is a 0-wait state and Flash not a 0-wait state the behavior of code when executed from RAM is slightly different from flash. Adding this repeat nop will make the behavior similar for both RAM / flash.

    void Reset(void)

    {

       volatile Uint16 temp;

       EALLOW;

       //Grab the clock config so we don't clobber it

       temp = WdRegs.WDCR.all & 0x0007;

       WdRegs.WDCR.all = temp | 0x28; // write bit 6 as 0, 5:3 as 0x5, enabling watchdog

       WdRegs.WDCR.all = temp | 0x20; // write bit 6 as 0, 5:3 as 0x4, enabling watchdog and forcing reset

       asm(" RPT#255||NOP");

       EDIS;

       while (true)

       {

    //        DELAY_US(1000000);

           asm(" NOP");

       }

    }

    Regards,

    Manoj

  • Hello Manoj,

    It has already been (at least) 3 posts asking you something and getting a response (from your side) which has NOTHING to do with it, although I have been specifically saying (in each of my last posts) that what you mentioned in your answers is not a problem for me: I DON'T HAVE A PROBLEM NEITHER WITH RESET NOR WITH WATCHDOG --> please, forget about RESET and WATCHDOG.

    MY ONLY PROBLEM IS: when I execute "DELAY_US()" in app running on FLASH, then code immediately jumps to ILLEGAL_ISR(). As when I execute "DELAY_US()" in app running on RAM this doesn't happen (it works OK), I would like to be able to call "DELAY_US()" in app running on FLASH. I am using default linker command files (provided in controlSUITE).

    Best regards,

    Adria
  • Adria,

    When you are executing code from flash, a forced WD reset causes the flash to read 0x0000's. When CPU fetches 0x0000's it recognizes it as illegal instruction. So, it jumps to illegal_isr function.

    When you are executing code from RAM, a forced WD reset doesn't affect the RAM contents. So, you don' see the problem. The difference in behavior is because WD resets hasn't properly propagated to the whole device and it just happened to affect flash and not RAM. This change in behavior can be avoided by using repeat NOP instruction immediately after forced reset.

    I modified the reset function code attached in my previous post and didn't the illegal_isr problem whether I executed your code in flash (or) RAM.

    Regards,
    Manoj
  • Manoj,

    You still have not understood the problem.

    Just forget about it because it has already been solved in another question I asked yesterday (it is called "TMS320F28379D: DELAY_US routine jumps to ILLEGAL_ISR when app running in FLASH").

    Best regards,

    Adria
  • Adria,

    Can you post the link of the other thread you are talking about? I'm curious what I missed and what was the problem and solution.

    Regards,
    Manoj
  • Hello Manoj,

    Yes of course:

    e2e.ti.com/.../746912

    Best regards,

    Adria