Motorola MC68332

"Olaf Kaluza" schrieb im Newsbeitrag news: snipped-for-privacy@criseis.ruhr.de...

Es koennte sein, dass schon der alte Motorola den Pin als output hatte,

bloss er war zu schwach um gegen den 125 anzukommen.

PQSPA0 ist also 0 fuer PQS0

DDQ0 ist 0 ?

Clearing a bit in the PQSPAR assigns the corresponding pin to general-purpose I/O; setting a bit assigns

the pin to the QSPI. The PQSPAR does not affect operation of the SCI.

PQSPAR ? PORT QS Pin Assignment Register

PQSPA0 ist 0 ?

DDRQS ? PORT QS Data Direction Register

DDQS0 ist 0 ?

PORTQS ? Port QS Data Register

PORTQS latches I/O data. Writes drive pins defined as outputs. Reads return data present on the pins.

To avoid driving undefined data, first write a byte to PORTQS, then configure DDRQS.

Das hab ich auch schon gedacht.

Ich behaupte mal ja, muss aber zugeben das ich jetzt gerade nicht in den Source schauen kann. Allerdings habe ich das schon mindestens ein Dutzend mal getan weil der Gedanke da selber was falsch gemacht zu haben ja sehr nahe liegt. Ich habe aber heute auch mal den Port ganz bewusst falsch gesetzt und es hatte keinerlei Auswirkungen. Allerdings habe ich das nur mit dem neuen Typ ausprobiert. Ich werde das morgen nochmal mit dem alten testen.

Vielleicht hat der Compiler ja schon immer eine Macke, bloss wie du schon vermutest, ist es bisher halt nie aufgefallen.

Das habe ich heute schon mindestens in fuenf verschiedenen Datenblaettern und Handbuechern gelesen. BTW: Es gibt uebrigens von irgendeiner Uni ein Script in Deutsch im Netz wo eines der Bits verkehrt rum beschrieben ist. Deshalb hatte ich es auch schonmal anders probiert.

Olaf

"Olaf Kaluza" schrieb:

Habe keine Erfahrung mit dem Baustein, also nur 'just a guess' aber nicht nur 'educated' sondern aus eigener uC-Erfahrung :)

Bei PICs z.B. hat sich schon öfter mal die Bedeutung eines gesetzten Schalters/flags für on-chip-peripherie geändert. Früher schaltete man $Modul durch setzen von flag ein, heute, vielleicht nach einer Maskenrevision, durch löschen.

Sowas kann natürlich verwirren, aber es kommt noch schlimmer...

Auch Geschalte von TRIS bzw DDR und solchen Sachen werden u.U. implizit automatisch per hardware erledigt, 'service included' sozusagen. Solche Abhängigkeiten finde ich aber, da böse potentielle Fehlerquellen, eher lästig und nicht hilfreich.

Aha, verdächtig verdächtig. Deutet ja in die Richtung...

Ich würde jetzt an dieser Stelle sorgfältig checken (altes/neues datasheet und errata sheets) und dann im Compilat gucken, was der Compiler *genau* macht. Könnte z.B. sein dass er ein flag 'richtig' schaltet, aber die Dependenzen sind geringfügig anders als früher, andere Reihenfolge oder 'früher wurde was mitgeschaltet, jetzt nicht' oder 'früher wurde es nicht mitgeschaltet, jetzt aber doch, aber jetzt sinngemäß andersrum oder auch zeitlich andersrum'...

Oder woanders im code, nicht in der Initialisierung sondern z.B. in einer ISR wird kurz was aus- und danach wiedereingeschaltet und dort stimmt zwar die Bedeutung des flags aber irgendwas fehlt oder es fehlt nix aber die Bedeutung ist anders oder es fehlt weder etwas noch ist die Bedeutung anders, aber die Reihenfolge ist wichtig und falsch... ächtz!

Drum' programmiere ich auch in Assembler immer 'explizit' d.h. flags, die von der Hardware implizit 'gleich mitgesetzt werden beim Modulschalten' setze ich trotzdem immer per code explizit. Damit es die nächste Maskenrevision besser übersteht bzw. wegen dieser Sache mit der Porzellankiste.

Hilft leider überhaupt nix bei Änderung der Schaltreihenfolge.

general-purpose

data

configure

Schon mal Freescale Application Engineering gefragt? Wenn wirklich im Chip oder in einem einigermassen aktuellen und gebraeuchlichen Compiler ein Bock sitzt, wissen die das meist.

Ansonsten mal einen Thevenin 220/330 anstatt des 125 dranhaengen. Wenn der das gelegentlich herumreisst, wird definitiv auf Ausgang geschaltet.

Naja! Ich hab bei denen in Deutschland angerufen, die haben nur eine Person die Ahnung hat und die ist gerade auf Kundenbesuch. Keine Fragen vor Montag bitte...

