[Gio55]

Finalmente oggi sono risucito a fare anche la pova dei campi commandBlock 6 - 7. Rimangono a zero anche dopo la esecuzione del comando.

A questo punto che sugerisci? E' normale?
Il registro che appare con quell'indirizzo su area riservata?

Aspetto tue nuove?

[zioelp]

Il registro che appare con quell'indirizzo su area riservata?

Forse mi è sfuggito un passaggio: l'indirizzo di cui stiamo parlando è quello che compare nel secondo parametro della funzione di lettura? Se è così, dovrebbe indicare alla funzione dove depositare i byte che arrivano dall'esterno. Se tale indirizzo non punta ad una zona di RAM accessibile, è giusto che la funzione esca con errore. Il problema, adesso, è capire perché la funzione venga chiamata citando un indirizzo non valido. Sarebbe utile osservare nel debugger tutta la catena di chiamate che portano alla funzione di lettura. Da qualche parte ci dev'essere il calcolo dell'indirizzo a partire da un'altra quantità logica di partenza, e tale calcolo dovrebbe riferirsi in qualche modo all'indirizzo fisico della RAM che il software ritiene accessibile, in genere stabilito con una #define. Se usi MPLAB, mi sembra di ricordare che il sorgente venga colorato in grigio nelle zone escluse dalla compilazione in seguito alle #ifdef non soddisfatte. Può darsi che la #define riferita all'indirizzo 0xA000 (valido) non venga vista, e ne venga assunta un'altra a 0xA400 che, magari, funziona su altri modelli di processore. Potrebbe esistere anche una funzione per l'allocazione dinamica dei buffer: viene chiamata da qualche parte prima della lettura, e il valore di ritorno viene usato come indirizzo nel secondo parametro che adesso vedi a 0xA400 e rotti. La stessa funzione di allocazione dinamica potrebbe essere usata anche per le scritture che, in base alle tue prove, funzionano bene. Quale indirizzo vedi nelle scritture? E' un indirizzo che inizia (giustamente) per 0xA000? Mi è anche capitato d'incontrare casi nei quali il buffer viene allocato, viene usato, e poi viene "deallocato" dimenticandosi di riallocarlo prima di una nuova lettura. Per fare una prova potresti anche definire tu stesso un buffer statico, ad esempio BYTE mybuf [STAZZA]; (dove STAZZA è l'ampiezza in byte, ad esempio 256 o 512) e poi passarne l'indirizzo alla funzione di lettura. Purtroppo, senza aver sotto mano in debug il sistema vivo, la lettura dei sorgenti non aiuta più di tanto, perché vedi solo le intenzioni, non la realtà

[Gio55]

In lettura il buffer (per la funzione incriminata) aveva indirizzo del tipo: A000 (corretto quindi).
Comunque un miglioramento l'ho ottenuto ho cambiato i file FSIO.c e .h con altra versione, quella che usavo permetteva la gestione del "Long File Name". Ora mettendo questa versione il supporto non lo posso più usare ma il buffer di lettura ha indirizzo correttamente del tipo A000.

Ottengo però lo stesso errore di bad cache...
Cerco di campire meglio dove si può originare il problema in questo caso poi faccio sapere qualcosa di più preciso.

p.s. ora che non ho più il supporto Long File Name, avrò problemi?

[zioelp]

p.s. ora che non ho più il supporto Long File Name, avrò problemi?

Dipende dal contenuto dei media che leggi: se nel directory compaiono nomi più lunghi dello standard, cioè 8 + 3 caratteri, li vedrai in forma abbreviata con in fondo una tilde (il coso a forma di ondina). Il contenuto dei file non cambia, quindi potrai leggere e copiare senza problemi. I file che creerai avranno già un nome limitato a 8 + 3 caratteri.
A proposito di nomi, un'altra fonte di rogne potrebbe essere Unicode, poiché i nomi lunghi adottano tale formato al posto del vecchio ASCII. Come prova significativa potresti prendere una chiavetta, formattarla su computer come FAT16, poi, a directory acora vuota, collegarla al PIC e scriverci un file "PROVA.TXT" di un solo blocco di caratteri "A" (o altri, indifferentemente). In questo caso, se provi a spegnere tutto, riaccendere e leggere con la funzione incriminata, hai ancora lo stesso errore di bad cache?

