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.

Debugging watchdog on TMS570

Other Parts Discussed in Thread: TMS570LC4357, HALCOGEN

Hello,

I have problems with debugging watchdog on TMS570LC4357 MCU. It seems that COS (continue on suspend) bit is ignored.

This is what I do:

   /* clear violations, assign window size, preload and reaction */
1. dwwdInit(rtiREG1, Generate_Reset, dwdPreload, Size_100_Percent);

   /* clear continue on suspend bit */
2. rtiREG1->GCTRL &= ~((uint32_t)(1U << 15U));

   /* assign 0xA98559DAU to DWD CTRL */
3. dwdCounterEnable(rtiREG1);

4. rtiREG1->WDKEY = 0x0000E51AU;
5. rtiREG1->WDKEY = 0x0000A35CU;

The problem is that lines 4. and 5. are not reachable using breakpoints or by stepping over line 3. (reset on target occurs).

I am using XDS200 debugger. Preload is set to 7ms (RTICLK is 75MHz and preload value is 63).

Is there someting I'm missing? Thanks for your help.

  • Piotr,
    In lines 4 and 5, do you want rtiREG or rtiREG1?
    Best Regards,
    Kevin Lavery
  • Kevin,
    I've just corrected. It is rtiREG1.

  • Piotr,
    Did this change your fail signature? Is this a post-problem or a code-problem?
    Best regards,
    Kevin Lavery
  • It was only post problem. I just copied content of Halcogen generated 'void dwdReset(rtiBASE_t *rtiREG)' function, which I call with rtiREG1 parameter.
  • Piotr,
    OK. I will have to work through this problem.
    Best regards,
    Kevin Lavery
  • Thank you,

    In case you need any further information, let me know. I think that the code that I enclosed is enough to reproduce it on the TMS570LC4357 target.

    Piotr

  • Piotr,
    When you step over line 3 (dwdCounterEnable(rtiREG1);), you do not start the counter. I have seen a failure in this case because the counter has not started and therefore the window is not open; in this case, RTIWDSTATUS gives me a value of 0x28, indicating that the value was written prior to the window opening.
    Can you send the RTIWDSTATUS for the failure you are dealing with (offset 0x98)?

    Best regards,
    Kevin Lavery
  • Kevin,
    RTIWDSTATUS in my case is equal to 0x32, so it indicates End Time violation.

    Best regards,
    Piotr
  • Piotr,
    I am working through the details, so I don't have an answer quite yet. However, I know now that you are correct, the SUSPEND signal is not getting to the RTI/DWD. I am finding the sequence to allow that.
    Best Regards,
    Kevin Lavery
  • Piotr,

    If you add the following set of writes, it will configure the SUSPEND signal to propagate from the CPU to the rest of the chip.  I have seen this work.

    *(int *) 0xffa07fb0 = 0xc5acce55; /* Unlock writes to CTI */

    *(int *) 0xffa07000 = 0x00000001; /* enable ECT in CTICONTROL */

    *(int *) 0xffa07020 = 0x00000008; /* Map CTITRIGIN0=CortexR5-0 DBGTRIGGER to Channel 3*/

    *(int *) 0xffa07028 = 0x00000001; /* Map CTITRIGIN2=ETM0 EXTOUT[0] to Channel 0*/

    *(int *) 0xffa0702c = 0x00000002; /* Map CTITRIGIN3=ETM0 EXTOUT[1] to Channel 1*/

    *(int *) 0xffa0703c = 0x00000008; /* Map CTITRIGIN7=CortexR5-0 DBGTRIGGER to Channel 3*/

    /* DBGTRIGGER from Cortex-R5-0 is mapped to both CTITRIIN0 and CTITRIIN7 */

    *(int *) 0xffa070a0 = 0x00000004; /* Map CTITRIGOUT0=CortexR5-0 EDBGRQ to Channel 2*/

    *(int *) 0xffa07140 = 0x0000000F; /* Enable all 4 channel interfaces */

    *(int *) 0xffa0afb0 = 0xc5acce55; /* Unlock writes to CTI */

    *(int *) 0xffa0a000 = 0x00000001; /* enable ECT in CTICONTROL */

    *(int *) 0xffa0a020 = 0x00000004; /* Map CTITRIGIN0=DMA_DBGREQ to Channel 2 */

    *(int *) 0xffa0a024 = 0x00000004; /* Map CTITRIGIN1=N2HET1_DBGREQ to Channel 2 */

    *(int *) 0xffa0a028 = 0x00000004; /* Map CTITRIGIN2=N2HET2_DBGREQ to Channel 2 */

    *(int *) 0xffa0a02c = 0x00000004; /* Map CTITRIGIN3=HTU1_DBGREQ to Channel 2 */

    *(int *) 0xffa0a030 = 0x00000004; /* Map CTITRIGIN4=HTU2_DBGREQ to Channel 2 */

    *(int *) 0xffa0a034 = 0x00000004; /* Map CTITRIGIN5=DMA_DBGREQ to Channel 2 */

    /* DMA_DBGREQ is mapped to both CTITRIGIN0 and CTITRIGIN5. One is pulse and another is level */

    *(int *) 0xffa0a038 = 0x00000004; /* Map CTITRIGIN6=N2HET1_DBGREQ or HTU1_DBGREQ to Channel 2 */

    *(int *) 0xffa0a03c = 0x00000004; /* Map CTITRIGIN7=N2HET2_DBGREQ or HTU2_DBGREQ to Channel 2 */

    *(int *) 0xffa0a0a0 = 0x00000008; /* Map CTITRIGOUT0=SYS_MODULE_TRIGGER to Channel 3*/

    /* When the CPU is halted, the SUSPEND will come from Channel Interface 0 when in * /

    /* lockstep mode or both Channel 0 and channel 1 when in dual-core mode */

    /* The SUSPEND is the result of the assertion on the DBGTRIGGER from the CPU */

    /* SYS_MODULE_TRIGGER is broadcasted to L2FMC, CCMR5, CRCx, and SYS modules */

    *(int *) 0xffa0a0a4 = 0x00000008; /* Map CTITRIGOUT0=USER_PERIPHERAL_TRIGGER1 to Channel 3*/

    /* USER_PERIPHERAL_TRIGGER1 is broadcasted to: */

    /* DMA, RTIx, AWMx, HTUx, SCIx, LINx, I2Cx, EMAC, EQEP, ECAP, DMM and DCCx modules */

    *(int *) 0xffa0a0a8 = 0x00000008; /* Map CTITRIGOUT0=USER_PERIPHERAL_TRIGGER2 to Channel 3*/

    /* USER_PERIPHERAL_TRIGGER2 is broadcasted to DCANx modules */

    *(int *) 0xffa0a0ac = 0x00000008; /* Map CTITRIGOUT0=USER_PERIPHERAL_TRIGGER3 to Channel 3*/

    /* USER_PERIPHERAL_TRIGGER3 is broadcasted to ETPWMx modules */

    *(int *) 0xffa0a140 = 0x0000000F; /* Enable channel interfaces */

    Obviously, we need to document this in some way other than the forum. However, for now, I think you will find that this does  the trick.

     

    Best Regards,

    Kevin Lavery

  • Kevin,

    Indeed, it works now. Thank you very much.

    But now my concern is: can these writes have any impact on ANY firmware or they should not be affected?

    Piotr

  • Piotr,
    I'm glad that it is working. This code propagates the CPU Debug Request to all peripherals. I need to dig more to insure that this is ALL it does. In short, I cannot fully answer your question yet. Will keep digging.

    Best Regards,
    Kevin Lavery
  • Piotr,
    This circuitry passes debug signals through the chip. Most of the signals are used to interface between the CPU(s) and Trace blocks (ETM-R5) and the TPIU. All of these are debug related signals. Additionally, suspend signals (debug request) from the CPU and other masters are inputs to this logic. These suspend signals propagate to the various logic on the chip.
    The Debug request signals are typically only valid during debug. This is a very long way of answering your question -- these writes propagate debug requests around the chip but do not impact the device when it is not being debugged.

    Best regards,
    Kevin Lavery