Newsgroup: it.hobby.elettronica.digitale
Titolo: Debug di un bus fault

Ciao,
ho un problema con un codice scritto per un Luminary Micro LM3S1918. 
Dopo qualche secondo mi va in bus fault (lo vedo dal debugger).
Come posso fare per capire quale ï¿œ l'istruzione che causa il blocco 
della CPU?
Il micro esegue ripetutamente le stesse operazioni (lettura da SD card, 
controllo di un DAC e altre cosette) e a occhiometro non sono riuscito a 
identificare la condizione malefica.
Non avendo tanto tempo a disposizione quale ï¿œ la strada corretta per 
eseguire un debug di questo tipo? Voglio dire, c'ï¿œ la possibilitï¿œ di 
sapere quale era l'ultima istruzione eseguita prima del bus fault?
Marco

 sapere quale era l'ultima istruzione eseguita prima del bus fault?
Dovresti avere a disposizione del debugger il call stack per vedere 
quali sono state le varie chiamate per arrivare al punto in cui sei.
Altrimenti puoi andare per ricerca dicotomica:fai fermare il fw in punti 
diversi cosï¿œ trovi la sezione in cui non si blocca. Restringi il campo e 
riprovi. Alla fine quando hai trovato la funzione vai di passo passo.
-- 
  _|/ Francesco Sacchi - Develer S.r.l., R&D dept.
   |\ 
http://www.develer.com/
 - 
http://www.bertos.org/

 sapere quale era l'ultima istruzione eseguita prima del bus fault?
Eclipse+openocd in caso di bus fault non fanno vedere il call stack, ma 
puoi comunque leggere dalla memoria (quindi tutte le variabili sono 
congelate al loro stato un attimo prima che capitasse il fault).
Le principali cause di bus fault per quello che sto notando sono 
l'accesso ad una periferica prima di averla "attivata" (le funzioni di 
libreria SysXXXX).
NOTA: In questi giorni mi capita un bus fault causato dall'ethernet. Dopo 
qualche secondo di funzionamento regolare finisce in fault. Disabilitando 
l'ethernet (e gli interrupt associati) tutto fila liscio. 
Per ora il problema e' in coda, quando inizio a guardarci bene ti faccio 
sapere.

 libreria SysXXXX).
Si questo era noto anche a me ma non vedevo la riga incriminata.
In effetti era proprio una periferica che veniva erroneamente utilizzata 
prima che venisse abilitata.
Devo dire che ci sono arrivato con il ragionamento, se mi fossi dovuto 
basare sul debugger sarei ancora qui :)
Ciao!
Marco

 riprovi. Alla fine quando hai trovato la funzione vai di passo passo.
Si, ho fatto piï¿œ o meno cosï¿œ. Speravo perï¿œ che vi fosse un modo meno 
empirico (appunto il call stack).
Ciao!
Marco

 basare sul debugger sarei ancora qui :)
Idem. E' una seccatura cercare quale periferica causa il fault: tocca 
escludere tutte quelle usate una per una ed andare per esclusione. 
La scelta di mostrare il dettaglio dell'abilitazione della periferica 
prima della sua inizializzazione mi e' ancora oscura. 
Mi attacco con una domanda: usando codesourcery dovrei utilizzare il file 
di startup relativo, che e' vuoto. Il file per il linker, invece, e' di 
una complicazione ridicola. In questo momento uso il file di startup e 
gli script del linker in versione gcc: sono piu' puliti e funzionano 
altrettanto bene. Tu come ti regoli?
Fra un po iniziera' il viaggio allucinante nel mondo dei bootloader...  

 Fra un po iniziera' il viaggio allucinante nel mondo dei bootloader...  
Ecco un compagno di viaggio :)
Anche per me sta per iniziare...
Ciao!
Marco