Ich habe ein Board mit einem AT91SAM9G20. Auf diesem Board ist eine 3V Batterie, die, wenn sie reingesteckt ist, den 32kHz Oszillator und den real time timer weiter laufen lässt. Sinn des ganzen ist, das die Software die Uhrzeit auch nach einem Ausfall der Versorgnungsspannung behält. Ich betreibe das Board nicht mit Linux. Ich habe mir einen kleinen Bootloader programmiert, der von dem Bootloader im ROM vom NAND Flash in den SRAM kopiert und ausgeführt wird. Mein Bootloader initialisiert dann den SDRAM und kopiert die eigentliche Firmware vom NAND Flash in den SDRAM, initialisiert die MMU, aktiviert den Daten- und Instructioncache und springt dann zum Startvektor der Firmware. Solange ich die Batterie nicht reinstecke funktioniert das alles so wie es soll. Mit Backupbatterie verhält sich der Controller irgendwie anders. Mein eigener Bootloader wird nicht ausgeführt und im SRAM steht nur Müll, wenn ich mich mit JTAG verbinde und den SRAM auslese. Das Problem ist nur, im Datenblatt steht da nicht viel, außer das in diesem Fall ein wake-up reset durchgeführt wird. Kann mir jemand sagen, was bei dem wake-up reset anders ist? Es sieht so aus als würde der Bootloader im ROM des Controllers, der die Software aus dem NAND Flash liest, nicht ausgeführt werden.
Hallo, der Post ist zwar schon alt, aber ich wollte mal nachfragen, ob sich das Problem mittlerweile gelöst hat???? Aktuell hab ich nämlich das gleich Problem. Kann hier jemand weiter helfen ???
Hallo, ich habe das selbe Problem mit einem AT91SAM9G25, mit Backup-Batterie bootet dieser nicht wenn die Haupt-Stromversorgung zugeschaltet wird, selbst wenn ich die Signale "NRST" oder "WKUP" (beide mit 100k Pullup) kurz auf Masse ziehe passiert nichts; trenne ich die Batterie ab und schalte die Stromversorgung ein dann startet das System einwandfrei; kennt nochjemand das Problem? Gruß Hartmut.
Hallo, warum braucht der Chip beim Kaltstart, also Power On ca. 1 Sekunde zum starten und bei gezogenem Reset nur ein paar Milisekunden ? Ich benutze den 9G10 und ich habe über das Reset Problem einmal eine Abhandlung gelesen, kann mich aber nicht mehr an die AppNode erinnern. Es hing mit dem Spannungsregler und den 2 Reset Eingängen, sowie mit der Core und IO Spannung zusammen. Die Core und IO Spannung muss dann mit einer gewissen Schaltung zuschalten. Ich habe das mit der Batt. gleich gelassen und eine externe Epson RTC eingesetzt. Gruß Sascha
Hallo, noch ein Nachtrag, hängt am externen BUS ein NAND-Flash dran? Dann kann es unter umständen passieren, das der BUS blockiert bleibt. Rückspannungen von der Batt. auf die Core und IO (BUS-Spannung) prüfen. Dann bootet der Chip nicht mehr weil der BUS blockiert ist. Gruß Sascha
Hallo zusammen, ich glaube ich habe eine Lösung gefunden: bei mir kam die 3.3V für VDDIO später als die VDDCORE, das habe ich geändert; beim EVAL-Board ist es auch so das die 3.3V anliegen und daraus die VDDCORE gewonnen wird, bei mir kommt jetzt auch die VDDCORE erst nach den 3.3V und die Boards die vorher verzögert oder garnicht booteten laufen jetzt problemlos; Gruß Hartmut.
Hallo Hartmut, genau das habe ich mit der Powersequence auch gemeint. Am besten ist es den VCC-Core Regler nachgeschaltet dem VCC-IO Regler zu setzen, dann ist das kein Problem. Mit Syncron Rectifier Reglern dürfte das auch kein Problem sein. So habe ich mein Design ganz einfach aufgebaut. Aber vorsicht, wenn der Reset in einer SDRAM Read-sequence kommt gibt der Chip keinen Clock mehr an das SDRAM aus und das SDRAM bleibt auf Ausgabe stehen, somit ist der BUS geklemmt. Dann kein Booten mehr über diverse Speicher möglich. Also den second Bootloader immer im seriellen Flash benutzen. Gruß Sascha
Hallo Sascha, in dem Chip-Dokument "doc11032.pdf" Kapitel 46.13 gibt es eine Grafik mit der Erläuterung das VDDIO nach VDDCORE kommen soll damit POR funktioniert, oder habe ich das falsch verstanden? Gruß Hartmut.
Hallo Hartmut, kann bei atmel das doc11032.pdf leider nicht finden. Aber wenn durch die VCCIO der Reset gesteuert wird, sollte der Core vorher schon startklar sein. Das hat auch mit dem SDRAM nichts zu tun. Sondern das mit dem SDRAM ist der zweite Fehler der passieren kann damit der Prozessor z.B. durch einen WDT Reset oder auch externen Reset nicht mehr bootet. Ansonsten sind die Chips bis jetzt doch relativ zuverlässig (9G10). Gruß Sascha
Hallo Sascha, doc11032.pdf ist altes "SAM9G25 Complete", im aktuelle Dokument vom AT91SAM9G25 ist es Kapitel 46.15 Power Sequence Requirements: da steht das VDDCORE und VDDBU den POR steuern, VDDIO soll nach VDDCORE kommen ?! mfG Hartmut Dahlke.
Hallo Hartmut, danke, ich werde mal Heute Abend mit meinem Speicheroszi die Sapnnungen aufnehmen und als Bild einstellen, mal sehen wie das bei mir aussieht. Jedenfalls startet der Chip bei mir sehr zuverlässig (ich würde mal sagen zu 100%). Gruß Sascha
Angehängte Dateien:
-
VCC_Core_IO.jpg
66 KB -
VCC_Core_Reset.jpg
68 KB -
VCC_Core_VCC_5V.jpg
67 KB -
VCC_IO_VCC_5V.jpg
66 KB
Hallo, so anbei wie versprochen die Oszi Bilder der Messungen. Man sieht also deutlich die VCC-Core Spannung, die mit 1.2V als erstes vorhanden ist. Der Reset lässt allerdings eh lange auf sich warten. Da sollte es kein Problem geben. In Abhängigkeit dazu habe ich noch die Anderen Spannungen gemessen. Die Eingangsspannung ist +24V und geht durch einen Syncronrectifier Regler von LT auf 5V runter. Von den 5V geht ein Syncronrectifier Regler auf VCC Core 1.2V (TI) und für die VCC IO Spannung ein Syncronrectifier von AD. Gruß Sascha
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.