Regalino per la comunity di Console Open: Usb Spi flasher fatto su Eagle. UPDATE V2.1

[freelancer]

Hai convertito il JED in SVF e quindi in XSVF usando quel tool che ho linkato sopra? Perchè se usi impact per generare l'XSVF potresti avere problemi.

Comunque quell'errore all'inizio indica che fallisce una verifica predisposta all'inizio del file XSVF. Probabilmente è un controllo sull'ID prima della programmazione che non dovrebbe fallire se il file XSVF è compatibile con il chip, a meno che non ci siano problemi sulla parte elettronica che non mi pare ci siano visto che l'altra CPLD viene programmata.

[D@rio]

ho provato a creare il .xsvf a partire dal .svf (creato a sua volta tramite impact a partire dal .jed) ma non ho risolto il problema, ottendo sempre lo stesso errore.

questa è la stringa che ho dato all'eseguibile per la conversione (trovata nel readme del programma e specifica per i coolrunner2)

svf2xsvf -d -r 0 -extensions -xwait -i test.svf -o test.xsvf -a test.txt

tendo ad escludere problemi elettronici del programmatore (ci ho programmato decine di volte i chip con XC2C64a e XC2C32) e della basetta di test (con IMPACT ed il programmatore parallelo viene programmata correttamente a partire col .jed), il problema è relativo al file .xsvf o all'eseguibile.

aggiungo che per la creazione del file .xsvf a partire dal .jed ho sempre utilizzato direttamente IMPACT e non ho mai avuto problemi ne' con i X2C264a ne' con i X2C232, ma non mi sorprenderebbe un bug del programma di conversione solo con i 128.

allego i files che sto utilizzando per la prova, magari riesci a capire qual è il problema


D@rio_test_XC2C128.zip

[freelancer]

Ciao, mi sono guardato un po' quei file e ad occhio mi pare che eccedano la dimensione dei buffer predisposti sul pic per le stringhe di byte associate ai comandi. Cerco di spiegarti rapidamente qual'è il problema usando la sintassi svf che è più facile da leggere.

Il comandi che creano problemi sono quelli del tipo:

SDR n TDI (a1a2...) SMASK (b1b2...) TDO (c1c2...) MASK (d1d2...)

n è la lunghezza in bit delle stringhe ( (a1a2...) (b1b2...) ecc ) che vengono inviate alla CPLD su TDI ed eventualmente lette in uscita su TDO, SMASK e MASK sono maschere usate per processare i dati relativi (le posizioni in cui c'è uno 0 sono don't care). Ovviamente nel comando può esserci solo la parte con TDI non è detto che siano presenti tutti gli elementi.

Ora sul PIC, per contemplare tutte le possibilità, devono esserci 7 buffer indipendenti in grado di contenere le suddette stringhe di dimensione n. Per gli XC2C64A io ho predisposto buffer da 40byte/320bit che sono sufficienti. Se guardi negli svf che tu hai allegato usando un text editor noterai stringhe da 94byte/752bit.

Ora dovrei controllare se è possibile aumentare un po la dimensione di quei buffer, anche se il PIC non ha tantissime risorse libere volendo mantenere anche le funzioni di USB/SPI intatte.

[D@rio]

ho capito...

se hai qualche prova da farmi fare sono a disposizione. per me andrebbe bene anche un codice che consenta di programmare solo i cpld, senza la parte relativa alla lettura e scrittura della nand.

[MARCHISIO80]

Innanzitutto ringrazio Essereumano,Freelancer e D@rio per l'ottimo lavoro che stanno svolgendo,grazie


Premetto che al momento voglio programmare e poi alimentare lo Storm esternamente,tramite usb-programmatore.....non dovrebbe cambiare molto alimentandolo esternamente,pero' vorrei fare cosi'...anche solo per comodita'

Qual'e' il modo piu' semplice per ricavare 1.8?



Grazie

[D@rio]

utilizzare un regolatore di tensione da 1,8V...come Vin prendi i 5V della USB

io ho utilizzato con successo gli LM1117-18

[nexus]

io Marchisio ho fatto un semplice schema per ricavare l'1.8V da usb

