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: Watchdog test

Part Number: TMS320F28379D


Hello,
I have a question regarding the watchdog of the TMS320F28379D.

We must use the watchdog in our application. In order to fulfill a safety standard we have to test the watchdog after power on. For this reason I have implemented the _system_pre_init() routine in my software to perform this test before controller initialization (the PLL init. in the C2000 ware also uses the watchdog to check if the PLL starts properly) is done.

I have implemented the following routine at the beginning of _system_pre_init().

#define WDOG_TEST
#ifdef WDOG_TEST
                                                                                        // watchdog is active after reset
    if (CpuSysRegs.RESC.bit.WDRSn==0)   // check reset cause
    {
        SET_DIG3;                       // set test IO, start of watchdog test
        while (1)
        {
            asm("       NOP");          // wait for watchdog reset (~13ms)
        }

    }
    else                                // here reset cause watchdog
    {
        CpuSysRegs.RESC.bit.WDRSn=1;    // clear WDRSn bit
                                        // watchdog test fulfilled
    }

#endif

The macro “SET_DIG3” (#define SET_DIG3    GpioDataRegs.GPCSET.bit.GPIO66 = 1) sets the GPIO66 to check the test of the watchdog on the oscilloscope.

The routine works fine. But if you want to start the program from the debugger the DSP hangs at the NOP instruction.

Is the WDRSn bit in the RESC register not valid when the program is started from the debugger?


Thank you very much


Ralf

  • Hi Ralf,

    The routine works fine. But if you want to start the program from the debugger the DSP hangs at the NOP instruction.

    DSP stops at NOP in your watchdog routine or inside BOOTROM. Please note that when running with debugger connected, you need to set proper bootmode via EMULATION BOOT. Check if you are doing that correctly.

    Regards,

    Vivek Singh

  • Dear Vivek,
    the DSP stops in my routine.

    Now I have changed the EMU_BOOT_MODE to FLASH. After a debugger reset I have start the DSP again and then it works.


    Is it possible to change the EMU_BOOT_MODE  automatically to FLASH during the startup from the debugger?

    Thank you very much

    Ralf

  • Hi Ralf,

    Is it possible to change the EMU_BOOT_MODE  automatically to FLASH during the startup from the debugger?

    Not sure what do you mean by "startup from the debugger". When you power-up the device it'll BOOT as per the BOOTMODE pin setting but only after you connect to CCS and issue a reset, it'll boot as per the EMULATION BOOT MODE after reset. Can you explain what you are expecting after CCS is connected ?

    Regards,

    Vivek Singh

  • Dear Vivek,
    I have made more tests. The EMU_BOOT_MODE has no influence on the problem.

    The behavior is as follows:

    When the DSP works standalone everything works as expected.

    When the debug probe (XDS110) is connected and the program is flashed during the start of the debugger session first the DSP runs to the symbol _c_int00. If you press then the resume button (F8) the DSP hangs in my watchdog test routine. Then I press the suspend button (Alt+F8) and after that the system reset button in the CCS debug session. If you start then the DSP again (with the resume button) everything works. It seems to be the DSP needs a system reset in a debug session for proper operation.

    Why is the system reset necessary for correct operation?


    Thank you very much

    Ralf

  • Hi Ralf,

    After loading the code you don't have to issue reset. It should work without any issue. Did you step though the code to see where in your WD test routine DSP hangs ?

    Regards,

    Vivek Singh

  • Dear Vivek,

    after the start of the debugger session and loading the program the program counters goes to _cint00.

    If you start the DSP the program hangs in the watchdog test routine.

    At this point the programs waits for the watchdog reset, but this reset is not issued

    If you then reset the DSP and start again the DSP runs sucessfully through the watchdog test routine an the application starts.

    Best regards

    Ralf

  • Look like watchdog is disable hence it's not issuing the reset. Are you enabling the watchdog in your application?

    Also what is the entry point in your project setting. It should start at "code_start".

    Regards,

    Vivek Singh

  • Dear Vivek,
    up to now the watchdog isn´t used in my application but later on I will use it.

    Currently the watchdog is only used in the pll start routine of the C2000 ware. This routine is calles later after the watchdog test.

    I have derived the project settings from an existing example, so I think the extry point is "code_start". I have only changed the autu run option from main() to c_int00.


    Where can I check the entry point?

    Best regards

    Ralf

  • Ok, thanks. In that case entry point should be ok. You can confirm that by unchecking the Auto Run Option and then see where does CPU halts after flashing the code.

    As I mentioned, you are not enabling the watchdog in your application hence watchdog is not triggering the reset hence CPU gets stuck in while (1) loop. Watchdog gets disable in Gel file when CCS is connected. Please enable the watchdog inside your main and that should fix the issue.

    When you reset and then run the CPU, BOOTROM code gets executed which enables the watchdog before jumping to application hence it works in that case.

    Hope it fixes the issue.

    Regards,

    Vivek Singh

  • Dear Vivek,

    that solves the problem. After enabling the watchdog before the test is made it runs also with the debugger.

    Thank you very much

    Ralf