No announcement yet.


  • Filter
  • Time
  • Show
Clear All
new posts

  • Watchdog

    I'm using a few of the uVGA(GFX) modules as displays in public areas.
    There are times the image on the screen just freezes.

    Is there a possibility in the hardware/system software to activate some kind of watchdog feature that would cold reset the unit if the retriggered by user software for a certain time?

    Thanks for your help


  • #2


    It would be nice to understand why it freezes, some bug in your program, maybe?

    There is a forum user who added a watchdog on an I/O pin to do just what you are asking for.

    Perhaps you can find the post (Don't think he included the circuit, but it shouldn't be that hard)


    • #3

      Thanks for the quick reply.
      Sure bugs are always around. The program is pretty short (550lines) and the loops are all forced to exit.
      I'll go bug hunting for sure, but the watchdog is still a good insurance.
      True adding an external watchdog is solution.



      • #4

        I've just noticed that the reset pin is not available on the expansion pins (J1, J2). That makes things a bit more difficult. Linking up external circuitry on the uUSB (CN1) connector is not easy when also used for programming these devices.
        I suppose taking an external watchdog and cut Vin (J1/11) for a few hundred milliseconds could be another option to get it to reset.


        • #5

          The hardware watchdog will take a while (PCB update etc), so I thought about a some kind of software watchdog. Using a periodic timer to monitor the mail loop.
          Are the timers (sys_SetTimer()) running on true interrupts? Meaning, could I use a timer to monitor if the main loop got stuck?
          If so does it make sense to use the "goto" to jump back to the start of main(), after freeing resources of course. Or is there a nicer way to make the program to re-start?



          • #6

            No they aren't, but even if they were you couldn't really rely on them to 'work' as it would depend on why Picaso had stopped responding


            • #7

              True. Was just an idea.

              Inspecting my code makes me think it could run into memory fragmentation and finally run out of heap.
              I was slack checking the return values from file_LoadImageControl(), which I added now.
              However if allocation fails I am still stuck. After that to get all clean running again I would need to restart the whole thing, which I can't.
              I'm already freeing mem in the reverse order of allocation. But maybe there is a case where it's not quite happening that way.
              Is there a way to interrogate the order of mem allocation so I can return them in reverse?



              • #8

                The heap should look after itself (i.e. it does garbage collection).

                But if you alloc something and don't free it, it can't help

                Try printing mem_Heap() in a few places to see if funny things are going on

                System_Reset() will do a full reset, but really it shouldn;t be required.


                • #9

                  That is rather interesting. I remember spending some considerable time to organise my allocs and frees because I did run out of memory quite quickly when doing the image free in a different order then loading them.
                  Well, I got a fatal error screen now when loadImage fails. It still locks up (to show the message).
                  The System_Reset() could come handy.


                  • #10

                    compiler does not know anything about System_Reset() call?????


                    • #11

                      Duh try SystemReset() it's in the programmers reference manual

                      (Had to retype the post as it failed on the first post, misstyped it on the redo)


                      • #12

                        Just as a side note, it is usually not recommended to call a watchdog reset from a timed interrupt, as the main loop could be hung up somewhere but the timer may keep firing happily. Typically, you tickle the watchdog from the main loop, and from within any excessively long subroutines as required.....
                        Best Regards,


                        • #13

                          I've got my watchdog hardware going. But the system timing is a bit disappointing to make it work.
                          The watchdog needs to be triggered about once per second.
                          But at startup it seem to take forever for the device to come up.
                          And I've tried to run the watchdog trigger both in main loop and in a timer callback function. Both are not great. As soon as a image update happens on the screen all seems to stop. My timer stops for up to about 400ms (!). That's a very long time for an embedded system.

                          Moderator, you argued against a watchdog in the timer in an earlier message. However doing it in the main loop is not good either. The loop time usually varies an awful lot, from a few micro seconds when idle to rather long when images are re-loaded.

                          My generic watchdog approach is have a 1 sec timer repeating timer. The main loop checks for timer expiry and re-triggers the watchdog. This slow re-trigger means any unexpected delays on the main loop will cause a reset. A fast watchdog trigger (every main loop) wouldn't not cause a reset if the program runs slow due to a fault.

                          So the problem here is that the time for any system call can be both rather long and unknown in duration.

                          In my code the timer callback does not seem to run until all my init code has run and even not until the first image has been up on the screen. That takes almost 10sec in my case. Useless to trigger a watchdog.

                          A bit stuck here. Do I need a watchdog that got a rather large timeout (10-20secs). Or is there a better way?


                          • #14

                            I'm not sure how you have your system set up, but 10-20secs seems a bit odd.

                            It would take about 2 (closer to 1.5) seconds before your program starts running, so unless you start your watchdog inside your program you can't set it for less than that.

                            If you draw a large hires image on a uVGA them I could imagine it taking 400ms to draw, so the 'main loop' might not execute for that time.

                            As 4DSysFan said, you may need to retrigger your watchdog in any excessively long sub routine


                            • #15

                              func WatchDog()

                              func Rst(var milisec) sys_SetTimer(TIMER0, milisec);endfunc
                              func main()

                              sys_SetTimer(TIMER0, 2000);//2 ssys_SetTimerEvent(TIMER0, );
                              Rst(2000);//2000 milisecunde


                              //periodic call function Rst(milisec); for reset Timer0 watchdog function