Hallo, ist es möglich den entwickelten Code für einen Mikrocontroller mit Revision A auf den selben Mikrocontroller aber mit der Revision B zu implementieren? Wenn ja, welche Änderungen müssten vorgenommen werden? Ich habe eine Platine fertigen lassen. Jedoch ist mir erst jetzt aufgefallen, dass der Controller auf der Platine Revision B hat und ich habe zuvor den Code für Revision A entwickelt. Der Code lässt sich leider nicht mehr auf dem neuen Controller abspielen.
Fragen wir mal so: Was hat sich denn am Controller von Rev. A zu Rev. B geändert?
Meinst du nicht, dass du wenigstens den Mikrocontroller benennen solltest? Eventuell auch, wo es denn konkret hakt?
Ja, Nein, vielleicht... Das ist einzig davon abhängig, ob die Unterschiede der Revision A zur Revision B das zulasssen. Ob das bei Deinem Mikrocontroller zutrifft, kannsd Du aus den Datenblättern beider Revisionen erkennen. ..oder Du fragst hier nach. ABER BITTE Unter Angabe um Welchen Mikrocontroller es sich handelt!
Micro222 schrieb: > Es handelt sich um einen ATSAME70N21. Dann musst Du Dir nur die Errata besorgen, die die Unterschiede der beiden ausmachen. Geh die Punkt für Punkt durch, und prüfe, ob da Dinge beschrieben werden, die für das Programm relevant sind.
Micro222 schrieb: > Ich habe eine Platine fertigen lassen. Jedoch ist mir erst jetzt > aufgefallen, dass der Controller auf der Platine Revision B hat und ich > habe zuvor den Code für Revision A entwickelt. Der Code lässt sich > leider nicht mehr auf dem neuen Controller abspielen. Das kann mit Sicherheit nicht sein.
1 | 9.2 Corrupted First Sent Data |
2 | Immediately after the I2SC module is reset, the first data sent by the controller on the |
3 | I2SDO line is corrupted. Any data that follows is not affected. |
4 | Workaround |
5 | None. |
6 | Affected Silicon Revisions |
7 | A B |
8 | X |
9 | |
10 | |
11 | 16.1 SMC_WPSR Register Write Protection |
12 | When the write protection feature is enabled and a write attempt into a protected register is performed, |
13 | the Write Protection Violation Source (WPVSRC) bit field in the SMC_WPSR register does not report the |
14 | right violation source. As a consequence, the value in the WPVSRC bit field is incorrect. This issue does |
15 | not affect the write protection feature itself, which is fully functional. |
16 | Workaround |
17 | None. |
18 | Affected Silicon Revisions |
19 | A B |
20 | X |
Nur die obigen 2 Fälle treffen ausschließlich auf Revision B und nicht auf Revision A. Such den Fehler irgendwo anders, mit Revision hängt es bestimmt nicht zusammen.
> Das kann mit Sicherheit nicht sein.
Wenn die I2SC Kommunikation fehlschlägt und das Programm nicht
vernünftig drauf reagiert, kann es schon sein, dass das Programm gerade
deswegen nun hängen bleibt oder quatsch macht.
Ich habe mit dem I2SC nichts am Hut. Ich habe nun ein Beispielprogramm für Revision B genommen und es geladen. Es funktioniert. An der Platine kann es nicht liegen. Das gleiche Beispielprogramm, jedoch für Revision A funktioniert nicht.
Eigentlich nein. Es kommt aber darauf an, was sich geändert hat. Hat sich der Prozessor geändert, so helfen nur die vom Hersteller herausgegebenen Errata oder ein sehr intensiver Blick in das Manual (Befehlssatz Namensgebung Zuordnung u.s.w.). Hat sich das Layout geändert, ist das Ganze ein sinnloses Unterfangen. Geht z.B. Port1 auf einen FET und im anderen Falle auf eine LED, so hilft nur eine Neuprogrammierung.
Stefanus F. schrieb: > Wenn die I2SC Kommunikation fehlschlägt und das Programm nicht > vernünftig drauf reagiert, kann es schon sein, dass das Programm gerade > deswegen nun hängen bleibt oder quatsch macht. Kann sein, aber hängenbleiben und Micro222 schrieb: > habe zuvor den Code für Revision A entwickelt. Der Code lässt sich > leider nicht mehr auf dem neuen Controller abspielen. nicht mehr abspielen lassen ist für mich nicht dasselbe. Falls man keinen Debugger hat, lässt sich mit Serial (vor verdächtigen Abschnitten/Stellen) auch einiges machen...
Micro222 schrieb: > Ich habe mit dem I2SC nichts am Hut. > Ich habe nun ein Beispielprogramm für Revision B genommen und es > geladen. Es funktioniert. An der Platine kann es nicht liegen. Das > gleiche Beispielprogramm, jedoch für Revision A funktioniert nicht. Und wo sind die Unterschiede, was funktioniert nicht ? Micro222 schrieb: > habe zuvor den Code für Revision A entwickelt. Der Code lässt sich > leider nicht mehr auf dem neuen Controller abspielen. Was funktionert jetzt nicht und wo hat der zuvor entwickelte Code für Revision A funktioniert ? P.S. Deine Erklärungen sind nicht nur konfus, die sind katastrophal. Nicht Programm oder Code für Revision B, sondern: Programm lief (oder lief nicht) auf Revision B. Dasselbe gilt für Revision A. Programme hast du bestimmt nicht für verschiedene Revisionen geschrieben (oder copy/paste, egal), sondern du hast dasselbe Programm auf verschiedenen Revisionen laufen lassen, oder ?
:
Bearbeitet durch User
Micro222 schrieb: > Ich habe nun ein Beispielprogramm für Revision B genommen und es > geladen. Es funktioniert. Aha, also das Beispielprogramm. Nun wissen ja alle Bescheid.
Ich kann nicht ganz folgen. Ihr habt jemanden, der Code für den Controller mit Revision A erstellen konnte. Wieso kann sich derjenige jetzt nicht einfach anschauen, warum der Code auf dem Controller mit Revision B nicht läuft?
Ich meine das ist ja die Frage Ich schrieb: > Wieso kann sich derjenige jetzt nicht einfach anschauen, warum der Code > auf dem Controller mit Revision B nicht läuft? Hmm auf die Idee bin ich ja nie gekommen. Habe total vergessen, dass ich mir den Code auch selber mal anschauen könnte bevor ich hier nachfrage. Ohh man... Peter D. schrieb: > Aha, also das Beispielprogramm. Nun wissen ja alle Bescheid. Ich wüsste nicht inwiefern es hier einem weiter hilft, wenn man weiß welches Beispielprogramm das war. Falls jemand mir ganz sachlich antworten kann dann gerne. Ich bin auch ganz offen gegenüber sachlicher Kritik. Aber bitte lasst doch diese unbedeutsamen Kommentare.
Micro222 schrieb: > Ich wüsste nicht inwiefern es hier einem weiter hilft, wenn man weiß > welches Beispielprogramm das war. ...stell dir vor, umgekehrt genau so: ohne dein Programm zu kennen, kann dir auch keiner sagen, warum es unter der Rev. B nicht funktioniert...
Micro222 schrieb: > Falls jemand mir ganz sachlich antworten kann dann gerne. Ich bin auch > ganz offen gegenüber sachlicher Kritik. Aber bitte lasst doch diese > unbedeutsamen Kommentare. Dann solltest Du aber mehr Informationn liefern. "Geht nicht" ist nunmal keine Fehlerbeschreibung.
Ich schrieb: > Ihr habt jemanden, der Code für den Controller mit Revision A erstellen > konnte. Und der funktionierte auf dem selben Board? Micro222 schrieb: > Peter D. schrieb: >> Aha, also das Beispielprogramm. Nun wissen ja alle Bescheid. > > Ich wüsste nicht inwiefern es hier einem weiter hilft, wenn man weiß > welches Beispielprogramm das war. > Falls jemand mir ganz sachlich antworten kann dann gerne. Das war sachlich! Und wir wissen, warum man darauf hinweist. SW-Weisheit: in 10 Zeilen Code ist 1 Fehler. Und genau den will dir PeDa zeigen, wenn er denn den Code sehen könnte. Oder arbeitest du fehlerfrei? Aber dann würde ja alles gehen! Marc V. schrieb: > Programme hast du bestimmt nicht für verschiedene Revisionen > geschrieben (oder copy/paste, egal), sondern du hast dasselbe > Programm auf verschiedenen Revisionen laufen lassen, oder ? Möglicherweise sind Kleinigkeiten unterschiedlich implementiert. TO, vermutlich kannst du auch dem Compiler mitteilen, dass du einen Rev. B-Chip hast.
Micro222 schrieb: > Hmm auf die Idee bin ich ja nie gekommen. Habe total vergessen, dass ich > mir den Code auch selber mal anschauen könnte bevor ich hier nachfrage. > Ohh man... Meinst Du das jetzt wirklich ernst? Micro222 schrieb: > Ich wüsste nicht inwiefern es hier einem weiter hilft... Wenn man ganz offensichtlich nicht mehr weiter weis und auf Hilfe eines Forums angewiesen ist, sollte man nicht die eigene Unwissenheit als Maßstab heranziehen. Denn eigentlich ist es normal dass Du das nicht weist - sonst wärst Du nicht hier. War mir ein Bedürfnis, das loszuwerden. Zum Thema kann ich derzeit nichts beitragen, ohne die Fragen der Vorposter zu wiederholen.
Micro222 schrieb: > Hmm auf die Idee bin ich ja nie gekommen. Habe total vergessen, dass ich > mir den Code auch selber mal anschauen könnte bevor ich hier nachfrage. > Ohh man... und > Ich wüsste nicht inwiefern es hier einem weiter hilft, wenn man weiß > welches Beispielprogramm das war. und > Ich bin auch ganz offen gegenüber sachlicher Kritik. Aber bitte lasst > doch diese unbedeutsamen Kommentare. Wie dumm muss man eigentlich sein in diesem Forum mit solchen Sprüchen einen auf dicke Hose zu machen und andererseits offensichtlich nicht zu wissen wie man den Unterschied zwischen 2 Hardware-Revisionen eines Mikroprozessors feststellt? Mit einem solchen Auftreten solltest du dich über die erfolgten Reaktionen nicht wundern. rhf P.S.: Im Übrigen wurden dir schon reichlich Tipps gegeben wie man das Problem finden oder zumindest eingrenzen kann.
Micro222 schrieb: > Ich wüsste nicht inwiefern es hier einem weiter hilft, wenn man weiß > welches Beispielprogramm das war. Na, vielleicht weil das Beispielprogramm auf bestimmte Features abzielt. Entweder, du rückst die Infos raus oder du musst selber sehen, wie du damit zurecht kommst, falls du nicht jemanden beauftragen möchtest, der sich damit auskennt und ein NDA mit dir abschließt.
Entweder man beachtet alle Änderungen, schon der CHIP ID ist ja unterschiedlich, oder man bestückt die A-Version welche ja weiterhin lieferbar ist. Es ja nicht gerade ein kleiner Controller und wenn die vorhandene Software viele externe Quellen enthält die ggf. irgendwelche Hardware Bugs der A Revision trickreich umschifft, würde ich mir den Aufwand wirklich nicht antun. Und die gesamte Errata ist ja wie für Chips dieser Grössenordnung allgemein üblich nicht gerade klein.
Micro222 schrieb: > Hmm auf die Idee bin ich ja nie gekommen. Habe total vergessen, dass ich > mir den Code auch selber mal anschauen könnte bevor ich hier nachfrage. > Ohh man... Junge, wenn jemand (du) von "Code abspielen" redet, dann muss man davon ausgehen, dass er nicht weiß was er tut. Wenn noch dazu kommt, dass du wiederholt wichtige Informationen verschweigst ("das Beispielprogramm"?) und glaubst es macht irgendwie Sinn uns dumm zu halten und zu verarschen, dann gibt es bald niemanden mehr, der versucht dir zu helfen. Arbeite mit uns, nicht gegen uns.
Micro222 schrieb: > Falls jemand mir ganz sachlich antworten kann dann gerne. Ich bin auch > ganz offen gegenüber sachlicher Kritik. Aber bitte lasst doch diese > unbedeutsamen Kommentare. Von Dir kommt aber auch garnüscht sachliches. Kein Code, kein Schaltplan, nix. Selbst den MCU Typ mussten Wir Dir erst aus der Nase ziehen. Erwartest Du etwa wirklich dass man Dir mit 'ner Glaskugel helfen kann? Auf einem komplexen Cortex-M7 kann man sehr leicht undefiniertes Verhalten erzeugen, dass einem in einer späteren Version auf die Füße fällt. Erfahrene Programmierer könnten das mit Blick in den Source durchaus erkennen. Wieso man bei einem so teuren µC keinen Debugger ansetzen kann, verstehe ich auch nicht. Der ist hier notwendig. Falls der nicht tut, ist DAS ein guter Hinweis auf die Fehlerquelle (Taktbaum oder Pinout).
Jack schrieb: > Junge, wenn jemand (du) von "Code abspielen" redet, dann muss man davon > ausgehen, dass er nicht weiß was er tut. Ach, daran hätte zumindest ich mich nicht gestört. Mir fallen für "abgespielten Code" genau so viel Analogien ein, wie für das gebräuchlichere "laufender Code" oder "laufendes Programm". Tatsächlich ist es doch so, dass ein uC den im Speicher liegenden Code viel mehr "abspielt" als dass er ihn "laufen" lässt, oder? Man sollte also nicht gleich anfangen Andere gering zu schätzen weil Sie eine andere Umgangssprache als man selbst verwenden. @TO Hast Du die Hinweise verstanden, kommt noch was oder ist das Problem gelöst?
hier meine 5 cent zu dem thema: wenn die lt. errata sheet in Rev.B neu eingebauten "bugs" keine relevanz haben, dann sollte die software auch darauf laufen. eine ursache könnte sein, dass die software eine bug in Rev.B aufdeckt, der noch nicht bekannt ist, scheint mir aber sehr unwahrscheinlich. wie sieht es mit einem debugger (j-link o.ä.) aus? ist der vorhanden und kann benutzt werden? gruss gerhard
Wir hatten auch mal Probleme mit den verschiedenen Revisionen des LPC2292. Blöderweise haben die alle die selbe Signatur. Der Kollege hat sich dann damit beholfen, indem er testet, ob einige Register beschreibbar sind, die nur in den höheren Revisionen vorhanden sind.
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.