Better watchdog handling

Are there any features that you would like to add to the VESC?
Posts: 41
Joined: 21 Apr 2016, 13:06
Location: Austria/Vienna

Better watchdog handling

Postby ViennaTom » 12 May 2016, 15:43

Hello VESC-developers,
Inspired from a thread in the hardware section that the controller sometimes freezes under heavy load i was thinking of a more sophisticated watchdog handling as the current implementation simply feeds the dog with every injected ADC reading and sometimes leaves the system unresponsive to commands. I was thinking of using the so called WWDOG Early Interrupt that indicates that the watchdog counter has already reached its low limit of 0x40. In this routine the health state of the system could be checked and either the dog fed or the system rebooted.

To check chibios integrity one could use function chSysIntegrityCheckI( flags ) and to check interrupts simple interrupt counters.
I have done this in my local firmware copy but this did not yet help in the situation of a non-responsive USB-Serial process.
I used lowest priority 15 interrupt and a pretty slow watchdog timer. Threads can register a flag or counter that is being checked on a timed basis too either permanently or in certain conditions but i limited this to a fixedsize lookup table.

void WWDog_EarlyTimeout(void)
bool bOsOk;
bool bAdcInjOk = (lastInjectedConversions != injectedConversions) || !lastInjectedConversions;
lastInjectedConversions = injectedConversions;

// perform OS sanity checks only one at a time
bOsOk = !chSysIntegrityCheckI( 0x01 << (wwDogCt++ & 0x03) );

if (bOsOk && bAdcInjOk && verityWDTags() ) {
WWDG_SetCounter(WWDG_RELOAD); // 100-64 3.5mSecs until next interrupt

Of course it would/might be nicer to have the ability for individual (critical) threads to provide a callback function checking their responsiveness within that early interrupt ISR. I will try to focus on the blocking USB comms meanwhile.

What do you think ?

Greets, Tom

addr stack prio refs state name time
20014f30 20000554 64 1 SLEEPING main 4952
20014a88 20014bcc 2 1 SUSPENDED usb_lld_pump 4800
200089d8 20008bdc 64 1 QUEUED USB-Serial read 3506
20008d70 20009c8c 64 1 QUEUED USB-Serial process 13955 The "frozen" USB process does no longer wait on the event
20004fe0 20005d44 64 1 CURRENT uartcomm process 1622
20006f68 200070a4 64 1 SLEEPING msec_timer 62

further investigating .....

Return to “Feature Requests”

Who is online

Users browsing this forum: No registered users and 1 guest