Hi! Ich hab da ein paar ältere Digitale Servo Drive Karten für BLDC Antriebe mit TTL Encoder Feedback, mit denen ich hobbymäßig eine Pick and Place Maschine bauen will. Antriebe sind X-Y Linearmotoren und Z mit Spindel. Auf der Karte ist ein ST10F167, ein FLU 10/100 von Elmo motion, sowie der Chipsatz von pmd mc1231a verbaut. Mit einem Testmotor hab ich schon erste Fahrversuche gemacht, scheint ganz OK zu sein, aber beim ersten Einschalten bestromt er volle den Motor durch, und da hab ich Angst, wenn ich ihm da mit richtig Wumms Strom liefern würde, würde es mir den Motor abbrennen. Nach gewisser Zeit regelt er den Strom, und alles ist OK. Ich möchte gerne diesen Chipsatz gescheiter benutzen, und sein Einschalt-Fehlverhalten korrigieren, leider ist der Code größer als 4096 bytes. Davon ist der Keil PK166 Eval beleidigt, und ich kann nicht weitermachen. Hat irgendwo jemand eine Vollversion / Lizenz rumliegen, die er nicht mehr braucht und, die ich mir leihen könnte? (Kann man dieses Limit irgendwie aushebeln?) Oder soll ich direkt mit Keil reden? Gibt es open source C166 compiler? Den von Hitex o.ä. gibt es nicht mehr. Hat den noch jemand? Wie bekomme ich den code in den Chip? Es schaut nach einem RS232 Protokoll aus... mfg Martin
Mit einem C-Compiler kann ich zwar nicht dienen, aber zum Flashen dieses hier: http://www.keil.com/appnotes/docs/apnt_157.asp
Danke für den Tip. Leider finde ich nirgends mehr das ST10 Flasher tool. Sogar der http://www.hitex.co.uk/c166/utilities.html Link ist nicht mehr aktiv, auf den sich so manche berufen. Einziges was ich gefunden hab ist ein .rar mit Passwort geschützt, das ich aber nicht kenne. Kann mir jemand den ST10 flasher bitte zusenden? Das mit dem Compiler Limit hab ich gelöst :D (ollydbg ist dein Freund :D ) Frage ist nur, ob das, was der Compiler mir da bietet auch funktioniert.
Ich finde es auch nicht mehr. Irgendwie habe ich in Erinnerung, dass man den exakten Namen des Zipfiles in Google eingeben muss. Vllt. kannst du hiermit was anfangen: http://www.rigelcorp.com/rfli.htm
Es handelt sich nicht um die neueste Version, aber sie funktioniert (an meinem Autoradio getestet). Falls dir im Gegenzug der grenzenlose Compiler unter die Finger kommt, wuerde ich mich ueber eine Nachricht freuen :) VG
Ihr seid die Helden des Tages! Mann, das ist es was ich gesucht habe! DANKE! Hab noch da die Hürde mit den Com port zu meistern... Mal sehen, ob das klappt...
Danke für deine Nachricht g. Hürde? Com-Port? Du musst den richtigen Anschluss nur auf COM1 erzwingen.
Das geht irgendwie nicht. Er denkt dauernd, er sei besetzt. Aber von wem, wenn ich noch garnix nach dem Booten gestartet habe außer dem Flasher? Ich hab einen direkten Com port. (keine USB-COM Nachahmung) Vielleicht kann der Flasher unter Win7 damit nix anfangen... Ich versuchs mal weiter.
Versuch mal, den Port mit einem anderen Tool zu oeffnen. Hterm o.ae. Ich verwende das Tool selbst auch unter Win7_64, allerdings mit einem USB->Serial Wandler.
Hab den Com Port jetzt frei bekommen. Jetzt ist die Anzeige grün... Mal sehen, ob ich die Teile geflasht bekomme... Nur zur Sicherheit: Der ST10F167 hat da am TX und RX nur 0..5V, gell? Aber der VPP muß 12V sein, stimmts?
Zu den Spannungen kann ich gerade wenig sagen. Ich vermute aber, dass da nirgends 12V noetig sind. Kommuniziert das Tool denn auch korrekt mit dem Monitor auf dem uC? Wenn, dann kann eigentlich nichts mehr schiefgehen :)
Die Spannungen stimmen schon, die 12 V werden tatsächlich noch benötigt. Monitor braucht es keinen, die haben einen festen BSL eingebaut.
...der initial 32 Bytes erwartet, in denen du deine Firmware unterzubringen vermagst? Eigentlich laedt der ST10 Flasher zunaechst mal den Monitor hoch, welcher vom RAM ausgefuehrt die Programmierung des Flash uebernimmt. Ohne geht es nicht sinnvoll.
Ja, das funktioniert so. 1. BSL lädt 32 Bytes (=ca 16 Befehle) Programm 2. Sprung zu dem 1. Byte. 3. in diesem Programm kann man dann alles machen was man will. 4. Loader für Monitor ins Ram runterladen. 5. Monitor macht dann die Aktionen und lädt auch manchmal neue Programmteile runter um verschieden Sachen auszuführen.
Ja, das wäre die Theorie. Praktisch schaut das so aus: (Hab Win7 Pro) Lämpchen grün, die Serielle Schnittstelle schaufelt auch genügend Daten hin und her, aber wenn ich dem Flascher sage, er soll ein Dump machen kommt dieser runtime error 383 und das Program stirbt. Beim Blank check meint er ich hab keine richtigen Blocks ausgewählt. Aber ich kann gar keine auswählen. Also Programieren hab ich mich noch nicht getraut. Ich will erst mal das Original aus dem Flash abspeichern, damit ich wenigstens etwas als Sicherungskopie hab. Eine Idee? Auch das Hex File zeigt keine Blocks an... Liegts am Win7? Hab da ihm schon Admin rechte gegeben...
:
Bearbeitet durch User
Naja, der Speicher wird gelockt sein, dann kannst du ihn nicht auslesen. Was mich skeptisch macht ist die Anzeige: CPU: ST10 no Flash. Der Flasher halt wohl den Chip nicht sauber erkannt. Als Linuxer hatte ich mit keinem Tool Erfolg die C16x-Derivate zu flashen. Mit meinen eigenen Routinen ist das kein Problem. Kannst du Windows programmieren? Dann kriegen wir das schon hin.
:D Linuxer? :D Da ich Windows nur zum Skypen und andere Entwicklungswerkzeuge brauche, aber alles andere über Ubuntu Linux erledige, bin ich in beiden Welten daheim. Die Linux Welt gefällt mir aber viel besser, und da ich die Steuerung auch im Ubuntu mache und der PC schon bei der Maschine im Kämmerchen steht, würde ich dich gerne fragen, ob du so freundlich wärst uns deinen Linux-Flasher zu teilen. Das würde dieser sinnlosen Sucherei, Emuliererei und dem Wildwuchs an Windows Derivaten und Problemen derer ein Ende machen... Speicherlock: Kann schon sein. Wenn ja, kann man dann den Speicher noch löschen und wieder programieren? Zur Aufheiterung, Anbei ein Foto meiner Maschine in der Speisekammer :D Meine Frau duldet das z.Z. noch erstaunlich gut.
Au mann... Wer lesen kann ist im Vorteil ;D Hab grade im installationsordner vom Flasher die Dokumentation gefunden und da steht drin: "Actually the software is not able to work with the ST10F167. This is due to the internal BSL that doesn’t respect the standard BSL of the ST10: the XRAM isn’t enable (XPERCON=0, SYSCON.2=0) and IDCHIP=0. These points seem not documented." Was nun? Ich denke das mit dem ST10F167 wird eine längere Tortur...
Merkwürdig, wer hindert die Herren das XRAM zu enablen (bset syscon.2)? Klar kann ich dir meine Tools zukommen lassen, die habe ich bisher aber nur für Infineon-Derivate benutzt, d.h. die werden wir etwas anpassen müssen. Hast du ein Usermanual für den F167? Ich finde nur ein Datasheet, das könnte etwas dünn sein. Kannst du mit der Maschine spielen ohne dass etwas kaputt geht (Endstufen abtrennen ...)?
Hab noch einen Probe BLDC Motor mit Encoder, und ein Labor Netzteil, das macht die Angelegenheit sicherer. Also das User Manual hab ich hier gefunden: http://www.datasheetarchive.com/dl/Datasheet-03/DSA0037340.pdf Da ist der BSL auf Seite 177 beschrieben. Eigentlich ausreichend.
Ok, danke für den Link, das sieht exakt so aus wie beim C167. AN490 von STM beschreibt das Flashen, dann könnten wir mal anfangen. Kennst du dich mit Lazarus aus? Edit: Wie lang ist dein Programm und wohin soll es geflasht werden (ich vermute unter 32 kB und Segment 0)?
:
Bearbeitet durch User
Lazarus? Nein. Nur aus der Bibel... C und C++ mit GCC, Python, oder die Keil Umgebung kenne ich. Der code ist ca 15000 bytes lang...
Ok, Martin, ich fange mal an. Erstmal sollten wie den F167 sauber auslesen können, sofern er nicht gelockt ist. Ich melde mich wieder.
Hi Guido! Den ersten Erfolg hab ich bereits. Hab den Keil a166 assembler dazu gebracht mir gescheiten code herzustellen, und ich habs geschafft einen Preloader in den RAM zu speichern. Dann hab ich es geschafft mit dem Preloader ein Programm runterzuladen, das nix anderes macht als zu zählen und mir die Zahlen zu senden. Kommunikation geht also mit Ubuntu Linux. Also es kann jetzt weitergehen, um den Flash auszulesen. Hast du da Algorithmen parat? Wenn ja, bitte teile sie mit uns.
Hallo Martin, das ist im Grunde einfach. Erste BSL-Stufe schicken, die lädt die zweite und diese enthält den Code um den Flash auszulesen und an den PC zu schicken. Die beiden Stufen habe ich, ich muss jetzt nur mein Lazarus-Programm hierfür so erweitern, dass es die Daten empfängt und speichert. Schaffe ich vielleicht heute abend. Dann brauchen wir eine 2. BSL-Stufe die den Flash programmiert, wie man vorgehen muss findest du am besten in der AN490/0592 und dem Datenblatt des F166 beschrieben. Das muss ich auch in Assembler erstellen. Eventuell muss ich auch für diesen Schritt noch mein Programm anpassen, damit das nötige Timing eingehalten wird. Bisher habe ich damit nur C16x mit externem Flash bearbeitet. Es sind keine großen Änderungen nötig, ich hatte aber wenig Zeit.
Ok Martin, dann kannst du mal probieren. Die Anwendung ist "bslflash", du musst die Schnittstelle anpassen, Baudrate sollte so funktionieren, CPU ist noch egal. Flasher ist F167_1_0.bin, als Anwendung kannst du einen Namen eingeben, wenn du sie frei lässt wird "code.bin" verwendet. Dann den "Read 32kB"-Button drücken, entweder es klappt oder nach ca. 20 s bricht das Programm ab. Beim Keil-Geraffel sollte auch ein Disassembler dabei sein, damit kannst du schaun, ob der Code Sinn macht. Für die Mitleser hänge ich noch ein Bildchen an, dann müssen diese nicht soviel downloaden.
Danke für die SW. Wie genau muß ich die Schnittstelle anpassen? Leider gehts bei meinem nicht so einfach. Ich benutze einen FTDI USB zu Seriell converter. Ich hab 9600 eingestellt. Wenn ich "Connect" sage, passiert nichts. Es sendet keinen Preloader o.ä. runter. Wenn ich "Read" sage, dann sendet er was an den Chip, der macht aber ein Reset und das Programm beschwert sich, "send flasher: no reply". und "disconnected" Vielleicht kannst du mir mal die Flasher src und die src deines Preloaders senden, damit kann ich vielleicht ein Program in C oder python schreiben. Natürlich ist die src deiner PC SW auch nützlich damit ich weiß wie du mit deinem flasher redest...
Das ist eigentlich unkompliziert: Stecke den USB-Wandler an und rufe auf einer Konsole dmesg auf. Das meldet welche Schnittstelle eingerichtet wurde, vermutlich /dev/ttyUSB0, zweiter Eintrag im Pulldown der Schnittstelle. Ist es eine andere, musst du einfach den kompletten Namen in das Feld eingeben. Die Baudrate ändert bslflash selbst entsprechend der Eingabe, wenn du keine sehr ungewöhnliche Quarzfrequenz hast sollte 38400 Baud schon funktionieren. Die erste BSL-Stufe ist als String in bslflash abgelegt, da die Länge der 2. Stufe hierin noch angepasst werden muss. Quelltext:
1 | ; Flash Loader ins XRAM laden: |
2 | ; Das Ende von Stage2 an Byteposition 19 (LowByte) und 20 |
3 | ; (Higbyte) muss entsprechend ihrer Laenge angepasst werden. |
4 | cpu 80c167 |
5 | include reg166.inc |
6 | org 0FA40h ; |
7 | ; |
8 | bset SYSCON.2 ; enable XRAM |
9 | mov R0, #0E000h ; Start of XRAM |
10 | loop |
11 | jnb S0RIR, loop |
12 | bclr S0RIR |
13 | movb [R0], S0RBUF |
14 | cmpi1 R0, #0E1A3h ; Endwert muss angepasst werden! |
15 | jmp NE, loop |
16 | nop |
17 | nop |
18 | nop |
19 | jmp stage2 |
20 | org 0E000h ; Start of XRAM |
21 | stage2 |
22 | END |
Connect kannst du klicken oder auch nicht, wenn nicht macht es das Programm von sich aus. Erst beim Klick auf "Read 32 kB" oder "Senden" passiert etwas, "Senden" muss für den F167 erst noch angepasst werden. Der erste Schritt hat wohl geklappt: Der PC sendet 0 und der F167 antwortet mit 0xC5. Der Download von Stage2 klappt nicht (send flasher: no reply), ev. ist das XRAM doch nicht verfügbar, dann muss ich das auf IRAM anpassen. Stage2 ist etwas schwierig, weil ich sowas mit meinem eigenen Compiler mache. Angucken darfst du das aber auch, siehe Anhang.
Ich habs geschafft, den Flash teilweise zu lesen. Nur teilweise, da ich die DPP noch nicht richtig benutze. Ich hab aber ein komisches Verhalten bemerkt. Sobald ich vom XRAM versuche zu lesen, kommt er in ein TRAP oder Reset.(weiß ich, da im original Programm das benutzt wird, und die LEDs entsprechend blinken) Hab ich den Syscon richtig eingestellt? Also ich will den XRAM an haben, und den Rom auch lesen. Anbei meine Sourcen.
Wäre natürlich interessant, was für ein Trap das ist. Stack-Over- Underrun? Die Initialisierung der zugehörigen Register hast du ja auskommentiert. Grundsätzlich sieht SYSCON gut aus allerdings weiß ich nicht, was per Hardware dort gesetzt ist. Nicht einfach überschreiben, nur Bits setzen oder löschen! Segmentierung sollte enabled sein. Die DPPx stimmen schon.
Hab es nicht herausbekommen, was der Fehler sein kann, warum ich nichts im Bereich 0x8000-0xefff im BSL Modus lesen kann. Find ich komisch. Ich hab aber ein Tool gefunden, das in der Dosbox erfolgreich auch im Linux funktioniert: ap160860 Der Link ist: http://ep.etc.tuiasi.ro/site/DIVERSE/placi/CAN/34/3461.htm http://ep.etc.tuiasi.ro/site/DIVERSE/placi/CAN/34/pdf/ap160860.pdf http://ep.etc.tuiasi.ro/site/DIVERSE/placi/CAN/34/exe/ap160960.exe Im Wesentlichen ist der C167CR-16F mit dem ST10F167 gleich aufgebaut. Mit adis16x hab ich die von mir ausgelesenen Daten disassemblieren und auch in Hex format konvertieren können: http://ep.etc.tuiasi.ro/site/DIVERSE/placi/CAN/34/exe/ap164002.exe http://ep.etc.tuiasi.ro/site/DIVERSE/placi/CAN/34/pdf/ap164002.pdf Ich hab es also mit meinen Tools geschafft den Inhalt des Flashs erfolgreich ausulesen, zu speichern, in hex umzuwandeln, ein anderes Hex auf den Kontroller zu laden, auszuprobieren und danach das Original wieder auf den Kontroller zu flashen. Ich bin der Meinung, diese Seite wo ich all die obigen Progis gefunden habe auf Mikrocontroller.net zu archivieren, bevor es auch noch verschwindet. Leider hab ich nicht so viel Erfolg mit meiner eigentlichen Anwendung. Da hab ich bemerkt, daß der Keil zwar SYSCON in den Target Optionen die richtigen Häkchen hat, aber beim generierten Code nicht mehr das richtige SYSCON eingestellt wird. Sprich, weder mein FlashRom wird aktiviert, noch das XRAM aktiviert. Ich denke es Liegt am START167.A66 das da nicht mit dem Keil mitmacht. Ist das schon mal bei euch passiert? Was mach ich dagegen?
Hab den Grund für den Trap gefunden: Seite 13: X11: Illegal Bus Trap after XPER access in Single Chip Mode http://ep.etc.tuiasi.ro/site/DIVERSE/placi/CAN/34/pdf/16errata/167flash/esac12.pdf Das trifft voll auf mich zu, da ich im Single Chip Modus bin, und keine anderen Speicherchips habe. Workaround: mov BUSCON1, #04C0h ; Am Anfang des Codes. Und man darf den P0 nicht mehr als IO benutzen. Jetzt kann ich auch den XRAM und CAN bus Register lesen und schreiben mit meinen Tools. Ich hätte nie gedacht, daß die Teile sooo kompatibel miteinander sind. Im Anhang die geänderten Dateien fürs Auslesen
Prima Martin, das muss ich mir merken. Einen F167 werde ich zwar nicht mehr ergattern aber ich habe noch 3 C167CS-32FM. Kompatibilität ist klar, es war von STM ja ein 1:1 Nachbau. Erst mit den F2xx wurden Unterschiede und ungewöhnliche Kombinationen realisiert.
Bitte 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.