Buona sera a tutti,
ho iniziato a fare qualche prova con gli ARM, in particolare con il TM4C1233, e dopo aver acceso i soliti led, aver controllato i pulsanti in input ed aver provato il SysTick, volevo fare qualche prova con la USB e realizzare un dispositivo HID.
Non il solito mouse o keyboard però, ma un HID generico.
Seguita la documentazione della USB Library di TI ho scritto il mio firmware.
Quando collego il dispositivo al PC con windows, viene riconosciuto come Dispositivo di input HID, fino a qui tutto bene. Dopo un po', diciamo 30 secondi circa, windows mette il dispositivo in errore con codice di errore 10:
Impossibile avviare il dispositivo. (Codice 10)
Ho ricontrollato centinaia di volte, ho cercato esempi in rete ma trovo solo mouse o keyboard.
Vi è mai capitata una cosa simile? Avete idea di cosa mi possa mancare?
PS: Il firmware riceve l'evento USB_EVENT_CONNECTED ma poi nulla altro.
Grazie.
TM4C123: USB HID
Moderatore:
Paolino
5 messaggi
• Pagina 1 di 1
0
voti
Ho rinunciato.
Cercando insistentemente ho trovato qualche esempio su internet ma nessuno funziona, tutti con lo stesso identico esito.
Ho pensato potesse essere un problema di windows, ma anche con linux non funziona.
Riconosce un nuovo dispositivo HID connesso, ma dopo un po' di tempo segnala errore (-110) e il dispositivo non è utilizzabile.
Ho pensato potesse essere un problema hardware, della schedina con il micro che sto utilizzando, ed ho quindi provato un dispositivo USB-CDC Virtual Com. Funziona a meraviglia.
A questo punto penso ci possa essere qualche errore nella libreria TI per HID che ho utilizzato, ma non ne trovo di più recenti (la mia è di ottobre 2013) e non sono in grado di verificarla/correggerla.
Ho trovato una libreria più vecchia, ma un rapido confronto sulle differenza tra le 2 librerie mi ha fatto notare alcuni chiari errori presenti nella libreria meno recente e corretti con il rilascio di ottobre.
Mi fermo qui. Se serve farò uso di CDC.

Cercando insistentemente ho trovato qualche esempio su internet ma nessuno funziona, tutti con lo stesso identico esito.
Ho pensato potesse essere un problema di windows, ma anche con linux non funziona.
Riconosce un nuovo dispositivo HID connesso, ma dopo un po' di tempo segnala errore (-110) e il dispositivo non è utilizzabile.
Ho pensato potesse essere un problema hardware, della schedina con il micro che sto utilizzando, ed ho quindi provato un dispositivo USB-CDC Virtual Com. Funziona a meraviglia.
A questo punto penso ci possa essere qualche errore nella libreria TI per HID che ho utilizzato, ma non ne trovo di più recenti (la mia è di ottobre 2013) e non sono in grado di verificarla/correggerla.
Ho trovato una libreria più vecchia, ma un rapido confronto sulle differenza tra le 2 librerie mi ha fatto notare alcuni chiari errori presenti nella libreria meno recente e corretti con il rilascio di ottobre.
Mi fermo qui. Se serve farò uso di CDC.

