Hallo, Ich habe ein ATMEL SAM7 Board von Olimex (wie hier in Shop) mit dem Wiggler (auch von Olimex). Leider bekomme ich keinen Code ueber Crossworks in den Mikrokontroller. Wenn ich JTAGSEL (BDS jumper auf dem board) auf HIGH (VCC) lege, bekomme ich eine "target not responding" Meldung. Wenn ich JTAGSEL auf LOW(GND) lege, kann ich zwar eine Verbindung herstellen, stimmt aber der geflashte Code mit der Datei beim Verifizieren nicht ueberein. Hat schon jemand von Euch mit Olimex SAM7+Wiggler+Crossworks Erfolg hehabt? mfg, r.
Hallo, ich glaube, ich habe mir einbisschen selber geholfen. Vielleicht hilft es auch weiter jemandem. Also ich bin im Besitzt eines Olimex ATMEL ARM Boards und eines "Wigglers". Ich habe versucht in Crossworks den Flash zu beschreiben. Es ging, aber die Verifezierung hat immer fehlgeschlagen. Ich "spielte" mit den Einstellungen fuer Oszillator und fuer JTAG teile ohne Erfolg. Da ich mit JTAG nicht weiter wusste, habe ich SAM-BA installiert. Die Verbindung mit dem Board hat auf Anhieb geklappt. Ich habe "Erase Flash" geklickt, worauf die folgende Meldung kam: "Cannot continue because at least one of the involved blocks ist locked. Should it be unlocked? J/N" Nach dem Loesch-/Unlockvorgang habe ich den Wiggler wieder angeschlossen und auf einmal ging es. Leider kann ich das Ganze noch nicht erklaeren, aber vielleicht hilft die Geschichte jemandem.
Hallo, ich kriege das gleiche Problem. Ich habe ein Olimex Wiggler und installierte Crossworks. Irgenwie bekomme ich immer die Fehlermeldung "target not responding". Hat jd es mit diesen zwei sachen geklappt, die Programme zu flashen? Falls es funktioniert, dann werde ich weiter versuchen. Ich habe auch in Webseite von Crossworks gelesen, bei dieser Fehlermeldung gibt es folgende Möglichkeiten: This error message could be caused by the following: 1, Incorrect ARM Debug Interface Type Check that the Target > ARM Debug Interface project property matches the type of target you are trying to connect to. 2, Unreliable JTAG Connection Try reducing the JTAG clock frequency or reducing the target interface's cable lengths as much as possible. Link unter: http://ccgi.rowley.co.uk/support/faq.php?do=article&articleid=2
Per OpenOCD koennen die SAM7 Lock-Bits auch ueber einen Wiggler-Adapter geloescht werden. SAM-BA muss also nicht unbedingt sein. http://openocd.berlios.de/web/ http://www.mikrocontroller.net/articles/AT91SAM7S_mit_OpenOCD_programmieren http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/openocd_intro/index.html (letzteres "Eigenwerbung") Martin Thomas
Danke für deine Antworten! Aber ich habe kein Board dabei. Mein µC ist ADuC7027. Ich weiss mit OpenOCD geht es. Aber ich habe schon Crossworks, ich wollte fragen, Crossworks+Olimex Wiggler geht nicht????? Falls es geht, dann gibt es Problem in meiner Platine. Fall es nicht geht, werde ich OpenOCD benutzen. Ich hoffe ich nerve euch nicht. Gruss Yaolan
Ich kenne den ADuC7027 nicht, aber die Kombination Crossworks und "Wiggler" (auch Nachbauten wie der von Olimex) funktioniert auf den ernstgemeinten Windowsversionen (2000, XP etc.) hervorragend; bedeutend besser beispielsweise als ein Original-Wiggler von Macraigor mit Macraigors "OCD Commander". Daher vermute ich, daß ein Problem mit Deiner Schaltung vorliegt oder aber daß die verwendeten Kabel möglicherweise zu lang sind - wie lang ist das zwischen Deinem PC und dem "Wiggler", wie lang ist das zwischen dem "Wiggler" und dem JTAG-Port Deiner Platine?
Hallo Leute, ich benutze auch das o.g. Olimex Board mit Wiggler und Crossworks. Nach Startschwierigkeiten wie sie auch romanua hatte, kann ich jetzt Code ins RAM schreiben. Beim Versuch den Flash-Speicher zu programmieren gibt es bei mir auch die Verifier-Fehlermeldung. Nach Kontakt mit Rowley habe ich eine Vorabversion von Crossworks 1.6 bekommen. Diese meckert nicht mehr über Verifier-Fehler sondern meldet, dass der Speicher gesperrt ist. Ich hätte vermutet, dass Crossworks den Speicher einfach unlocked, aber das scheint nicht so zu sein. Meine Idee ist jetzt, ein Programm zu schreiben, dass alle Seiten des Flash unlocked. Danach sollte es doch möglich sein, in den Flash zu schreiben. vgl. Manual: [q] The Flash Command register must be written with the following value: (0x5A << 24) | (lockPageNumber << 8 & PAGEN) | CLB lockPageNumber is a page of the corresponding lock region. [\q] Komme vielleicht heute abend dazu und werde dann berichten. Gruß, Nils
Hallo, Das Problem mit gesperrten Seiten musste ich immer wieder bekaempfen, da bei mir folgendes Scenario oft aufgetreten ist: 1. inkorrektes Program geflasht. 2. nach dem Reset, kann Target nicht ueber JTAG gestoppt werden, weil das Program im Flash nach dem Reset Ammok laeuft. Was tun? 3. Samba Firmware ins Flash duch das Schliessen des TST Jumpers uebertragen. Ab jetzt ist zumindestens ein korrekter Code im Flash, aber die Seiten sind gelockt. 4. Samba software starten und das Borad anschliessen. Im Samba Program 'Erase entire Flash'(oder aenliches) auswaehlen. Kommt die Frage, ob die Seiten unlocked werde sollen->'Ja' 5. ab hier gehts es mit Crossworks wieder. Nils, wenn Du in Crossworks 1.6 "Erase All" clickst, was passiert? Bei mir in 1.5 passierte nichts, egal, ob jetzt die Seiten gelockt waren oder nicht.
Hallo romanua, Ein Angeclicktes "Erase all" ändert nichts, weil Crossworks durch die gesperrten Seiten keinen Zugriff hat. Ich würde ja die Samba 'Erase entire Flash' Methode anwenden, aber ich nutze Crossworks unter Linux. Deshalb werde ich die Seiten wohl von Hand entriegeln müssen. Gruß, Nils
Hallo Nils, Du hast schon damit Recht, dass das Problem der gesperten Seiten gruendlich angeprochen werden muss. z.B. mit so einem Program wie Du vorher aus dem RAM ausfuehren wolltest. Ich wollte bloss wissen, ob Crossworks 1.6 vielleicht die gleiche Funktionalitaet wie 'Samba' bekommen hat und wuerde dich fragen, ob Du Seiten unlocken willst. Die Hoffnung hat mir folgende Zeile in SAM7 Manual Seite 20 gegeben: Asserting the ERASE pin clears the lock bits, thus unlocking the entire Flash. Gruss, R.
Ich dachte es geht irdenwie ueber JTAG Erase pin zu asserten. Obwohl, ich gebe zu, ich hab nicht nachgeschaut, wo Erase Pin ueberhaupt ist.
Über die erwähnte Textzeile bin ich auch schon freudig gestolpert, aber leider gibt es keinen Jumper/Taster dafür. Der Erase Pin ist Pin 55 am AT91SAM7S64..256 (Pin42 bei AT91SAM7S32). Er ist am Olimex-Board leider nicht angeschlossen. Daher werde ich ein Programm fürs RAM schreiben, das die Lockbits entfernt und den Flash löscht. Dann braucht man bei fehlerhaftem Code im Flash zwar noch den TST-Jumper damit wieder korrekter Code im Flash ist, aber man spart Samba, um die Bits zu löschen. Werde berichten, ob es funktioniert. Gruß, Nils
Vielen Dank für eure Antworten. @Rufus, ich denke auch, dass von µC Kern bis zum JTAG connetor zu weit weg ist. Jetzt bei mir sind die Lange zwischen µC und JTAG etwa 2cm-5cm. Von JTAG Anschluss auf der Platine bis PC dauert ungefähr 0,5m. Da die Platine habe ich schon gelötet, ich schaffe es nicht den Abstand zwischen JTAG und µC zu verkleinern. Und die Länge des Kabels an Pc hat es auch gestört? Keine Ahnung wo liegt das Problem...
Hallo Leute, habe ein kleines Programm geschrieben, das die Flash-pages unlocked und den Flash löscht. Das führe ich im RAM aus. Anschließend kann ich mit Crossworks den Flash beschreiben. So kann ich unter Linux programmieren und komme ohne Samba aus. @romanua: Der Verifier meldet beim Debugen Unterschiede, obwohl keine Unterschiede vorhanden sind. Ein extra Verifier-Durchlauf zeigt dann, dass keine Unterschiede vorliegen. Das Verhalten zeigt sich sowohl unter Windows als auch unter Linux. Hast Du das auch? Gruß, Nils
@Nils Das stimmt. Das Verifizieren faellt immer durch, obwohl es keine Unterschiede vorhanden sind. Das sieht man auch beim ersten Durchlauf, wenn man die Meldung 'Verifier has found errors. Do you want to compare the differences.' mit 'ja' beantwortet. Zwischen beiden Vergleichfenstern gibt es keine Unterschiede dann, es sei denn es gab gesperrte Seiten. Ich habe das Netz zum Thema durchsucht. Es gibt auf www.embeddedrelated.com paar Meldungen dazu. Da sagt anscheinend ein Rowley Mitarbeiter, dass es an der Loader.exe Datei fuer SAM7 liegt. Das oft vorgeschlagene Reduzieren der Geschwindichkeit des JTAGs hilft nicht (bei mir sicher nicht). Man solle sich bei Rowley melden, um eine reparierte Datei zu bekommen. Ich habe es nicht gemacht, da man der Code an sich richtig geflasht wird. Hier weiter lesen: http://www.embeddedrelated.com/groups/AT91SAM/show/802.php Nils, Hast Du vor dein Entsperrprogram zu posten?
@romanua Die Loader.exe habe ich mal von Rowley bekommen. Habe sie noch nicht probiert, weil ich bisher dachte, dass sie in meiner Crossworks Vorabversion 1.6 enthalten sei. Ich werde die neue Loader.exe aber heute abend mal probieren. Wenn es erfolgreich ist, maile ich sie Dir gern (ich weiß nicht, was Rowley davon hält, wenn ich sie hier poste). Klar kann ich das kleine Programm zum Entsperren der Flash-Pages hier posten. Werde noch ein wenig kommentieren und dann poste ich es.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.