[Gio55]

Guardando tra le definizioni, in cui carica tutti i codici di errore tramite OR causate dalle chiamate alle successve funzioni (derogate allo stack usb).
Fra questi compare anche 0X03 che riporta "No dynamic memory is available".

C'era un define da abilitare per permettere l'allocazione dinamica e correggere un errore che hanno fatto nella libreira: bypassavano la definizone delle macro free e malloc, bho perchè!?!) . Comunque fatto.

Ora il codice di errore (della stessa funzione) è diventato 0x12 "Transfer phase error. Returned in dCSWStatus".

Ho fatto poi la tua prova della scrittura e rilettura. Trovo il file scritto con caratteri "A"... e rileggo i caratteri bene nel buffer. La funzione "USBHostMSDSCSISectorRead" (quella incriminata) nello stesso caso non da errore.
Ho provato a ripetere il tutto anche facendogli cambiare la cartella in un sottopercorso tutto ok.

Sembra che l'unica funzione che non funziona sia quella della ricerca... proprio quella che mi serve

[zioelp]

Ho fatto poi la tua prova della scrittura e rilettura. Trovo il file scritto con caratteri "A"... e rileggo i caratteri bene nel buffer. La funzione "USBHostMSDSCSISectorRead" (quella incriminata) nello stesso caso non da errore.
Ho provato a ripetere il tutto anche facendogli cambiare la cartella in un sottopercorso tutto ok.
Sembra che l'unica funzione che non funziona sia quella della ricerca... proprio quella che mi serve

Che cosa intendi esattamente per "funzione di ricerca"? Se il tuo scopo è ottenere un elenco dei file contenuti in una cartella è probabile che il processo debba essere gestito con due funzioni: una, che in genere si chiama FindFirst, attraversa il directory partendo da un pattern iniziale; l'altra, che può chiamarsi FindNext, continua il lavoro dal punto in cui si è fermata la prima. Tanto per fare un esempio, supponiamo che tu voglia l'elenco dei file che hanno estensione ".jpg". La prima chiamata a FindFirst deve avere come parametro "*.jpg", o qualcosa di simile. FindFirst alloca i buffer necessari e scandisce la directory fermandosi alla prima occorrenza dove compare l'estensione ".jpg", ad esempio "foto1.jpg". Se ora volessi verificare la presenza di altri file con la stessa estensione, non dovresti più chiamare FindFirst ma FindNext. FindNext non ha come parametro un nome di file, ma un puntatore ad un'area di memoria che, di solito, viene ritornata da FindFirst. Ogni chiamata a FindNext ritorna un altro nome di file o, se non trova corrispondenze, un errore di "file not found". A questo punto, a seconda dell'automazione inserita nelle funzioni, l'utente ha o non ha la responsabilità di deallocare i buffer o resettare qualcos'altro, pena l'impossibilità di chiamare di nuovo FindFirst per un'altra ricerca.
Sembra che nel tuo caso la prima chiamata a FindFirst vada a buon fine, e poi le successive producano l'errore che citi.

[Gio55]

Hai ragione!

Credo di aver risolto. Sto leggendo anche le cartelle con la catena di FileFind e FindNext. Mi sono accorto che succede una cosa strana: se metto un breack point e poi faccio proseguire, non vedo l'aggiornamento di tutti i vettori. Se metto il breack point su FileFind e procedo fino a FindNext i vettori non si aggiornano o vedo il codice di errore che dicevo precedentemente. Se meto il breack point al termine della chiamata FileFind e FindNext sembra tutto andare correttamente.

E' un limte del debuger (con il PickKit3)?

[zioelp]

Hai ragione!
Credo di aver risolto... E' un limte del debuger (con il PickKit3)?