Circuito di alimentazione, avente in uscita 1,8v e 3,3v per la prog. dei CPLD(xc2c64)

[freelancer]

ho capito...

se hai qualche prova da farmi fare sono a disposizione. per me andrebbe bene anche un codice che consenta di programmare solo i cpld, senza la parte relativa alla lettura e scrittura della nand.

Ho provato ad aumentare la dimensione dei buffer, il fw lo trovi qui, io non posso testarlo:

PICFLASH.zip

[D@rio]

adesso funziona!!!

ho provato a programmare un XC2C128 ed un XC2C64a e li ha scritti senza problemi.

[mikele09]

Sto seguendo questo interessantissimo lavoro che state facendo e volevo farti una domanda:
Utilizzando un XC2C128 oltre ad avere un buffer più grande si hanno differenze per quello che riguarda i tempi di reset (soprattutto sulle slim)?
Grazie

[antonellopiu]

Ciao, a questo link bitstreams_bga.zip trovi una versione modificata di xsvf.exe che non controlla l'ID della CPLD (quindi prova direttamente a programmare) e i bitstream dello squirt BGA, non ho testato nulla personalmente, ma dovrebbe funzionare.

In linea di massima per adattare bitstream differenti dovresti partire da un .SVF e convertirlo in .XSVF utilizzando svf2xsvf502 che trovi qui: http://www.xilinx.com/support/docume...es/xapp058.zip

@antonellopiu

L'orientamento del condensatore è indifferente, ma se misurando la tensione su VCC trovi 0.8 probabilmente lo zener non funziona o è storto, in quel punto non dovresti mai avere meno di 3.3 (salvo quando il PIC è inattivo).

Potresti provare senza zener e diodi, cioè a 5V. C'è un piccolo rischio, ma nel 90% dei casi programma senza problemi.

Altrimenti puoi usare un regolatore o un'altra fonte di alimentazione a 3.3 da inserire tra il GND del PIC, il VCC del coolrunner e i tre diodi normali.

Ciao Freelancer e grazie della risposta. In realtà io il test di 0,8 l'ho fatto con pic collegato ma non in programmazione. Cioè con porta usb collegata. Ma se per fare una prova prendo un alimentatore esterno e collego 3,3 e gnd dell'alimentatore e poi gli altri pin tmo tms tdo tmk tdi (li ho messi in ordine sparso) dovrebbe funzionare senza diodi ne condensatore giusto? Ormai ne faccio una questione di principio perchè nel frattempo ho riesumato un cadavere con porta lpt mi sono costruito il cavo lpt e ho programmato con impact......ma se funziona a tutti deve funzionare anche a me!!

[D@rio]

Sto seguendo questo interessantissimo lavoro che state facendo e volevo farti una domanda:
Utilizzando un XC2C128 oltre ad avere un buffer più grande si hanno differenze per quello che riguarda i tempi di reset (soprattutto sulle slim)?
Grazie

mi sa che stai facendo un po' di confusione...

gli XC2C128 sono i "fratelli maggiori" dei XC2C64a, la tipologia di CPLD è la stessa (Coolrunner II) ma hanno a diposizione il doppio delle macrocelle, quindi potrebbero avere la possibilità di giocare un po' col codice e tentare di migliorare i tempi sulle slim. Se venissero programmati con lo stesso codice rilasciato da gligli (opportunamente ricompilato) non ci sarebbero grandi differenza in realtà.

i buffer di cui parla freelancer sono quelli interni al PIC che serve per programmare i CPLD... la prima versione che aveva rilasciato aveva dei buffer con dimensione tale da gestire in maniere corretta i file .xsvf per i XC2C64a e XC2C32 (che hanno stringhe più corte al loro interno) ma non i file .xsvf per i XC2C128. Con la nuova versione che ha postato ieri, dove sono stati aumentati questi buffer, si riescono a gestire correttamente tutti file .xsvf e quindi si riescono a programmare correttamente tutti i CPLD elencati prima.

[mikele09]

Ok grazie per la spiegazione!

[alessioxp]

