EMB_75

EMBEDDED FEBBRAIO 56 SOFTWARE | RTOS TOOLS Tutto è connesso Tutte le visualizzazioni in Tracealyzer sono in- terconnesse per cui cliccando sui dati tracciati o sulle barre dell’istogramma è possibile trovare la posizione corrispondente nella visualizzazione del trace principale ed esaminare il comporta- mento dettagliato dell’RTOS che si cela dietro le statistiche. Un caso pratico: il reset “misterioso” del watchdog Percepio dispone di una raccolta di esempi di utilizzo di Tracealyzer da parte dei clienti e ha ricreato problematiche simili per illustrare i van- taggi offerti da Tracealyzer agli sviluppatori di software embedded. In questo articolo viene riportato il caso di un utente che ha riscontrato un problema con un reset che di manifestava in maniera casuale. Impostando un breakpoint sul gestore delle ecce- zioni del reset, l’utente in questione ha scoperto che era scaduto il timer di watchdog. Il timer di watchdog doveva essere resettato in un task ad alta priorità che veniva eseguito periodicamente. La possibilità di inserire “User Events” persona- Á * molto utile in questo caso. Questi eventi sono si- mili alle classiche chiamate “printf()” e qui sono stati aggiunti quando il timer di watchdog è stato resettato e quando è scaduto. Gli “User Events” supportano anche il passaggio di parametri e questa caratteristica è stata usata per registrare il valore del timer (appena prima del reset) per vedere i margini del watchdog, ovvero il tempo " * À \ - presentato dalle etichette di testo evidenziate in giallo. È possibile vedere che SamplerTask è in esecu- zione ma non azzera (clear) il timer del watchdog durante l’ultima esecuzione del task, il che re- setta il sistema dopo un certo periodo (reset del watchdog). Quindi è utile domandarsi perché SamplerTask non resetti il timer di watchdog. A questo punto è necessario visualizzare le chiama- te ai servizi del kernel per vedere quello che il task stava facendo. L’ultimo evento di SampleTa- % * }K ] del kernel il cui compito è inserire un messaggio in una coda di messaggi. Si può notare (Fig. 8) che l’etichetta è rossa, il che indica che questa chiamata a XQueueSend ha bloccato il task, pro- ' } switch) verso ServerTask prima che il timer di watchdog fosse stato resettato: il timer è poi sca- duto e il sistema è stato resettato. Le ragioni del blocco A questo punto è utile domandarsi il motivo per }K ] % [ click sull’etichetta di questo evento permette di aprire la visualizzazione della storia dell’oggetto ', ™ J P „ €( - À 'O K ( À w La colonna più a destra mostra i messaggi me- morizzati temporaneamente (bufferizzati). Come  À messaggi contiene già cinque messaggi e quindi è presumibilmente piena, da qui il blocco. Poi- ché si suppone che ControlTask debba leggere la coda e quindi liberare spazio, è lecito domandarsi il motivo per cui il funzionamento non sia quello previsto. Per far luce su questo comportamento è possibile analizzare le modalità di variazione del margine del watchdog in funzione del tempo. Questa in- formazione è reperibile nella registrazione degli F 3 = &$ # 5! " + viene utilizzato per registrare e visualizzare i dati dell’utente, in modo analogo a quello delle classiche ! $ Fig. 8 – SamplerTask blocca un’operazione “invia a una ! <