E' probabile. I micro PIC non hanno mai brillato in quanto a supporto per l'emulazione. E' una precisa politica di Microchip: su silicio mettono solo il minimo indispensabile, anche per contenere i costi. Nei modelli piccoli, non c'è supporto nativo per l'emulazione, e infatti l'utente deve comprare un coso a parte con sopra lo stesso micretto in versione "bond out", cioè con qualche pin in più e i circuiti di debug omessi nella versione standard. Nel mio lavoro mi trovo ad usare parecchi micretti di aziende diverse, quali ad esempio Freescale, Infineon, Atmel, Texas, e recentemente Silicon Labs. Quasi tutti incorporano i circuiti di emulazione real time, e alcuni prevedono addirittura l'accesso ai registri anche mentre il programma sta girando. Nel caso del tuo chip (che come ripeto non ho avuto occasione di utilizzare) ipotizzo che l'emulazione non sia del tutto "trasparente", nel senso che alcune operazioni non possono esser svolte mentre il programma gira, e altre non possono aver luogo se c'è un breakpoint nel mezzo.
Per aggirare l'ostacolo potresti semplicemente sfruttare la chiavetta anche come logger: invece di usare il debugger sul PC, e fermare tutto di tanto in tanto con dei breakpoint, puoi lasciare che il tuo programma giri da solo e preveda delle tue funzioni che, prima e dopo i punti da debuggare, leggano le variabili e ne scrivano una rappresentazione utile in un file di testo che avrai avuto cura di creare all'inizio nel file system della chiavetta "target". Se vuoi divertirti ancora di più, puoi inizializzare un timer e aggiungere ad ogni lettura il cosiddetto "time stamp", al fine di conoscere anche quanti millisecondi passano da un'operazione all'altra.

[Gio55]

Per il log vorrei provare a farlo con la UART, però nel micro PIC32MX230 si dovrebbero impostare i pin con il PPS... Come dovrei fare (non l'ho mai usato questa funzione)? Nel datasheet e nel manuale dell'XC32 non mi appare chiarissimo

[zioelp]

Per il log vorrei provare a farlo con la UART, però nel micro PIC32MX230 si dovrebbero impostare i pin con il PPS... Come dovrei fare (non l'ho mai usato questa funzione)? Nel datasheet e nel manuale dell'XC32 non mi appare chiarissimo

Al di là del nome simpatico, il PPS (Peripheral Pin Select) non è altro che uno stratagemma per migliorare la versatilità dei chip con (relativamente) pochi pin disponibili. Se il chip che stai usando avesse 200 pin, ciascuno potrebbe svolgere una sola funzione ben documentata. Dal momento che i pin sono presenti in numero inferiore a tutte le possibili funzioni e periferiche previste nel chip, hanno inventato un meccanismo per associare a ciascun pin diverse funzioni, non solo in modo fisso e prestabilito come nei modelli più piccoli, ma in modo variabile e gestibile "a run time" con opportuni registri. In due parole, hanno deciso di trattare gli ingressi e le uscite in maniera distinta: per i primi, hai un registro per ciascuna periferica; per le seconde, hai un registro per ciascun pin. Non ho letto il datasheet per intero, ma come suggerimento di base per la tua sperimentazione ti inviterei a procedere per gradi verificando di volta in volta col debugger che cosa succede nei registri che manipoli. Nel caso dell'UART, immagino che tu voglia avere un ingresso per ricevere e un'uscita per trasmettere. Sappiamo che il PPS associa gli ingressi alle periferiche, quindi guarderei in mezzo ai registri della periferica UART alla ricerca di quel registro che stabilisce quale dei diversi pin multifunzione verrà considerato. Probabilmente troverai una tabella dove alcuni bit del registro selezionano alcuni pin del chip: tutto qui. Per l'uscita di trasmissione c'è un criterio diverso: il registro di scelta non è associato alla periferica, ma ai singoli pin multifunzione. Non devi far altro che scegliere uno dei tanti pin marcati PPS, e cercare il registro di mappatura ad esso associato. In tale registro troverai una lista di periferiche, e fra queste ci sarà una combinazione riferita alla UART (o ad una delle UART se il chip ne ha diverse). Una volta realizzate le associazioni fisiche coi pin d'ingresso e uscita, dovrai solo "convincere" la UART a funzionare coi parametri di baud rate, ampiezza di parola, sincronismi e altre opzioni che desideri. Non conosco l'hardware che stai usando, ma non dimenticare che il chip manipola livelli TTL o CMOS a 5 o 3 volt, mentre le classiche porte EIA-232 di un computer (native o aggiunte via scatolino o cavetto USB) adottano tensioni più alte e anche negative.