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.

How to use Digital Window Watchdog in a useful way

Hello Support,

According to the following post :

http://e2e.ti.com/support/microcontrollers/hercules/f/312/t/210338.aspx

The Period of Watchdog is determined by the TIME INSTANT when CPU Services the Wacthdog with "write A35C to WDKEY".

Usually the Period of Windowed Watachdog should be independent of CPU Service Instant of Watchdog.

If you look at TI following document -- slvsab1d.pdf -- for TPS7A6333 device http://www.ti.com/litv/pdf/slvsab1d

 related to "Figure 24. Watchdog Window Duration" in Page 15, you will see Watchdog Period is constant irrespective of CPU timing of Service.

In effect, is there any useful way current Digital Window Watchdog be used at all because the Period END Point will be shifting with the instant when CPU services the Watchdog.

Any clue about the expected usage of Digital Window Watchdog in comparison to slvsab1d.pdf based architecture will be helpful.

Thank you.

Regards

Pashan

 

  • Hello Support,

    I think I can make it work now the way it is supposed to be.

    Thank you.

    Regards

    Pashan

     

  • Thanks Pashan,

    Did you ever get this to work? If so what did you do ?

    Best Regards,
    Anthony
  • Hello Anthony,
    Essentially as the Period is from the instant of service to watchdog, so watchdog service call is invoked from a RTOS TASK Level [precise time if there is no system overload of blocked RTOS TASK].
    Within the watchdog service call we check for plausibility of all the other system RTOS TASK execution control flow as well as previous time stamp of watchdog service before actually petting the watchdog. In essence, it was no different than previous external watchdog we using in Delphinus Device or Titan Device [Analog Watchdog]. Actually my understanding was wrong and hence I asked the question which Kevin confirmed.

    RTOS TASK which is servicing the watchdog is invoked because of OSEK Category 2 Timer Tick ISR [Low Priority than all Category 1 ISR always]. So it is called precisely if there is no system overload or error.
    That also protects that we are not servicing watchdog inside ISR. We have BCC1 OSEK System. So if any RTOS TASK is in a INFINITE Loop, system will halt and watchdog will not be serviced correctly.
    By checking for plausibility of other RTOS TASK Control Flow and previous time stamp of watchdog service, we are preventing watchdog service being done when system RTOS TASKS are not executing at pre-determined rate.

    In essence, my understanding was wrong and I didn't do enough homework before asking the question.
    We didn't do anything special to use it. It was the same architecture as we used for Delphinus or Titan w.r.t. Watchdog Service function call sequence.

    Only thing is that had the period remained constant from the first start instead of from the last service, we could have made the window 25% instead of 50% [more tight]. That's where I got confused and asked the question. It would have been a better design according to me then.

    Let me know if you need any more information.
    Thank you.
    Regards
    Pashan
  • Thank You Pashan,

    I haven't run into the problem but thought another customer might run into the same thing you did, and it's good to have the solution in the knowledge base of the E2E forums. Thanks much for sharing your solution.

    Best Regards,
    Anthony