Experimente mit aelterem DSP

Hab mir gedacht, hier frag ich mal nach. Ich habe also einen älteren DSP, nämlich dem 56001 von Motorola. Der mag nicht so recht. Ich hab e allerdings die Busleitungen mit 15 KOhm nach +5Volt versehen, weil sie im Reset-Zustand alle im Tri-State sind. Das simple Testprogramm steht in einem EPROM ab der Speicherstelle P:$C000 und sieht so aus:

Main MOVE P:$C000,A NOP NOP NOP JMP Main

Im Programmspeicher des DSP finden sich zuerst die Vektoren für die

Unterbrechungen, ab der Speicherstelle $0400 steht dann der Programmcode. Zumindest im Listing sieht das gut aus. Ich habe zu Fuß die Adresse P:$C000 auf dem Adressbus verdrahtet, tatsächlich wird d as EPROM damit erreicht und liefert auch das an dieser Stelle zu erwartende

Datum ab.

Ich will nach Reset am Chip-Select vom EPROM mit dem Programmcode LOW-Nadeln sehen. Stattdessen zählt der DSP seine Adressen durch. La sse ich das EPROM weg, tut er das allerdings nicht. Ich habe den Eindruck, daß sich der DSP bereits beim Bootstrap des Programmcodes verschluck t. Das wäre dann ein Busproblem. Also: Was sollte ich tun? Terminierung der Busleitungen weglassen? Taktfrequenz kleiner wählen?

Viele Grüße, Holger

Reply to
Holger
Loading thread data ...

Hab mir gedacht, hier frag ich mal nach. Ich habe also einen älteren

DSP, nämlich dem 56001 von Motorola. Der mag nicht so recht. Ich hab e allerdings die Busleitungen mit 15 KOhm nach +5Volt versehen, weil sie im Reset-Zustand alle im Tri-State sind. Das simple Testprogramm steht in einem EPROM ab der Speicherstelle P:$C000 und sieht so aus:

Main MOVE P:$C000,A NOP NOP NOP JMP Main

Im Programmspeicher des DSP finden sich zuerst die Vektoren für die Unterbrechungen, ab der Speicherstelle $0040 steht dann der Programmcode. Zumindest im Listing sieht das gut aus. Ich habe zu Fuß

die Adresse P:$C000 auf dem Adressbus verdrahtet, tatsächlich wird d as EPROM damit erreicht und liefert auch das an dieser Stelle zu erwartende Datum ab.

Ich will nach Reset am Chip-Select vom EPROM mit dem Programmcode LOW-Nadeln sehen. Stattdessen zählt der DSP seine Adressen durch. La sse ich das EPROM weg, tut er das allerdings nicht. Ich habe den Eindruck, daß sich der DSP bereits beim Bootstrap des Programmcodes verschluck t. Das wäre dann ein Busproblem. Also: Was sollte ich tun? Terminierung der Busleitungen weglassen? Taktfrequenz kleiner wählen?

Viele Grüße, Holger

Reply to
Holger

Am 28.11.2012 04:58, schrieb Holger:

Dich mal fragen, was da 'rauskommen soll. Manche Probleme sind nämlich keine mehr, wenn man fragt. Wem nützt das?

Reply to
Hartmut Kraus

Hallo Holger,

Welchen Bootmodus verwendst Du (sprich, wie sind die MOD-Pins verschaltet?) Welche Busbreite hat das EPROM? (Wenn Du den Code direkt aus dem EPROM ausführen willst, muß es 24 Bit breit sein). Welche Taktfrequenz hat der DSP und welche Zugriffszeit das EPROM?

Tom

Reply to
Thomas Langhammer

Thomas Langhammer schrieb:

et?)

Hallo Thomas,

relativ einfach: Bootmodus ist 1, vom achtbittigen EPROM an Adresse P:$C000, Taktrate z. Zt. 25 MHz, EPROM 150 ns. Allerdings mit 15 Waitstates während des Bootprozesses. Problem scheint mir hier die Geschwindigkeit des Busses zu sein, löse ich gerade mit passiver Terminierung. 15k nach 5V, 15k nach GND. Auf jeder Busleitung.

Holger

Reply to
Holger

Hallo Holger,

die Busgeschwindigkeit ist bei diesen DSPs üblicherweise nicht das große Drama, es sei denn, die Leitungen zum EPROM sind recht lang (>5-10cm). Das EPROM müßte an D0-D7 hängen (die anderen Datenleitungen sollten zumindest einen gültigen Zustand haben, also PullUp o.ä.). Außerdem müssen die Daten im EPROM richtig gepackt sein, d.h. das erste Byte im EPROM landet an Adresse P:$0 in den unteren 8 Datenbits, das nächste Byte in den mittleren und das nächste dann in den höchsten 8 Datenbits. Das 3. Byte landet dann bei P:$1 im LSB. Und gestartet wird dann das Programm durch Sprung an die Adresse 0, d.h. das Programm müßte so assembliert sein, daß MAIN = $0000 ist.

