Hallo zusammen,
ich habe Probleme bei der Programmierung eines ATSAME54N20A. Der
Controller bleibt bereits vor der eigentlichen main-Funktion im
reset_handler() hängen und springt dann in den dummy_handler. Die
Funktionen sind in der startup_same54.c hinterlegt, die von Atmel Studio
automatisch bei einem neuen Projekt hinterlegt sind.
Da ich neu in der Programmierung eines SAM-Controllers bin, habe ich
erstmal versucht nur eine LED zum Leuchten zu bringen. Dies hat auch
beim ersten Mal funktioniert. Danach wollte ich das Programm erweitern,
und bei der Ausführung des neuen Programm funktionierte nichts mehr.
Also habe ich alles wieder auf das letzte Programm zurückgesetzt, aber
die LED leuchtete auch nicht mehr. Selbst ein leeres Projekt ohne
eigenen Code läuft nicht fehlerfrei durch.
Beim Debugging ist mir dann aufgefallen, dass der Controller bereits in
der von Atmel vorgegebenen Datei “startup_same54.c“ stehen bleibt, und
zwar im reset_handler() bei Initialize the relocate segment (in der
Zeile „*pDest++ = *pSrc++“). Von dort aus springt der Controller immer
in den dummy_handler() in einer Endlos-Schleife und erreicht niemals die
main-Funktion.
1
voidReset_Handler(void)
2
{
3
uint32_t*pSrc,*pDest;
4
5
/* Initialize the relocate segment */
6
pSrc=&_etext;
7
pDest=&_srelocate;
8
9
if(pSrc!=pDest){
10
for(;pDest<&_erelocate;){
11
*pDest++=*pSrc++;
12
}
13
}
Die Analyse der Register zeigt mir, dass ein Hard Fault vorliegt, und
zwar genauer UNDEFINSTR = 1. Allerdings hilft mir das recht wenig
weiter, weil das in der Startup liegt und ich daran nichts geändert
habe.
Ich habe schon neue Projekte aufgesetzt, den Mikrocontroller ersetzt,
verschiedene PCs ausprobiert und das halbe Internet durchforstet. Auch
den Support von Atmel bzw. Microchip habe ich kontaktiert, allerdings
haben die noch keine Lösung für mich.
Das einzige, was ich im Internet zu dem Thema gefunden habe, ist unter
anderem dieser Artikel:
https://www.avrfreaks.net/forum/code-stuck-resethandler-after-atmel-studio-upgrade-701417
Allerdings geht es in den Artikeln immer um einen ATSAME7x. Die dort
vorgeschlagenen Lösungen funktionieren bei meinem Controller nicht. Die
Veränderung in der Startup beschreibt Register, die bei einem ATSAME5x
nicht existieren. Und zudem steht dort, dass dieser Fehler in der
aktuellen Version von Atmel Studio (7.0.1931) bereits behoben sei.
Ich verwende ein selbst gestaltetes Board, deswegen würde ich an sich
auch Hardware-Fehler in betracht ziehen. Allerdings hat die LED ja bei
beiden Mikrocontrollern am Anfang und sogar noch einmal zwischenzeitig
geleuchtet.
Hat jemand eine Idee was ich noch machen kann?
Zeig doch mal den disassemblisierten Code des Reset_Handler. Steppe mal
jede Instruktion einzeln durch, merke dir bei welcher der Fehler
auftritt, und starte von vorne bis die Ausführung direkt vor dieser
Instruktion steht; mache einen Screenshot mit aktuellen
Register-Inhalten (R0-R15, CPSR) und zeige diesen.
Muss vielleicht der SRAM irgendwie explizit eingeschaltet werden, bevor
mit "*pDest++ = ..." darauf geschrieben wird? Bei manchen Controllern
ist das nötig.
Danke für die schnelle Antwort. Allerdings bin ich jetzt noch mehr
verwirrt.
Habe das mal genauso gemacht, bin die Instruktionen einzeln
durchgegangen, Screenshot von der letzten Instruktion bevor es in den
dummy_handler ging hab ich angehängt.
Allerdings war es dieses mal an einer anderen Stelle als oben im ersten
Post angegeben !?
Und noch verrückter: das erste mal danach ist er wieder an der besagten
Stelle abgestürzt, und danach das mal geht er plötzlich wieder ganz
normal in die main rein ?!?
Hmm, dann ist das keins der üblichen Software-Probleme.
Funktioniert das Programm wenn du ohne Debugger, ganz normal ausführst?
Wie sieht es mit anderen Debuggern, z.B. J-Link aus? Funktioniert es auf
einem Eval-Board? In dem verlinkten Thread wird ja erwähnt, dass der RAM
konfiguriert werden muss. Schlag doch mal nach, ob das bei deinem
Prozessor auch nötig ist.
Was passiert wenn du den Reset_Handler in Assembler mit einer
Dummy-Schleife umsetzt:
1
.thumb
2
.type Reset_Handler, %function
3
Reset_Handler:
4
nop
5
b Reset_Handler
Der tut dann natürlich gar nichts, aber stürzt es auch ab?
Danke für die Vorschläge.
Beim ersten Mal ohne Debugger hat das Programm funktioniert (was ich
auch schon mehrmals ausprobiert habe und regelmäßig nicht klappte). Beim
zweiten Mal bricht Atmel Studio ab mit der Fehlermeldung "Error: Timed
out waiting for the chip erase to complete"
Eval-Board sowie anderen Debugger als den Atmel-ICE habe ich leider
nicht hier.
Habe jetzt eine Antwort von Microchip Support erhalten. Diese fragen
aber nur ob ich einen Interrupt freigegeben habe und vergessen habe
diesen zu implementieren. Imemrhin haben sie mir auch direkt ein
Beispiel-Programm mitgeliefert, allerdings tritt auch bei diesem ein
ähnliches Verhalten auf wie vorher. Manchmal läuft es durch, und
manchmal geht es genauso in den dummy_handler.
Ich versuche mal an einen anderen Programmer zu kommen und überprüfe in
der Zeit noch einmal meinen Hardware-Aufbau.
Manuel K. schrieb:> Beim> zweiten Mal bricht Atmel Studio ab mit der Fehlermeldung "Error: Timed> out waiting for the chip erase to complete"
Dann stimmt da hardwareseitig etwas nicht.
Manuel K. schrieb:> Habe jetzt eine Antwort von Microchip Support erhalten. Diese fragen> aber nur ob ich einen Interrupt freigegeben habe und vergessen habe> diesen zu implementieren.
Könnte sein, wenn nicht UNDEFINEDINSTR gesetzt wäre. Im IPSR kannst du
nachsehen welcher Interrupt tatsächlich ausgelöst wurde; ich vermute mal
dass alle nicht-implementierten Interrupts einfach Dummy_Handler
aufrufen (wie weak-Attribut im ISR-Vektor eingetragen).
Manuel K. schrieb:> Ich versuche mal an einen anderen Programmer zu kommen und überprüfe in> der Zeit noch einmal meinen Hardware-Aufbau.
Ja, mach das mal. Achte auch mal auf Stützkondensatoren und
Spannungseinbrüche (Oszilloskop). Wenn man nicht so viel Erfahrung mit
einem Controller hat sollte man vielleicht nicht direkt mit einem
eigenen PCB anfangen :-)
Mit dem Microchip Support hab ich aber leider auch keine guten
Erfahrungen gemacht. Kaufen ist erlaubt, aber wehe es soll auch
funktionieren :-)
Ein anderer Debugger wird nicht viel nützen, weil der gar nicht
unterstützt wird, zumindest kein J-Link.
Aber ein SAME54-Xplained könnte helfen.
Hast Du den Test mit der LED mal frisch als Projekt aufgesetzt?
Und das AS7 Studio für den E54 ist auf dem neuesten Stand?
Die Dinger sind ja noch ganz frisch.
@Niklas G.
mit den Interrupts vermutest du richtig, wird pauschal der dummy_handler
aufgerufen, hat deswegen auch am Anfang gedauert zu finden wo das
ungefähr herkommt.
Eigenes PCB war leider mehr oder weniger Pflicht. Schreibe gerade meine
Bachelorarbeit Elektrotechnik, und ohne das eigene Design wäre das zu
sehr Informatik und zu wenig E-Technik gewesen :/
Beim Design habe ich mich eigentlich an die Angaben im Datenblatt und
zusätzlich an der Dokumentation zum Eval-Board gehalten. Hat wohl nicht
gereicht :D
@Rudolph
Ok dann kann ich mir den anderen Debugger auf jeden Fall sparen.
Das Projekt mit den LEDs funktioniert manchmal, und dann auch wieder
nicht. Egal ob im existieren Projekt oder als ganz neues Projekt.
AS7 ist die aktuellste Version. Erst gestern Abend noch auf einen
anderen PC frisch installiert und auch dort probiert, produziert
dieselben Fehler.
Aber vielleicht hätte ich mir wirklich einen älteren Controller
aussuchen sollen, zu dem es schon mehr im Internet zu finden gibt... :D
Rudolph schrieb:> Ein anderer Debugger wird nicht viel nützen, weil der gar nicht> unterstützt wird, zumindest kein J-Link.
Also laut Segger schon:
https://www.segger.com/downloads/supported-devices.phphttps://www.segger.com/products/debug-probes/j-link/technology/ides/atmel-studio/Manuel K. schrieb:> Eigenes PCB war leider mehr oder weniger Pflicht.
Klar, aber dann ist es taktisch klug einen Controller zu nehmen, von dem
es ein Eval Board gibt, und selbiges parat zu haben :-)
Prüfe auch mal ob das Programm auch wirklich korrekt im Flash ist.
Starte den Debugger mal so, dass er die .elf Datei des Programms nicht
kennt; dann muss er den tatsächlichen disassemblisierten Code aus dem
Flash anzeigen, statt einfach nur die Daten aus der .elf-Datei. Wenn der
Code aus irgendwelchen Gründen nicht richtig auf dem Controller ist und
dieser bei der Ausführung im Debugger sich scheinbar völlig falsch
verhält, kann es eine böse Falle sein wenn der Debugger was anderes
anzeigt als tatsächlich auf dem Gerät ist...
Niklas G. schrieb:>> Ein anderer Debugger wird nicht viel nützen, weil der gar nicht>> unterstützt wird, zumindest kein J-Link.>> Also laut Segger schon:
Okay, danke für den Hinweis.
Manuel K. schrieb:> Das Projekt mit den LEDs funktioniert manchmal, und dann auch wieder> nicht.
Stell doch mal ein komplettes Test-Projekt ein, einfach das /debug
Verzeichnis löschen und zippen.
So zum LED wackeln.
Was mir gerade noch einfällt ist die Takt-Erzeugung.
Ich habe gerade einen SAMC21 am Wickel und hatte mit dem das Problem,
dass der CAN nicht wollte.
War nur alles richtig was ich mit dem CAN veranstaltet hatte, aber ich
habe mich mit der PLL vertan und einen zu hohen Multiplikator
eingestellt.
Und da ich für CAN und Core 48MHz brauche kommen die aus dem gleich
GCLK.
Hat etwas gedauert das zu finden, weil ich an der falschen Stelle
gesucht habe...
Und die Wait-States muss man auch passend einstellen wenn das aus dem
Flash laufen soll.
>AS7 ist die aktuellste Version.
Nicht AS7, das E54 Pack dazu: http://packs.download.atmel.com/
Die x5x sind doch noch sehr neu, das kann sehr gut sein das da noch dran
rumgepatcht wird.
Dafür wird dann auch nicht extra ein neues AS7 Release veröffentlicht.
Das Pack für den SAMC21 habe ich zum Beispiel Anfang Oktober
aktualisiert und AS7.0.1931 ist ja von Juni.
Niklas G. schrieb:> Klar, aber dann ist es taktisch klug einen Controller zu nehmen, von dem> es ein Eval Board gibt, und selbiges parat zu haben :-)
Aus Fehlern wird man klug. Vielleicht denke ich bei der nächsten
Bachelorarbeit daran... :D
Niklas G. schrieb:> Starte den Debugger mal so, dass er die .elf Datei des Programms nicht> kennt;
Also ich habe aus dem Projektverzeichnis die .elf Datei gelöscht und
danach das Programm neu debuggt, meintest du das so? Wenn ja, dann ist
nichts passiert, immer noch Fehler.
Rudolph schrieb:> Stell doch mal ein komplettes Test-Projekt ein, einfach das /debug> Verzeichnis löschen und zippen.
Ist passiert. Allerdsings noch eine Stufe einfacher als LED wackeln, da
geht lediglich eine LED an. Selbst über sowas freue ich mich schon, da
das nur ab und zu funktioniert :D
Rudolph schrieb:> Was mir gerade noch einfällt ist die Takt-Erzeugung.
In wieweit brauche ich denn überhaupt schon einen Takt? Mein Ziel ist
doch erstmal ein nacktes Programm ohne Probleme zum Laufen zu bringen.
Und für eine simple LED brauche ich doch auch keinen (explizit
eingestellten) Takt oder nicht? Also das Programm oben läuft ja auch das
ein oder andere Mal, und dann pllötzlich wieder nicht.
Rudolph schrieb:> Und die Wait-States muss man auch passend einstellen wenn das aus dem> Flash laufen soll.
Das sagt mir jetzt ehrlich gesagt gar nichts :/ Da merke ich dann doch
wie sehr ich ein Anfänger bin :( Aber selbe Frage wie gerade, in wieweit
benötige ich das schon für meine LED?
Vielleicht bin ich da etwas naiv, aber ich bin davon ausgegangen dass
ein neu erstelltes Projekt unter Atmel Studio bei einem Atmel Controller
mit den dazugehörigen Packages an sich lauffähig ist ohne noch weitere
Einstellungen treffen zu müssen. Also zumindest solange man keinen
eigenen Code hinzufügt, nur das nackte Programm, auch wenn es dann
natürlich nichts kann.
Rudolph schrieb:> Nicht AS7, das E54 Pack dazu
Achso Entschuldigung, da habe ich dich falsch verstanden. Hatte das aber
schonmal überprüft, jetzt nochmal einmal nachgeschaut, ist definitiv die
aktuelle Version 1.0.87 wie auf der Microchip Website.
Manuel K. schrieb:> Niklas G. schrieb:>> Klar, aber dann ist es taktisch klug einen Controller zu nehmen, von dem>> es ein Eval Board gibt, und selbiges parat zu haben :-)>> Aus Fehlern wird man klug. Vielleicht denke ich bei der nächsten> Bachelorarbeit daran... :D
Aber da gibt es doch ein Board:
https://www.microchip.com/developmenttools/ProductDetails/ATSAME54-XPRO
Könntest du nochmal das mit dem Debuger aus deinem ersten Beitrag
starten und sagen auf welche Adresse
1
uint32_t*pSrc,*pDest;
zeigen, in dem Moment wo er aussteigt.
Das würde evtl. einer Zugriffsverletzung entsprechen, was dazu jedoch
nicht passt, ist...der Reset_Handler ist bei den CortexM4 mit FPU so gut
wie identisch, und du hast ja auch nur lediglich ein leeres Projekt.
Dies würde bedeuten, dass in den linker-Files falsche Werte bzgl. der
Adressen hinterlegt sind. Daher kommen die "Grenzwerte" und Größen.
Kann mir grad auch nichts zusammendichten, was dieses sporadische
funktionieren erklären könnte.
Hast du mal versucht ein leeres Prohjekt mit der ASF zu erstellen (Diese
hat damit gar nix zu tun, aber vllt. ist intern eine falsche Konfig
hinterlegt, bzgl. der RAM Adressen. Das ist in den Dateien hinterlegt
dir mit *.ld enden.
Müsste man mal mit dem Datenblatt vergleichen.
Ist richtig, das braucht soweit keine Takt-Einstellung.
Der E54 läuft per Default mit 12MHz Core-Clock.
Ich habe jetzt auch nicht damit gerechnet, dass das Projekt so einfach
ist, das ist ja wirklich nur ein leeres Projekt plus zwei Zeilen Code.
Adam P. schrieb:> vllt. ist intern eine falsche Konfig> hinterlegt, bzgl. der RAM Adressen. Das ist in den Dateien hinterlegt> dir mit *.ld enden.> Müsste man mal mit dem Datenblatt vergleichen.
Also ich hab es dir mal mit dem Datenblatt verglichen,
das stimmt alles soweit...
Moin,
ich kenne die SAMs nicht, aber koennte es vielleicht sein, dass das
Ding einen WDT hat? Der dann irgendwann dazwischen haut?
Es wird ja keine Clock und keine Waitstates eingestellt, soweit ich
das interpretiere. Da dürfte der Core mit angezogener Handbremse durch
die Init-Funktionen gehen, oder?
Ist nur so ein Bauchgefuehl, ich kenne die SAMs nicht.
Adam P. schrieb:> Aber da gibt es doch ein Board:
Ja ich weiß, aber hab es halt nicht parat. Muss mal schauen und mit
meiner Firma klären ob ich das auch noch bestellen kann. Ich weiß dann
aber jetzt für zukünftige Projekte bescheid dass man sich um sowas auch
schon früher kümmern sollte, die Zeit in der BA Phase ist ja doch
ziemlich beschränkt.
Adam P. schrieb:> Hast du mal versucht ein leeres Prohjekt mit der ASF zu erstellen
Hab ich auch schon probiert. Also mit ASF, über Atmel Start, als
"normales" C/C++ Projekt, als komplett leeres Projekt und Dateien
händisch hinzufügen... Hat leider alles keinen Unterschied gemacht.
Adam P. schrieb:> Könntest du nochmal das mit dem Debuger aus deinem ersten Beitrag> starten und sagen auf welche Adresseuint32_t *pSrc, *pDest;> zeigen, in dem Moment wo er aussteigt.
Ich muss die Optimierung ausschalten damit ich die Werte überhaupt sehen
kann. Und dann stehen beide Pointer meist auf den Wert 0x0 (die
for-Schleife wird einige Male durchlaufen bevor irgendwann der Fehler
zuschlägt). Beim Starten zeigen beide Pointer als erstes auf 0x20010478.
Dann wird *pSrc = 0x02DC6C00 und *pDest = 0x0 zugewiesen. Wenn er
durchläuft zeigt *pSrc wiedr auf 0x20010478 wie beim starten und *pDest
auf 0x0. Welcher Wert beim Rausschmiss kommt prüfe ich nochmal
Rudolph schrieb:> Ich habe jetzt auch nicht damit gerechnet, dass das Projekt so einfach> ist, das ist ja wirklich nur ein leeres Projekt plus zwei Zeilen Code.
Genau das ist das was mich so fertig macht. Wenn ich wenigstens etwas
Code geschrieben hätte dann könnte ich den Fehler ja irgendwie noch
begründen, aber so ist es echt einfach nur Verwirrung pur
Darth Moan schrieb:> koennte es vielleicht sein, dass das> Ding einen WDT hat
Ja hat er. Hatte aber gedacht dass der nicht ins gewicht fällt bei
meiner Anwenung wo nichts drin steht. Hab aber auch schon mal probiert
den über die Fuses zu deaktivieren, hat nichts gebracht.
Bin aber gerne offen an der Stelle noch was zu probieren, weiß nur nicht
genau wie. In der Main den zu deaktivieren bringt ja nichts wenn das
Programm nicht bis zur Main läuft, und für mehr reichen meine Kentnisse
leider nicht.
Aber sollte so ein WDT nicht auch erst anschlagen wenn nach der
Initialisierung ab dem eigentlichen Programmstart etwas schief läuft?
Moin,
Manuel K. schrieb:> Aber sollte so ein WDT nicht auch erst anschlagen wenn nach der> Initialisierung ab dem eigentlichen Programmstart etwas schief läuft?
Das kommt halt drauf an, was der Hersteller da so eingebaut hat.
Ich bin ja kein SAM Kenner, aber folgendes lass sich auf die Schnelle
so:
Configurable Reset Values
After a Power-on Reset, some registers will be loaded with initial
values from the NVM User Row.
This includes the following bits and bit groups:
• Enable bit in the Control A register, CTRLA.ENABLE
• Always-On bit in the Control A register, CTRLA.ALWAYSON
• Watchdog Timer Windows Mode Enable bit in the Control A register,
CTRLA.WEN
• Watchdog Timer Windows Mode Time-Out Period bits in the
Configuration register,
CONFIG.WINDOW
• Time-Out Period bits in the Configuration register, CONFIG.PER
• Early Warning Interrupt Time Offset bits in the Early Warning
Interrupt Control register,
EWCTRL.EWOFFSET
Ich kenne das halt von anderen Plattformen, dass die nach POR immer
erstmal laufen, bis man sie abschlatet. Aber was da mit den Fuses
gemacht werden kann und was nicht, weiss ich nicht.
Da muesste eher ein SAM Experte was zu sagen.
Darth Moan schrieb:> Ich kenne das halt von anderen Plattformen, dass die nach POR immer> erstmal laufen, bis man sie abschlatet. Aber was da mit den Fuses> gemacht werden kann und was nicht, weiss ich nicht.> Da muesste eher ein SAM Experte was zu sagen.
Danke erstmal für die Idee, werde mal abwarten ob sich noch jemand dazu
meldet und dann morgen weiter in der Richtung schauen. Hab jetzt erst
noch ne Nachtschicht vor mir um zu schauen ob der Hardware-Aufbau soweit
in Ordnung ist... :D
Darth Moan schrieb:> Da muesste eher ein SAM Experte was zu sagen.
Bei einem SAM3X ist das der Fall: Der WDT muss im Startup-Code
abgeschaltet werden, sonst schießt der den Controller nach ein paar ms
ab (so schnell ist der Debugger nicht). Zu deinem SAME54 kann ich nichts
sagen.
Grob überflogen würde ich sagen, dass der WDT beim SAME54 erstmal
deaktiviert ist.
Der würde aber (z.B. beim SAM4E) auch erst aus der main() in der
board_init() deaktivert werden.
Was du noch in Erfahrungen bringen könntest, da du sagtest 1x
funktionierts und dann wieder nicht.
Gibt es evtl. diesen Unterschied, wenn du im Debug Mode mit dem Debugger
drauf bist oder ob du die Firwmare im Release aufspielst?
Manuel K. schrieb:> Dann wird *pSrc = 0x02DC6C00 und *pDest = 0x0 zugewiesen
Irgendwie passt das nicht,
Dein Flash ist definiert als:
1
rom(rx):ORIGIN=0x00000000,LENGTH=0x00100000
danach folgt reservierter Bereich bis:
0x03000000
Mit *pSrc = 0x02DC6C00 würde er ja auf Speicher zugreifen, den es nicht
gibt...
Sollte ich da etwas übersehen, bitte ich um Entschuldigung, auf den
ersten Blick sieht es jedoch komisch aus.
(Außer du hast dich beim Abschreiben vertan)
Darth Moan schrieb:> ch kenne das halt von anderen Plattformen, dass die nach POR immer> erstmal laufen, bis man sie abschlatet. Aber was da mit den Fuses> gemacht werden kann und was nicht, weiss ich nicht.> Da muesste eher ein SAM Experte was zu sagen.
Mit den Fuses werde ich mich jetzt sofort weiter auseinander setzen.
Wenn man diese im Device Programming Menu ausliest stehen der WDT
standardmäßig auf Enable. Dort deaktivieren und Programmieren scheint
aber keinen Unterschied zu machen, auch wenn sie nach einem erneuten
Auslesen jetzt als deaktiviert eingetragen sind. Aber vielleicht muss
man da auch noch mehr setzen. Melde mich nochmal dazu wenn ich mehr in
Erfahrung gebracht habe.
Adam P. schrieb:> Gibt es evtl. diesen Unterschied, wenn du im Debug Mode mit dem Debugger> drauf bist oder ob du die Firwmare im Release aufspielst?
Auch schon probiert. Funktionierte sogar auf Anhieb beim ersten Mal
nachdem ich es auf Release umgestellt habe. War aber anscheinend nur
Glück, danach ging es wieder nicht.
Niklas G. schrieb:> Achte auch mal auf Stützkondensatoren und> Spannungseinbrüche (Oszilloskop)
Bin jetzt nochmal das komplette Layout durchgegangen, mir ist nichts
weiter aufgefallen. Stüzukondensatoren sind auch außreichend vorhanden,
da hatte auch schon eine zweite Person aus der Firma mit mer Erfahrung
drauf geachtet.
Lediglich meine Spannungsversorgung für 3.3V liegt nur bei 3.15V, der
Spannungsregler liefert zu wenig. Diese sind aber recht konstant und
brechen nicht zusammen, auch nicht beim Programmieren. Laut Datenblatt
kommt der Chip auch mit Spannungen bis zu 1.7V runter noch klar, sollte
also eigentlich kein Problem darstellen. Ich schaue trotzdem mal dass
ich das noch was anderes finde mit den gefordeten 3.3V, kann ja nicht
schaden.
Nochmal zu deinem Wert: 0x02DC6C00
In deiner *.lss Datei ist der Wert in der
void SystemInit(void)
hinterlegt... dort wo du die Clock konfigurierst, aber ich dachte bis
dahin kommst du erst gar nicht?
Schau mal selbst in der *.lss (im Debug Ordner) Zeile: 208-217
Adam P. schrieb:> Irgendwie passt das nicht,> Dein Flash ist definiert als:rom (rx) : ORIGIN = 0x00000000,> LENGTH = 0x00100000> danach folgt reservierter Bereich bis:> 0x03000000>> Mit *pSrc = 0x02DC6C00 würde er ja auf Speicher zugreifen, den es nicht> gibt...>> Sollte ich da etwas übersehen, bitte ich um Entschuldigung, auf den> ersten Blick sieht es jedoch komisch aus.>> (Außer du hast dich beim Abschreiben vertan)
Habs nochmal überprüft, und Scrennshot gemacht. Der steht in dem Moment
wieder in der for-Schleife und hat *pSrc = 0x02DC6C00. Hab mich also
nicht verschrieben.
AHHHH OK :-)
ergibt Sinn. 0x02DC6C00 = 48.000.000
Da wird deine Konfig übernommen, da pDest auf deine SystemCoreClock
zeigt, stimmt mit deiner *.map überein.
Aber da bleibt er nicht hängen, oder?
Aber das kann nicht das Problem sein, ist bei dir ja wirlich nur ein
Standard-GCC-Projekt,
da ist ja von dir gar nichts verändert...
Versuch mal das hier:
Hallo,
Ich hatte neulich ein sehr ähnliches Problem beim samd21. Vielleicht ist
es hier das gleiche Problem... Löschen mal sämtliche breakpoints im avr
Studio.
Bei mir lief es danach wieder. Und es hängte sich an exakt der selben
Stelle auf.
Gruß
Flo
Das quasi leere Programm muss so funktionieren.
Entweder ist die Hardware defekt, oder das vom AS7 generierte Projekt
ist fehlerhaft.
Das SystemInit() macht doch erst mal gar nichts weiter als eine Variable
zu setzen, das hat doch weiter keine Auswirkung und man kann das auch
löschen.
Und was vor der Main alles passiert ist ja erstmal nichts an dem man
rumdoktern müssen sollte damit der Controller los läuft, wenn auch nur
mit 12MHz Core-Takt.
Und auch ohne irgendwas mit den Fuses machen zu müssen.
>Lediglich meine Spannungsversorgung für 3.3V liegt nur bei 3.15V, der>Spannungsregler liefert zu wenig.
Wenn das kein einstellbarer ist, würde mir das Sorgen machen.
Und wenn das ein einstellbarer ist, würde ich mal den Feedback-Teiler
überprüfen und nachrechnen.
Adam P. schrieb:> Leeres Projekt aus dem neusten Atmel Start.
Start ist so eine Sache.
Ich habe vor zwei Wochen ein Start-Projekt für den SAMC21 generiert das
sich bei der Takt-Einstellung aufgehängt hat - ohne vorher einen Fehler
im Start anzuzeigen.
Nicht, dass man im Start die Takt-Erzeugung überhaupt so konfigurieren
könnte wie der Controller das unterstützt, zum Beispiel kann man den
Vor-Teiler der PLL nicht einstellen.
Rudolph schrieb:> Start ist so eine Sache.
Ja ich nutze das selbst gar nicht, mal davon abgesehen, dass es für den
SAM4E gar keine Start-Projekte gibt.
Aber um sich Ideen zu holen und etwas nachzusehen... Ist bestimmt genau
so wie mit den ASF Beispielen (bzw. auch dem ASF ansich) aus dem
Standard-Menü, wenns funktioniert ist ok, wenn nicht, tja...Lesen &
Suchen.
Mich wundert es nämlich auch, dass dieses leere Projekt bereits im
Reset_Handler hängen bliebt.
Adam P. schrieb:> Leeres Projekt aus dem neusten Atmel Start.
Das frisst Atmel Studio bei mir gar nicht, haut nur einige Fehler raus,
siehe Bild.
Florian H. schrieb:> Ich hatte neulich ein sehr ähnliches Problem beim samd21. Vielleicht ist> es hier das gleiche Problem... Löschen mal sämtliche breakpoints im avr> Studio.> Bei mir lief es danach wieder.
Bei mir leider nicht. Alle Breakpoints gelöscht. Zusätzlich noch Projekt
und Atmel Studio geschlossen und neu gestartet. Drei mal lief es, dann
war wieder vorbei.
Ich verstehe vor allem diese Unbeständigkeit nicht. Nach meiner Logik
müsste es Laufen oder halt nicht, aber das ist sehr merkwürdig.
Rudolph schrieb:> Und auch ohne irgendwas mit den Fuses machen zu müssen.
Hab ich auch gedacht. Aber ich habe mir das gerade nochmal genauer
angeschaut und die gesetzten Fuses sind komplett anders als im
Datenblatt als Default angegeben. Allerdings sind zwei Sachen sehr
merkwürdig:
1. Beim Auslesen bekomme ich immer ein failed bei den Registern
SW0_WORD_0 und SWO_WORD_1 sowie bei den TEMP_LOG_WORD-Registern. Die
TEMP-Register sind mir dabei noch relativ egal, da sie auch im
Datenblatt nicht weiter spezifiziert sind. Aber die anderen Register
setzen BIAS Werte für AC und ADC
2. Wenn ich die Fuses auf die Default Werte stellen und anschließend
Programmieren will, bricht Atmel Studio mit einer Fehlermeldung ab:
"WriteRegister() failed to write at 800080", siehe Bild.
Manuel K. schrieb:> Das frisst Atmel Studio bei mir gar nicht, haut nur einige Fehler raus,> siehe Bild.
Das ist verständlich, da in deinem oben genannten Projekt die Einträge
anders heißen, vergleich das mal...dabei habe ich das Projekt extra für
den
ATSAME54N20A erstellt, warum kennt er das bei dir nicht?
Bei mir läuft die Erstellung ohne Fehler durch...
Da gibt es z.B. den Unterschied:
-> .pfnNMI_Handler = (void*) NMI_Handler (bei dir im GCC Projekt)
-> .pfnNonMaskableInt_Handler = (void*) NonMaskableInt_Handler
usw.
Irgendwie hört sich das an, als würde da Grundsätzlich etwas falsch
laufen.
Adam P. schrieb:> Das ist verständlich, da in deinem oben genannten Projekt die Einträge> anders heißen, vergleich das mal...dabei habe ich das Projekt extra für> den> ATSAME54N20A erstellt, warum kennt er das bei dir nicht?
Hab es angepasst, lässt sich dann auch ohne Probleme erstellen. Beim
Debuggen ist dann aber genauso Schluss wie vorher.
Hab auch nochmal eine Atmel Start Datei erstellt, da muss ich komischer
Weise nichts anpassen, hat direkt die Bezeichnungen der Handler drin.
Läuft aber nach wie vor nicht. Allerdings ist das Programm dieses Mal
bei der __libc_init_array() hängen geblieben bevor es in den dummy ging.
Hab da noch so eine Idee.
Die Fuses sind momentan so eingestellt, dass die Threshold Werte für die
BOD der 3.3V Versorgungsspannung bei 2.964V - 3.112V liegen. Da meine
Spannung vom Regler nur bei 3.15V liegen, bin ich ja schon nah an der
Grenze dazu. Kann es sein, dass ich in dem Bereich mir vielleicht einen
Fehler reinziehe der zu den ganzen beschriebenen Fehlern führt? Oder
macht das wegen dem dummy_handler und so überhaupt keinen Sinn?
Als BOD33_Action ist "0x3; BKUP-; The BOD33 puts the device in battery
backup sleep mode.". Den µC betreibe ich aber in Switching bzw Linear
Mode.
Habt ihr bei euch kein Labortisch-Netzteil. Das wäre am einfachsten,
2 Adern anlöten oder sogar nur verbinden, 3.3V einstellen und
ausprobieren.
oder kannst du die Fuses für BOD nicht deaktiveren oder auf 1.7V oder
sowas runterschrauben?
Würde dann aber die andere Spannungsversorgung abziehen und die 3.3V zu
Testzwecken direkt in die Schaltung einfließen lassen.
So hab ich z.B. auch ein Fehler im Spannungsregler gefunden, vor ihm war
alles OK und danach mal so mal so, bis er gar nichts mehr geliefert
hatte.
Adam P. schrieb:> Habt ihr bei euch kein Labortisch-Netzteil.
Das probiere ich gleich noch aus. War nur erst mit den Fuses
beschäftigt, ob ich die nicht doch irgendwie noch konfiguriert bekomme.
Das ging bis jetzt ja auch noch nicht.
Manuel K. schrieb:> Rudolph schrieb:>> Was mir gerade noch einfällt ist die Takt-Erzeugung.>> In wieweit brauche ich denn überhaupt schon einen Takt? Mein Ziel ist> doch erstmal ein nacktes Programm ohne Probleme zum Laufen zu bringen.
Das sollte man sich einrahmen und an die Wand hängen.
Eigentlich wäre es das Allererste, sich einen Startupcode in Assembler
selbst zu schreiben, wenn derartige Abstürze vorkommen. Dabei lernt man
zugleich auch etwas über das Pferd, was man zu reiten beabsichtigt.
In einem Assembler-Startup hast du Gewißheit, daß die Vektoren stimmen,
sofern du selbige erstmal richtig hingeschrieben hast. Bei so einem
Startup in C bist du drauf angewiesen, daß der Compiler beim Optimieren
und auflösen der C-Ausdrücke es passend tut und nichts weg-optimiert.
Ansonsten würde ich zu allererst nach den Beschreibungen des
Startupverhaltens von Folgendem schauen:
- Watchdog. Ich hatte schon µC, wo man den WD als Allererstes
abschalten mußte, weil per Default nach Reset die Zeit bis zum ersten
erforderlichen WD-Reset zu kurz war, um überhaupt aus dem Startup
herauszukommen, da der Controller ja zuerst mit einem recht niedrigen
internen Takt anlief.
- Cache. Guck nach, ob dein Controller Cache eingebaut hat und wie
dieser nach Reset konfiguriert ist.
- Brownout-Detektor. Dessen Einstellung ist z.B. bei einigen Chips von
Nuvoton Angelegenheit eines Konfigurations-Wortes im Flash. Wenn das in
deinem Falle auch so ähnlich ist und dieses Wort im gewöhnlichen
Flash-Bereich liegt, dann ist wieder mal ein Stück auf absolute Adresse
fixierter Assemblercode nötig
- Security-Zeugs. Hier gilt das Gleiche wie für den Brownout. Beliebte
Sache bei einigen NXP Controllern.
W.S.
Ich hab den Fehler endlich gefunden. Lag doch an der Hardware.
Ich hatte beim Layouten zwei Pins vertauscht. Anstatt VSW über eine
Induktivität mit VDDCORE zu verbinden, war es an einen andere PIO
angeschlossen. Und VDDCORE hing in der Luft. Dummer Fehler der viel Zeit
gekostet hat.
Vielen vielen Dank für die zahlreichen Antworten! Einige Kommentare
werde ich im weiteren Projektverlauf oder für die nächsten Projekte
definitiv berücksichtigen. (Ein Eval-Board ist mittlerweile auch
bestellt :D)
Manuel K. schrieb:> (Ein Eval-Board ist mittlerweile auch> bestellt :D)
Na damit bekommst in der Zukunft zumindest Gewissheit, dass der Fehler
evtl. in deiner Hardware liegt :)
Softwarefehler wirken sich dann halt auf beide Boards aus.
Aber man lernt ja zum Glück nie aus ;-)
Thread beobachten
Seitenaufteilung abschalten