Ich also auf die Amihomepage. Obwohl ich dort noch nicht angemeldet bin hat der Computer mit als ein "Andre sowieso" erkannt. Staun!

Also hab ich mich erstmal eingetragen. Dann kann man irgendwo anklicken das man hilfloser Wurm ist der Beistand braucht und muss erstmal alle moegliche Fragen beantworten. Jedesmal mehrere Minuten Wartezeit zum Seitenaufbau. Dann durfte ich endlich anklicken das es ein Problem mit dem 68332 ist. Danach ist dann nichts mehr passiert.

Also wieder bei Freekram in Deutschland angerufen und die mir erzaehlt ich koenne auch an snipped-for-privacy@freescale.com schreiben wenn ich nur verzweifelt genug bin. Also erstmal gemacht. Kam aber bisher noch nichts zurueck. Und irgendwie rechne ich auch nicht gross damit.

Ich glaub den Laden kannst du auf deiner Liste gleich neben NXP zum Teufelsaustreiben setzen. Scheint dieselben Probleme zu haben.

Ich bin heute leider nicht dazu gekommen mich weiter damit zu beschaeftigen da es in meiner Firma erstaunlicherweise noch etwas wichtigeres als dieses Problem gab. :-)

Aber Montag...seufz.

Olaf

Die Antworten im allgemeinen schon, aber erst nach 24-48 Stunden.

Es gibt auf der freescale-Webseite newsgroups:

Wollte ich auch gerade schreiben. Ich hatte frueher auch keine Hemmungen, in USA anzurufen:

Ich weiss aber nicht, ob 1-800 von Euch aus noch funktioniert.

Oder mal bei comp.arch.embedded einen Post setzen.

"Joerg" schrieb:

Wie sieht deine (sicherlich über Jahre hinweg akkumulierte sprich' auf grosse Datenmengen bezogene) Erfolgsbilanz diesbezüglich aus?

Wie oft hat es was genützt, wie oft nicht?

Ich bin, was support anrufen angeht nämlich so skeptisch, skeptischer geht's nicht! Vielleicht ja zu völlig unrecht?

Ja, das kam frueher jede Woche vor.

Es nutzte so gut wie immer, ausser wenn z.B. ein Bauteilehersteller echt Sch....e gebaut hat und den Leuten keine Ausreden mehr einfielen.

Der beste war ein Anruf bei den ehemaligen Tseng-Labs in Taiwan. Ziemlich harte technische Fragen, per Email nochmal detailliert, weil das alles nicht auf den Anrufbeantworter passte. Die Firmware-Chefin rief umgehend bei mir in Deutschland an und erklaerte mir in aller Ruhe alles, was ich wissen wollte.

Dann OrCad, als sie noch nicht verkauft waren. Druckertreiber wollte nicht, brauchte mehr als den Generic Driver. Angerufen. "Ist keiner der Ingenieure mehr hier, ich mache nur Gebaeudepflege, aber ich leite das weiter." Mist, Zeitverschiebung verschaetzt, ist ja Westkueste. Wenn das mal klappt ... Es funzte, am naechsten Tag hatte ich eine Nachricht, dass eine Diskette an mich per Luftpost unterwegs sei.

Meine Erfahrungen sind besser, allerdings nicht mit Halbleiterfirmen, die zu einer reinen Vetriebsbude verkuemmert sind. Die haben schlicht keine Ingenieure mit Ahnung.

Ein Problem koennen Rueckrufe werden. Mein Anrufbeantworter in Deutschland war deutsch+englisch besprochen und die eingebauten Vermittlungsansagen waren auch zweisprachig. War lustig, ein Geraet von Tiptel, Englisch mit Duesseldorfer Akzent. Wenn der Beantworter nur Deutsch spricht, damit kommen Amerikaner oft nicht zurande.

Leider kann ich das in umgekehrter Richtung nicht bestaetigen. Z.B. blieben so ziemlich alle Anrufe an Infineon Support (in Deutsch!) unbeantwortet. In Konsequenz flog deren Bauteil raus :-(

Joerg schrieb:

Du hättest Englisch nehmen müssen. In Indien spricht niemand deutsch!

- Henry

:-)

Der Anrufbeantworter klang aber definitiv bayrisch ...

Ich weiß nicht. Einst war ich stolz auf meinen Datenbücherschrank u.a. viel Siemens und Telefunken, Valvo usw.

Heute gibt es diesen Schrank nicht mehr. Die Firmen auch nicht mehr...

- Henry

Ich habe viele Valvo Buecher noch, die sind wirklich gut. Da sind viele Dauerbrenner wie BAV99 oder BSS123 drin, die ich heute noch verwende, weil multi-sourced. Wenn Internet mal kaputt oder der Strom weg ist, bin ich froh, dass es dieses Regal noch gibt.

Henry schrieb:

sch!

=2Ea.

Schrank weg. Folge: Firmen verschwunden ;-)

--=20 mfg hdw