Tom

Reply to
Thomas Langhammer

Thomas Langhammer schrieb:

große

gen sollten

das erste Byte

chste Byte

bits. Das 3.

. das

st.

Das ist alles so geregelt. Ich werde mal sehen. Bis jetzt ist es ein Lochrasteraufbau. Wenn gar nichts funktioniert, mache ich eine Platine.

Holger

Reply to
Holger

Am 02.12.2012 18:06, schrieb Holger:

Die würde ich machen, wenn ich wüsste, dass es funktioniert, und wie. Was machst du, wenn du auf der Platine den- / dieselben Fehler eingebaut hast, sie nur noch schwerer findest? Ist aber dein Problem, las' dir mal nicht 'reinreden. :-)

Reply to
Hartmut Kraus

Holger schrieb:

Hallo Holger, das erinnert mich an meine letzte berufliche Hardwareentwicklung... Alle sagten: ein 56k auf Lochraster? Bist du wahnsinnig? Aber ich habe das Gegenteil bewiesen :-) Allerdings ist das eine Zicke, und er braucht Masse, Masse, Masse! Mit einem Massegitter aus fettem Draht und vielen Entkoppelkondensatoren ging es dann schliesslich. Vielleicht kannst du da in der Richtung noch was verbessern.

Nach den Erfahrungen haben wir die Platine dann sogar zweilagig hinbekommen und großes Lob von den Kaufleuten bekommen. Und z.T. laufen die Vögel heute noch...

Viel Erfolg wünscht Jens

Reply to
Jens Carstens

Am 03.12.2012 07:54, schrieb Jens Carstens:

Ein zähes Volk, diese Kaufleute.

Gruß Dieter

Reply to
Dieter Wiedmann

Dieter Wiedmann schrieb:

Ja, nee, is klar... So früh morgens kann ich mich noch nicht eineindeutig ausdrücken :-) In Wirklichkeit laufen von DENEN heute einige nicht mehr mehr, die meisten 56k hingegen nur nicht, weil sie wegen Obsoleszenz ausgemustert wurden, nicht Unfähigkeit. Das ist aber auch manchmal semantisch anstrengend hier...

IdS! Jens

Reply to
Jens Carstens

Am 03.12.2012 08:02, schrieb Dieter Wiedmann:

:-D

Bernd

Reply to
Bernd Laengerich

Jens Carstens schrieb:

Hallo Jens,

ich habe eher den Verdacht, der aus einem ausgeschlachtetem c't-Bastelprojekt stammende Prozessor wurde vom Vorbesitzer kaputtgespielt und ist defekt. Es ist außerdem die Experimental-Version XC56000ARC27. Grund für meine Vermutung: Ich lasse den DSP ohne Zugriff auf den externen Speicher laufen, nachdem er via EPROM den Code geladen hat, nix kompliziertes. Dennoch finden externe Schreib-Lese-Zugriffe auf

den externen Speicher statt, was meines Erachtens nicht sein dürfte. Ic h habe zum Laden des Codes nur das EPROM dringelassen und dann die Leitungen WR. RD, PS, DS und X/Y gemessen. Die müßten meines Erachten s im Tri-State sein, sind sie aber nicht. Der Prozessor zählt außerdem

seine Adressen modulo durch. Wie schätzt du das ein?

Viele Grüße, Holger

Reply to
Holger

Holger schrieb:

Hallo Holger, schwer zu sagen... Das ist ja alles schon ca. 16+ Jahre her, und ich kann nur noch aus der Erinnerung reden. Soweit ich mich erinnere war das grösste Problem aber das booten, wenn er erstmal geladen war, dann wurde es deutlich einfacher. Um mehr sagen zu können, müsste ich erstmal etliche steinalte Unterlagen aus der Gruft exhumieren, soweit sie überhautp noch irgendwo existieren. Das war noch in der Papierzeit...

Grüsst, Jens

Reply to
Jens Carstens

Jens Carstens schrieb:

n

Hallo Jens,

einen DSP96002 habe ich ja schon zum Laufen gekriegt, auch auf Lochraster. Die Sache mit dem Hochzählen der Adressleitungen habe ich s o in den Griff gekriegt:

Alt:

org $0

reset JMP Main

....

Main MOVE P:$C0000, A ; Beispiel für Zugriff via Port A JMP Main

