Mein SH7262 hat ja kein internes Flashrom. Der bootet sein Programm beim einschalten aus einem externen SPI-Flash.
Ich habe neben dem Prozessor Platz fuer zwei solche Flashrom vorgesehen.
Jetzt stellst sich natuerlich die Frage wie bekommt man seinen Bootloader das erstemal in den Prozessor. Dazu habe ich noch einen Pfostenstecker mit dem ich die Flashroms ueber meinen Brenner programmieren kann. Den Prozessor halte ich in der Zeit dauerhaft im Reset damit er die Finger vom Flash laesst.
Umschalten zwischen den Flash kann ich ueber eine Loetbruecke. /CS des jeweils ungenutzten Flash wird dann ueber 4.7k auf 3.3V gezogen.
Auf einem Platz habe ich einen AT25DF041A, auf dem anderen einen AT26DF081A. Beide SPI-Flash kann ich problemlos programmieren und auch ein verify durchfuehren. Die sind garantiert einwandfrei gebrannt!
Dadurch das ich extern zugreife ist auch sichergestellt das die Platine selber fehlerfrei sein muss.
Trotzdem bootet mein Prozessor problemlos vom AT25DF041, beim AT26 dagegen passiert nichts.
Ich habe hier gerade beide Datenblaetter parallel gelesen. Mal abgesehen davon das der eine etwas groesser ist kann ich da keinen Unterschied erkennen. Ich wuerde sogar sagen das die Datenblaetter voneinander abgeschrieben sind.
Weiss also einer was der Unterschied zwischen den 25er und den 26ern ist? Beide sind mit 70Mhz auch schnell genug. Der Prozessor liesst mit
wenn ich den serial boot-Vorgang des SH7262 richtig verstehe, wird ja erst ein 8k großer Loader aus dem SPI-Flash ins Fast-RAM kopiert. Läßt sich überprüfen, ob das geschieht?
Hat der Loader vielleicht ein Problem mit den unterschiedlichen Größen bzw. Density-Codes der SPI-Flashes?
Hast du die Flash-ROMS mal umgelötet auf den jeweils anderen Sockel?
Das ist bereits der Bootvorgang. Diese 8kb sind mein Bootloader der sich ueber RS232 melden wuerde und munter mit einer LED blinzelt.
Klar, ich muss aber noch meinen Analyzer dran pappen.
Das muss ich noch rausfinden. Hm..ich sehe gerade es gibt eine Applikation speziell zum booten und dort verwendet Renesas einen AT26DF161A. Von daher sollten also die 26er grundsaetzlich gehen und mit der groesse sollte er auch klarkommen.
Das wollte ich mir und der Platine bis jetzt nicht antun. Aber der Verdacht liegt ja nahe. Was mich erstaunt ist aber, beide Footprints sind sehr nahe an der CPU.
formatting link
Auf dem Bild hier sind noch beide unbestueckt. Rechts neben dem SD-Slot. Der 25DF041 ist weiter weg von der CPU, naher an der Pfostenleiste zum brennen. Der 26DF081 ist naeher an der CPU und alle Leiterbahnen gehen erst bei ihm vorbeit. Ich glaub ich probier es mal mit Terminierung. 36Mhz Clock sind ja schon recht heftig. Allerdings finde ich es dann erstaunlich das der eine wirklich zuverlaessig und reproduzierbar funktioniert. Naja, muss ich wohl mal den Oszi vorgluehen...
Das sieht ziemlich gruselig aus. So nach dem Motto sparen um jeden Preis. Wenn ich sowas gemacht habe (derweilen lasse ich die Platinen fertigen und bestücke sowas via Schalblone) haben sich oft Lötfehler eingeschlichen die zu äusserlich nicht zu erkennenden Leerläufen (also dem Gegenteil zu Kontakt) führten. Hast Du schon mal den Flash mit Flussmittel nachgelötet und alle Leitungen mit dem Durchgangsprüfer durchgeklingelt?
Also wenn es an der Terminierung liegen sollte fresse ich einen Besen^W^W^W^W würde mich das schon sehr wundern. Ich betreibe Busse bis 100MHz ohne besondere Terminierng und die Signale sind Astrein. (OK - das sind dann auch Multilayer aber im Prinzip ....)
Ach? Ich finde ja das sieht brilliant aus. Aber ich habe ja auch Selbstbewusstsein. :-)
Noe, es geht um Spass am selbermachen. Im Laden kaufen kann doch jeder.
Das muss an dir liegen. Bei mir schleichen sich keine Loetfehler ein.
Ich habe besseres getan. Ich hab das Flash ueber den Pfostenstecker auf der Platine gebrannt und ausgelesen. Ausserdem hat das SOT8,
1.27mm Pinabstand. Sowas grobes kann man nicht falsch loeten. :-)
Mich auch. Aber wie schon gesagt die Verbindungen muessen in Ordnung sein, sonst haette ich den Flash nicht von meinem Brenner aus ansprechen koennen.
Allerdings ist es ja so das der jeweils nicht benutzte Flash ueber /CS abgeschaltet ist. Das fuehrt dazu das der Problemflash bei seinem Zugriff immer die Leitungen zum unbenutzten Flash und zum Pfostenstecker als kleine Antennen mit an seinen Fuessen haengen hat.
Es kommt wohl mehr auf die Flankensteilheit an, weniger auf die Cycle time.
In diesem Fall ist die Entfernung zwar wirklich sehr kurz, eine Masseflaeche gibt es aber keine. Findet der Strom keinen Rueckweg in der naeheren Umgebung, wird eine Schleife aufgespannt. Uebersprechen durch induktive Kopplung koennte dann ein Thema sein (z.B. Glitches auf SCK und dadurch" ueberzaehlige" Bits).
Dass es mit dem einen Chip geht und mit dem anderen nicht koennte z.B. daran liegen, dass die Flankensteilheit der MISO-Treiber nicht gleich ist.
Wieso glaubt ihr eigentlich immer alle es wuerde keine Masseflaeche geben? Von ein paar nicht zu vermeidenden Unterbrechungen ist die gesamte Unterseite der Platine Masse. Ich werde die Unterbrechungen aber sicherheitshalber auch nochmal zuloeten. (Kupferblech)
Terminierung hat im uebrigen nichts gebracht.
Auf dem Logicanalyzer sieht auch alles unauffaellig aus. Ich kann bei beiden SPI-FLash sehen wie der Controller sein Programm da raussaugt. Allerdings sehe ich natuerlich nur ein paar Byte.
Ich warte erstmal ab bis endlich mein 48Mhz Quarz eingetrifft weil ich dann die Platine im Debugger laufen lassen kann und dann kann ich mir mal anschauen was der Prozessor aus den Flash ausliesst.
Das wuerde ich sofort glauben. Aber wieso klappt das ausslesen des einen Flashbausteins IMMER und das des anderen NIE? Ich meine wenn es so schlecht steht dann wuerde ich auch erwarten das es mit dem anderen Baustein wenistens ab und an mal ein Problem gibt. Ich hab mir die Signale heute auch mal auf dem Oszi angesehen. Ich sage mal so, ich habe schon schoeneres gesehen, aber ich denke das sollte laufen.
Hier mal der Datenausgang des Flashs:
formatting link
Die Signale sehe auf dem Oszi gleich aus.
Ausserdem sieht man auf dem Logicanalyzer immer das der Prozessor
32Bit einliesst. Er taktet vier Bytes recht schnell rein, danach kommt ein kleines Paeuschen bis er sein Register leer macht und dann kommen wieder vier Byte. Man sieht also an diesen Viererbloecken schon das die Anzahl der Takte stimmen muss.
Oh...und das anstecken des Logicanalyzer, was immerhin die Leiterbahnlaenge am Bus verfuenffacht, hat auch keinen Einfluss. Weder positiv noch negativ.
Etwas sorgen macht mir allerdings die Betriebsspannung. Hier mal die 3.3V erzeugt mit einem LowDropregler:
formatting link
Ich denke mal gegen 50mv Stoerungen auf der Spannung kann man nichts sagen.
Aber die 1.2V sehen so aus:
formatting link
Da sind 200mV mit 100Mhz drauf. Aechz!
Aus Mangel an herumliegenden Alternativen erzeuge ich die 1.2V im uebrigen mit einem LM317. Ist dagegen was zu sagen? Die Platine hat natuerlich bergeweise 100nF an jeder Versorgungsleitung und der Regler hat einen 10uF zusaetzlich am Ausgang.
Der naheliegendste Gedanke ist ja das die 100Mhz garnicht auf der Versorgung sind sonder ueber das Massekabel des Tastkopfs einkoppeln, aber ich finde die 100MHz halt nur bei den 1.2V und nicht bei den 3.3V so deutlich und der MAsseanschluss war da identisch.
Ausserdem finde ich die 100MHz sowieso schon merkwuerdig. Der Prozessor laeuft mit einem externen Takt von 18Mhz und macht sich daraus 144Mhz. Intern erzeugt er sich noch 36 und 72MHz. Da passen die
100Mhz irgendwie garnicht rein.
Ausser, tja aussser mein 50Mhz Quarzoszillator den ich zu testzwecken mal an den USB-Anschluss geloetet habe. Die Frequenz wird aber derzeit noch garnicht genutzt. Aber vielleicht arbeitet der ja als fieser Stoersender. Ich mach den mal ab...
Sieht ja gruselig aus ... hast du auch eine Aufnahme vom SCK-Signal?
Auch kann die Empfindlichkeit der SCK-Eingänge unterschiedlich sein.
Naja, da der Takt vom Prozessor vorgegeben wird, wundert das nicht. Aber ob der Flash nicht noch die eine oder andere Flanke vom Überschwingen an SCK "sieht" und sich dadurch verzählt, kannst du daran nicht erkennen. Gerade beim "Read Array"-Kommando tödlich.
Auf deinem Bild schimmern durch die Platine Bereiche mit verschiedenen Farben. Darin habe ich geglaubt eine Masse zu erahnen die (speziell im Bereich des SPI Busses) eher einem Flickenteppich aehnelt als einer geschlossenen Flaeche. Bei dreistelligen Megahertz ist ja aber auch ein "Umweg" von wenigen Zentimetern nicht mehr vernachlaessigbar ... ausserdem habe ich sowas selber schon oefters 2-lagig geroutet und bei einem Gehaeuse mit so kleinem Pitch und so vielen Pins will ich einfach nicht so recht glauben, dass es da keine Probleme gegeben haben soll die Flaeche intakt zu halten.
Ein Bild der Platinenunterseite wuerde solchen Spekulationen uebrigens ein jaehes Ende bereiten ;-)
Zum Absturz reich ja schon ein falsches Bit. Nach Murphy triggert das Oszi natuerlich nie auf einen Bereich mit fehlerhaften Daten solange auch fehlerfreie Bereiche vorhanden sind ...
Also wenn die 1V overshoot real sind, dann ist das IMHO bei 3V Supply gar nicht gut.
Das ist in der Tat seltsam, wenn es am Limit laufen wuerde haette man da eine Veraenderung erwarten duerfen.
Wenn er die 100MHz nicht durch irgendeinen Effekt selbst erzeugt eigentlich nicht.
Es stellt sich die Frage ob mit dem 2-lagigen Layout die Blockkondensatoren ausreichend gut angebunden werden koennen ...
Bei einem AVR mit 16MHz geht so ein Layout, fuer 144MHz waeren aber Versorgungsflaechen parallel zur Masseflaeche schon nicht verkehrt. Deswegen bauen die Hersteller solche Chips doch heute normal in BGA-Gehaeuse, die kriegt man ohne Multilayer gar nicht erst geroutet ;-)
Micha
--
Irgendwann wird die Welt untergehen und das juengste Gericht kommen,
steht in der Bibel. Aber sicher nicht aufgrund des Fehlens von
Railtaxis ;-)
Joerg in defa
Die kamen wirklich alle von dem 50Mhz Oszillator den ich freischwebend rechts neben dem Controller verdrahtet hatte. Erstaunlich das der kleine Racker so einen Radau machen kann.
Die 1.2V sehen jetzt super aus. Vorher hab ich da auf meinem Tek465 (100Mhz) einen breiten Streifen gesehen. Jetzt nur noch einen der unwesentlich dicker ist als das Rauschen des Oszis bei maximaler Verstaerkung.
Ich vermute und hoffe auch mal das die Taktleitungen zum Flash nun sauberer aussehen. Leider kann ich das nicht sagen da sie mit meinem
100Mhz Ossi auch vorher schon gut aussahen. Und fuer die Datenleitungen braucht man wohl wirklich mal ein schnelles DSO. Muss ich wohl am Dienstag mal in der Mittagspause kurz an den 2008 haengen.
Oh..und das was Buerklin da als 48Mhz Quarz ohne weiteren Kommentar verkauft sind Oberwellenquarze. Allerdings hatte ich das irgendwo schon erwartet....mal sehen..
usb 2-1.4: new high speed USB device using ehci_hcd and address 5 usb 2-1.4: New USB device found,idVendor=045b, idProduct=0020 usb 2-1.4: New USB device strings:Mfr=0, Product=0, SerialNumber=3 usb 2-1.4: SerialNumber: 000000000000 usb 2-1.4: configuration #1 chosen from1 choice cdc_acm 2-1.4:1.0: ttyACM0: USB ACMdevice usbcore: registered new interfacedriver cdc_acm cdc_acm: v0.26:USB Abstract ControlModel driver for USB mod ems and ISDN adapters
BTW: Interessant als was der Debugger erkannt wird...
Erinnert mich daran, daß ich versehentlich den Lattice-programmer umgeflasht habe, nun wird er als unser Prüfgerät erkannt *grompf* Die Deppen, keinerlei Schutz des Programms implementiert, und den gleichen USB-chip wie wir verwendet. Ich bei der Erstinbetriebnahme von paar Dutzend Baugruppen nur noch stupde USB-chips geflasht und dabei irgendwie das Lattice-Dings erwischt, das sich nicht gewehrt hat und überschrieben wurde :-( Seither liegt er tot 'rum...wenn jemand so einen hat, wäre ein EEPROM-dump toll :)
-ras
--
Ralph A. Schmid
http://www.dk5ras.de/ http://www.db0fue.de/
http://www.bclog.de/
So, das Problem ist geklaert. Jedenfalls irgendwie!
Ich hab das Board mit dem funktionierenden Flash gebootet und mit der Entwicklungsumgebung verbunden. Dann habe ich die /CS umgestoepselt und von der Entwicklungsumgebung aus das Problemflash gebrannt. Das hat auf Anhieb funktioniert! Und nun laeuft das auch.
Dabei ist mir aufgefallen das mein Flashprogramm unter HEW immer
64kByte brennt, mein USB-SPI-Flasher dagegen nur 32kByte.
Jetzt koennte man ja sagen: AHA! Wenn man so bloed ist nur das halbe Flash zu brennen dann kann es ja nicht gehen. Allerdings ist der Bootloader nur 24k gross und liegt auch am Anfang. Daher ist noch nicht ganz klar warum es nicht geht. Aber auf jedenfall ist es ein Problem mit der Software und darum hier OT. :-)
Von wegen Masseflaechen, vollkommen ueberbewertet. :-D
Lustig ist der Analogfernseher den wir draussen im Garten schonmal benutzen. Abends, wenn es schon dunkel ist. Wenn wir das Drahtlostelefon daneben liegen lassen und es klingelt waehrend wir gerade weiter weg sind sieht man das. Der Bildschirm faengt einen Veitstanz mit abstrakter Malerei an, es flackert wie in der Disco.
--
Gruesse, Joerg
http://www.analogconsultants.com/
"gmail" domain blocked because of excessive spam.
Use another domain or send PM.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.