Fabio
1
voti
E si, sono testardo e non mi piace lasciare una cosa a metà...
Ho voluto approfondire il problema del dispositivo HID e sono giunto ad un punto dal quale non so come muovermi.
Quando collego il micro alla USB del PC comincia il colloquio e in particolare:
- alla funzione "URB_FUNCTION_GET_DESCRIPTOR_FROM_DEVICE -> Device" il micro risponde correttamente
- alla prima chiamata alla funzione "URB_FUNCTION_GET_DESCRIPTOR_FROM_DEVICE -> Configuration 0" il micro risponde correttamente
- alla seconda chiamata alla funzione "URB_FUNCTION_GET_DESCRIPTOR_FROM_DEVICE -> Configuration 0" il micro risponde correttamente
- alla funzione "URB_FUNCTION_SELECT_CONFIGURATION --> 1" il micro risponde con un ACK ma....
All'ultima richiesta il micro risponde si con un ACK (è infatti la prima istruzione della routine), esegue tutta la routine e poi viene generato un "hard fault".
Le risposte alle varie funzioni avviene in una routine di interrupt, USB0 Interrupt, anche la gestione della URB_FUNCTION_SELECT_CONFIGURATION avviene tramite la routine di interrupt. Tutta la routine viene eseguita e non mi riesce di capire il motivo del "hard fault".
Cosa significa esattamente un "hard fault"? Non sono sicuro di averne compreso il vero significato.
Come posso individuare la causa di questo errore?
Grazie.
Ho voluto approfondire il problema del dispositivo HID e sono giunto ad un punto dal quale non so come muovermi.
Quando collego il micro alla USB del PC comincia il colloquio e in particolare:
- alla funzione "URB_FUNCTION_GET_DESCRIPTOR_FROM_DEVICE -> Device" il micro risponde correttamente
- alla prima chiamata alla funzione "URB_FUNCTION_GET_DESCRIPTOR_FROM_DEVICE -> Configuration 0" il micro risponde correttamente
- alla seconda chiamata alla funzione "URB_FUNCTION_GET_DESCRIPTOR_FROM_DEVICE -> Configuration 0" il micro risponde correttamente
- alla funzione "URB_FUNCTION_SELECT_CONFIGURATION --> 1" il micro risponde con un ACK ma....
All'ultima richiesta il micro risponde si con un ACK (è infatti la prima istruzione della routine), esegue tutta la routine e poi viene generato un "hard fault".
Le risposte alle varie funzioni avviene in una routine di interrupt, USB0 Interrupt, anche la gestione della URB_FUNCTION_SELECT_CONFIGURATION avviene tramite la routine di interrupt. Tutta la routine viene eseguita e non mi riesce di capire il motivo del "hard fault".
Cosa significa esattamente un "hard fault"? Non sono sicuro di averne compreso il vero significato.
Come posso individuare la causa di questo errore?
Grazie.
Fabio
1
voti
Sono riuscito a "tamponare" il problema facendo in modo che funzionino sia HID che CDC.
Riporto qui quanto ho fatto nel caso possa servire a qualcuno o nel caso (spero) possiate suggerirmi una migliore soluzione.
Il "hard fault" si verifica su questa riga:
(a) ui32DMAIntStatus = USBLibDMAIntStatus(g_psDCDInst[0].psDMAInstance);
della funzione USBDeviceIntHandlerInternal(uint32_t ui32Index, uint32_t ui32Status)
presente nel file usbdenum.c della libreria usblib fornita da TI.
La USBLibDMAIntStatus è definita come
#define USBLibDMAIntStatus(psUSBDMAInst) psUSBDMAInst->pfnIntStatus(psUSBDMAInst)
seguendo le varie inizializzazione mi sembra di aver capito che in definitiva venga richiamata la funzione uDMAUSBIntStatus per verificare se ci sono stati interrupt del modulo uDMA.
Non sono riuscito a capire perché il puntare a quella funzione (psUSBDMAInst->pfnIntStatus) o la variabile globale che lo contiene (g_psDCDInst[0]) vengano ad un certo punto "sporcate".
Il modulo uDMA mi sembra di capire sia utilizzato dalla libreria solo nel caso si utilizzino le funzioni per bufferizzare i dati in input/output. Nel mio caso (HID e CDC) non ho fatto uso di funzioni di buffer integrate nella libreria. Ho pertanto provato a commentare la (a) e tutto ha iniziato a funzionare perfettamente.
A me basta così, se qualcuno ha idee in merito per una migliore soluzione sono disponibile a fare test.
Riporto qui quanto ho fatto nel caso possa servire a qualcuno o nel caso (spero) possiate suggerirmi una migliore soluzione.
Il "hard fault" si verifica su questa riga:
(a) ui32DMAIntStatus = USBLibDMAIntStatus(g_psDCDInst[0].psDMAInstance);
della funzione USBDeviceIntHandlerInternal(uint32_t ui32Index, uint32_t ui32Status)
presente nel file usbdenum.c della libreria usblib fornita da TI.
La USBLibDMAIntStatus è definita come
#define USBLibDMAIntStatus(psUSBDMAInst) psUSBDMAInst->pfnIntStatus(psUSBDMAInst)
seguendo le varie inizializzazione mi sembra di aver capito che in definitiva venga richiamata la funzione uDMAUSBIntStatus per verificare se ci sono stati interrupt del modulo uDMA.
Non sono riuscito a capire perché il puntare a quella funzione (psUSBDMAInst->pfnIntStatus) o la variabile globale che lo contiene (g_psDCDInst[0]) vengano ad un certo punto "sporcate".
Il modulo uDMA mi sembra di capire sia utilizzato dalla libreria solo nel caso si utilizzino le funzioni per bufferizzare i dati in input/output. Nel mio caso (HID e CDC) non ho fatto uso di funzioni di buffer integrate nella libreria. Ho pertanto provato a commentare la (a) e tutto ha iniziato a funzionare perfettamente.
A me basta così, se qualcuno ha idee in merito per una migliore soluzione sono disponibile a fare test.
Fabio
0
voti
Discussione aggiunta ai preferiti.
Grazie Fabio, potrà tornare utile.
Grazie Fabio, potrà tornare utile.

"La follia sta nel fare sempre la stessa cosa aspettandosi risultati diversi".
"Parla soltanto quando sei sicuro che quello che dirai è più bello del silenzio".
Rispondere è cortesia, ma lasciare l'ultima parola ai cretini è arte.
"Parla soltanto quando sei sicuro che quello che dirai è più bello del silenzio".
Rispondere è cortesia, ma lasciare l'ultima parola ai cretini è arte.
-

TardoFreak
73,9k 8 12 13 - -EY Legend-

- Messaggi: 15754
- Iscritto il: 16 dic 2009, 11:10
- Località: Torino - 3° pianeta del Sistema Solare
5 messaggi
• Pagina 1 di 1
Torna a Firmware e programmazione
Chi c’è in linea
Visitano il forum: Nessuno e 4 ospiti

Elettrotecnica e non solo (admin)
Un gatto tra gli elettroni (IsidoroKZ)
Esperienza e simulazioni (g.schgor)
Moleskine di un idraulico (RenzoDF)
Il Blog di ElectroYou (webmaster)
Idee microcontrollate (TardoFreak)
PICcoli grandi PICMicro (Paolino)
Il blog elettrico di carloc (carloc)
DirtEYblooog (dirtydeeds)
Di tutto... un po' (jordan20)
AK47 (lillo)
Esperienze elettroniche (marco438)
Telecomunicazioni musicali (clavicordo)
Automazione ed Elettronica (gustavo)
Direttive per la sicurezza (ErnestoCappelletti)
EYnfo dall'Alaska (mir)
Apriamo il quadro! (attilio)
H7-25 (asdf)
Passione Elettrica (massimob)
Elettroni a spasso (guidob)
Bloguerra (guerra)