Neu:

org $0

reset JMP $40

....

Main MOVE P:$C000, A JMP $40

Das zumindest sollte er können. Schon seltsam, daß der Assembler den

JMP-Befehl mit dem Label "Main" mit 0AF080 000040 übersetzt, den JMP-Befehl mit der direkten Angabe der Speicherstelle hingegen mit 0C0040 .

Wenn der JMP-Befehl mit 0C0040 übersetzt wird, finden zumindest keine seltsamen Speicherzugriffe mehr statt. In der Hauptschleife sollte er jetzt regelmäßig das Datum an P:$C000 laden und in den Akku schieben. Das macht er selbst dann nicht, wenn man ihn via Funktionsgenerator mit nur 100 kHz taktet, ist mein Eindruck. Es gibt rund 1537 Pulse am CS-Eingang des EPROMs, was heißt, er lädt seinen Code noch in seinen

Speicher. Danach sollte er diesen Code ausführen. Scheint er nicht unbedingt zu wollen. Nach Reset lädt er sich jedenfalls seine 1537 Bytes, also er scheint den Bootstrap-Code zu laden. Aber es könnte ein

Problem mit der Geschwindigkeit des EPROMs geben, weiß ich noch nicht.

Das EPROM hat 150 nsec an Zugriffszeit, könnte also knapp sein.

Vielleicht sollte ich bei Gelegenheit den Prozessor (nach Fertigstellung

meines Systems) über das Host-Interface laden. Grübel. Auf jeden Fall würde ich bei einer Neukonstruktion die Busleitungen von Port A mit Leitungstreibern versehen. Es kann schon sehr gut sein, daß die Kapazität auf den Leitungen und der Widerstand derselben die Bandbreite zu sehr begrenzen, wobei dies bedeutet: Das System ist überfordert und

stürzt ab.

Holger

Reply to
Holger

Hallo Holger

Ich hab zumindest für den 56002 das EVM mit Doku noch griffbereit (und soweit ich weiß ist das programming model identsich zum 56001)

Bei der P-Adresse ist eine 0 zuviel drin - kann das die Ursache sein? (Adressen sind beim 56k auch nur 16 Bit breit)

Kannst Du evtl. mal das Assembler-Listing (also mit Adressen und Code) posten?

Die Befehle sind eigentlich gleichwertig:

0C0040 ist ein Fast Short Jump auf die Adresse $40 (die unteren 3 Nibbles "040" werden zero extended 0AF080 00040 ist ein Long Jump auf die Adresse $000040 Könnte sein, daß der Assembler je nach Quelladresse den Short Jump nur nimmt, wenn die oberen PC-Bits identisch sind.

Wie wird das übersetzt? Für MOVEs aus dem P-Speicher müßte man eigentlich MOVEM nehmen, aber soweit ich mich noch erinnere, machen einige Assembler-Versionen das automatisch, auch wenn man mit MOVE arbeitet. MOVEM P:$C000,A müßte laut meiner Papierdoku übersetzt werden mit

07F08E 00C000

Tom

Reply to
Thomas Langhammer

Thomas Langhammer schrieb:

schieben.

176 P:0040 07F08E Main MOVE P:$C000,A 00C000 177 P:0042 0C0040 JMP Main

nehmen, aber soweit

ch,

erden mit

Scheint der Fall zu sein. Ich werde schlauer sein, wenn ich den DSP im fertig aufgebauten System über das Hostinterface füttern kann, um dann zu sehen, was der DSP auf seinem Port A so macht. Vielleicht bestäti gt sich mein Verdacht, daß einfach das EPROM zu langsam ist. Bein EPROM habe ich OE auf low und gebe mit low auf CS das jeweils adressierte Datum frei. Vielleicht wäre es hier sinnvoll, OE und CS zu vertausch en?

Grüße, Holger

Reply to
Holger

Hallo Holger,

Sieht alles richtig aus. Und an P:$0000 müßte ebenfalls ein JMP nach $0040 stehen.

Auf jeden Fall. Denn die Adressen liegen bereits 1/2 Taktzyklus vor dem /RD- Impuls an, und die /OE-Zugriffszeit ist in aller Regel kürzer als die durch /CE. Wichtig ist noch, daß vom DSP der /RD-Anschluß verwendet wird als Lesesignal für das EPROM (nicht /PS - /PS kann aber für /CS des EEPROMs verwendet werden, wenn z.B. auch X/Y-RAM am Bus hängt). Was noch sein könnte: /BR und /HACK brauchen einen PullUp, sonst sperrt der DSP evtl. den externen Bus.

Tom

Reply to
Thomas Langhammer

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.