ciao, io ho uno sia uno squirt 360 1.0 (quello green) e due 1.2 (quelli BGA)! ho un programmatore usb/spi autocostruito con il firmware di freelancer, che permette di programmare anche gli xilink BGA! ma il problema è che il team squirt ha rilasciato solo i file .SVF (per lo squirt 1.2) e a me servono gli .XSVF! ho provato a convertirlo e a programmare lo xilink bga ma il led di debug non lampeggia! premetto che ho già programmato lo squirt 1.0 e funziona perfettamente, perchè come file ho usato il .XSVF del team squirt e programmato con il firmware di freelancer! e la console glitcha, ma con lo squirt 1.2 no!(BGA), cosa può essere? non voglio comprare lo slave programmer, visto che posso usare il mio autocostruito!

comunque ringrazio freelancer e d@rio per il magnifico lavoro che state svolgendo!

[D@rio]

qualche pagina dietro freelancer ha allegato i file .xsvf per il package BGA, prova quelli se vanno.

in alternativa, prova a scrivere al supporto tecnico dello squirt per chiedere se ti mandano i file .xsvf

[alessioxp]

qualche pagina dietro freelancer ha allegato i file .xsvf per il package BGA, prova quelli se vanno.

in alternativa, prova a scrivere al supporto tecnico dello squirt per chiedere se ti mandano i file .xsvf

ho provato, niente da fare! non lampeggia proprio il led di debug onboard, cosa che invece fa lo squirt 1.0 con led di debug aggiuntivo e la xbox glitcha!

[freelancer]

ho provato, niente da fare! non lampeggia proprio il led di debug onboard, cosa che invece fa lo squirt 1.0 con led di debug aggiuntivo e la xbox glitcha!

Ma sei sicuro che il led di debug debba lampeggiare con le stesse modalità anche con lo squirt BGA? Comunque se durante la programmazione non ti da nessun errore, il chip è stato programmato correttamente. Di questo puoi essere sicuro. I file xsvf usati per programmarlo possono essere sbagliati, ma essendo ottenuti a partire dagli svf ufficiali ne dubito.

[alessioxp]

Ma sei sicuro che il led di debug debba lampeggiare con le stesse modalità anche con lo squirt BGA?

beh, non avrebbe nessuna utilità allora! ahahahah
comunque il led è collegato al pin 27 (nel bga, ma anche nel 1.0 che ho aggiunto io!)

Comunque se durante la programmazione non ti da nessun errore, il chip è stato programmato correttamente. Di questo puoi essere sicuro.

nessun errore! e durante la programmazione (anche nel 1.0) rimane acceso il led di debug anche se moooolto debolmente!

I file xsvf usati per programmarlo possono essere sbagliati, ma essendo ottenuti a partire dagli svf ufficiali ne dubito.

questi svf?

[freelancer]

beh, non avrebbe nessuna utilità allora! ahahahah
comunque il led è collegato al pin 27 (nel bga, ma anche nel 1.0 che ho aggiunto io!)




nessun errore! e durante la programmazione (anche nel 1.0) rimane acceso il led di debug anche se moooolto debolmente!




questi svf?

Credo siano quelli, in ogni caso puoi convertire anche tu da svf ad xsvf usando la procedura descritta in un post sopra. Io tenderei ad escludere che il malfunzionamento sia da imputare al passaggio SVF -> XSVF, è un operazione semplice. Piuttosto il fatto che il led si accenda debolmente farebbe pensare a qualcosa che non va nella parte elettronica. Sei sicuro che il chip non abbia problemi e sia montato correttamente?

[impression]

ciao a tutti... voleo chiedere freelancer se il suo hex v1.1 era basato sulla rev 3.0b di nandpro e se sono attivi i led sui pin 2 e 3 , e se inoltre l'hex era valido anche per i pic 18f2550 (sia quello di freelancer che quelli di nandpro) e se il file di d@rio "PICFLASH_v3b_plus2_LED at port A0 and A1" era solo nandpro oppure "contiene" anche la versione 1.1 di freelancer

grazie mille

p.s. lo chiedo perchè per errore ho aquistato dei pic 18f2550 al posto dei 2450, ma mi sembra di capire che sono praticamete uguali, solo che il 2550 contiene più memoria giusto???