Ich weiß, die Frage wird viel zu viele Details vermissen, die ich nicht alle auf einen Schlag liefern kann - vielleicht habt ihr trotzdem gute Ansätze für die Lösung meines Problems (vorher gehts hier nicht nach hause..) Gefertigte PCB mit früher verifiziertem Layout hat ATSAM4S16C drauf, der muss jetzt programmiert werden. In der vorgängerversion war ein ATSAM4SA16C drauf - und das Projekt noch mit Atmel Studio 6 - dann migriert auf 7... Eben neuinstalliert auf die aktuellste Version Juni2016. JTAG ICE3 läuft mit Atmel Studio 7 - allerdings fehlt Win8 immernoch ein Treiber, den er nicht (wie von Atmel behauptet) nativ installiert. Es gibt also ein "unbekanntes Gerät" im device manager - und unter "Jungo" nur "atmelwindrvr" und "WinDriver" - aber nicht JTAGICE3. Wie gesagt, der programmer muckt aber im Studio nicht, firmwareupdate wurde auch bereits (erfolgreich) gemacht eben. Das Projekt mit alten sourcefiles und ASF neu aufesetzt, aber auch schon mit den alten files geflasht: Der Controller lässt sich anstandslos programmieren und der code verifizieren. ABER Es läuft nichts drauf, nichtmal meine LEDs lassen sich togglen. Ich weiß nur nicht, wieso der nicht startet: RST ist auf high, Versorgung ist da. So viele halbe Baustellen (Projektmigration, ICE3 Treiber und neue PCB)... wo würdet ihr anfangen? und was ist der einfachste Weg zu prüfen ob der Controller ÜBERHAUPT läuft? Not ist wirklich am Mann, auch zeitlich... ich danke euch SEHR für jede Hilfe.
Da ja schon das "s" gefehlt hat, könnten natürlich auch andere Kleinigkeiten wie das Startup, die Takteinstellung usw. fehlen. Sehe ich das richtig das selbst ein neu erstelltes Blinky nicht läuft?
hp-freund schrieb: > Da ja schon das "s" gefehlt hat, könnten natürlich auch andere > Kleinigkeiten wie das Startup, die Takteinstellung usw. fehlen. > Sehe ich das richtig das selbst ein neu erstelltes Blinky nicht läuft? Das compiler file habe ich noch nie angefasst, weil ich immer der meinung war, dass die Projekteinstellungen im Studio dazu ausreichen... Wie es jetzt diesmal kam, dass das "s" gefehlt hat (siehe Beitrag "Atmel Studio Update und nu: Build Failed" ) habe ich auch immernoch nicht verstanden, auch weil es trotz neuem Projekt inkl. neuer einbindung der ASF elemente etc noch dazu kam. Ich habe eben das Programm auf dem µC mal über den Debugger gestartet - und seitdem läuft auch ein Blinky in der alten main... trotzdem noch nicht alles (z.B. die USART-Bluetooth schnittstelle)
Alex schrieb: > trotzdem noch > nicht alles (z.B. die USART-Bluetooth schnittstelle) Das könnte noch ein Takt- oder Optimierungsproblem sein. Kannst Du den Blink Takt genau messen?
Aber als Nicht SAM4 Kenner halte ich mich lieber raus. Vielleicht gibt es noch mehr Unterschiede bei den zwei µC.
In Fällen wie Deinem rufe ich den Save all Befehl auf und fange nochmal bei Adam und seiner Frau an. Anders ausgedrückt: "Hello World" ist angesagt. Geht das nämlich, so scheint sich Deine Hardware zu manchem überreden zu lassen. Und sogar der Compiler scheint zu zucken. Geht das nicht, so sollte man den Fehler rund um die Compilerinstallation suchen oder noch schlimmer; vor der Tastatur.
Sebastian S. schrieb: > In Fällen wie Deinem rufe ich den Save all Befehl auf und fange nochmal > bei Adam und seiner Frau an. Ja, das hatte ich kurz nach Adam (was das Projekt angeht) ja auch schonmal gemacht, ganz von vorne war dann grad nicht mehr nötig: Merkwürdig ist schon, dass jetzt alles funktioniert - und alles, was ich getan habe ist im laufe der Versuche mehrmals flashen (und erster erfolg eben nach dem ersten run im debug-modus)... Ist sicher kein Wackelkontakt oder ähnliches - die platine ist professionell gefertigt und bestückt und durch mich durchgetestet - und wie gesagt, flashen ging immer. Was den Compiler und die genaueren Hintergründe angeht, schaue ich mir das morgen nochmal an - denn jetzt ist der Karren erstmal aus dem Schlamm gezogen, der µC läuft wie er soll. Die startschwierigkeiten sind allerdings ominös...
Nochmal mit einer weiteren identischen platine aus der selben fertigung verifiziert: Der Controller springt erst richtig an (läuft die routinen wie vorgesehen hab), wenn er einmal im debug modus gestartet wurde (mit ICE3). Irgendwelche ideen wie das kommen kann?
Alex schrieb: > Der Controller springt erst richtig an (läuft die routinen wie > vorgesehen hab), wenn er einmal im debug modus gestartet wurde (mit > ICE3). > > Irgendwelche ideen wie das kommen kann? Debug -> Optimierung steht als Standard auf -O1 Release -> Optimierung steht als Standard auf -Os Ich denke die Compileroptimierung macht dir was kaputt.
Hallo, wird in deinem Programm printf aufgerufen? Es könnte sein, dass der Core die Daten rauschieben will über JTAG und wartet so lange, bis die Daten vom Debugger abgerufen werden. Was du noch machen könntest (zumindest klappt es bei J-Link von Segger) über ein Tool bei hängendem Controller zu schauen, wo er genau hängt. Wenn das nicht klappt musst du von Hand suchen und LEDs toggeln lassen, je nach Stelle, wo er hängt. Die printf Ausgabe kann man normal in der IDE umstellen (makefile) von semihost zu swo. Jens
Kaj schrieb: > Debug -> Optimierung steht als Standard auf -O1 > Release -> Optimierung steht als Standard auf -Os > > Ich denke die Compileroptimierung macht dir was kaputt. Ich das .elf/hex compiliere ich inzwischen als release, vorher aber als debug. scheint aber bei beiden Fällen das gleiche Problem zu geben. Jens D. schrieb: > wird in deinem Programm printf aufgerufen? Es könnte sein, dass der Core > die Daten rauschieben will über JTAG und wartet so lange, bis die Daten > vom Debugger abgerufen werden. Ja wird es! Ich verwende sowohl printf als auch puts aus dem stdio utility des Atmes Software Frameworks. > Was du noch machen könntest (zumindest klappt es bei J-Link von Segger) > über ein Tool bei hängendem Controller zu schauen, wo er genau hängt. > Wenn das nicht klappt musst du von Hand suchen und LEDs toggeln lassen, > je nach Stelle, wo er hängt. durch die led toggle versuche die ich gemacht habe konnte ich immerhin feststellen, dass er nicht mal in die main loop einsteigt. > > Die printf Ausgabe kann man normal in der IDE umstellen (makefile) von > semihost zu swo. Details zu der printf Ausgabe würden mich gerade stark interessieren!! Ich weiß zu wenig darüber wie die auf dem sam4s im ASF umgesetzt ist... was ändert die Umstellung auf swo? Und: Müsste das nicht auch irgendwo im sourcecode configurierbar sein (wahrsch nicht in der stdio.h, die ist ja fix)? Ich habe auch den Verdacht dass das mit einer anderen problematik zusammen hängen kann: Das Bluetooth Modul wird eigentlich vom µC konfiguriert (anderer name, baudrate etc) - Alles über printf/puts OPCODE ausgaben. Auch das scheint nicht so zu funktionieren - bis es irgendwann mal (woran das liegt weiß ich noch nicht) geht, nach einem der vielen flash-Vorgänge.
P.S. jetzt kommt der clou (gerade bestätigt): Wenn ich parallel zum USART Rx des µC auch noch ein FTDI USART zu USB modul anklemme (um die vom Bluetooth modul gesendeten (geantworteten) daten abzufangen zur Überprüfung): - dann klappt die konifguration.
Könnte es sein, dass printf auf deine USART zeigt? Such mal nach "#define printf". Alex schrieb: > Wenn ich parallel zum USART Rx des µC auch noch ein FTDI USART zu USB > modul anklemme (um die vom Bluetooth modul gesendeten (geantworteten) > daten abzufangen zur Überprüfung): - dann klappt die konifguration. Schau dir die 2 Signale mal mit einem Oszi an mit und ohne FTDI Modul. Vielleicht ist der Ausgang von dem BT Modul opendrain und es fehlt ein Pullup der im Controller nicht aktiv ist / bei dem Modell an dem Pin zu klein ist. Vielleicht bleibt dein Programm bei der Initalisierung von dem Modul stehen. Falls printf auf die USART umgelenkt ist wird printf auch nichts auf SWO ausgeben.
Jens D. schrieb: > Such mal nach "#define printf". wird im kompletten Projekt nicht gefunden Jens D. schrieb: > Schau dir die 2 Signale mal mit einem Oszi an mit und ohne FTDI Modul. > Vielleicht ist der Ausgang von dem BT Modul opendrain und es fehlt ein > Pullup der im Controller nicht aktiv ist / bei dem Modell an dem Pin zu > klein ist. > > Vielleicht bleibt dein Programm bei der Initalisierung von dem Modul > stehen. > Das ist ja das merkwürdige: Das stehen bleiben, passiert nur bis zum ersten Anschluss des ICE im Debug modus - btw. die fehlerhafte Initialisierung des BT Moduls klappt nur so lange nicht, bis es einmal erfolgreich stattgefunden hat (eben dann wenn ich das FTDI modul dazu schalte). Danach, d.h. bei beliebigem Betrieb (on/off, neuflashen...) funktioniert alles wie es soll - auch insbesondere die BT kommunikation und reinitialisierung (startet auf 115kBaud und wird dann auf 230kBaud hochgestellt, jedes mal über FTDI modul nachprüfbar). Die anschließende kommunikation - und jede menge datentransfer - funktioniert dann problemlos. > Falls printf auf die USART umgelenkt ist wird printf auch nichts auf SWO > ausgeben. ist auf USART umgelenkt. wo allerdings (siehe die suche nach dem #define) ist mir grade schleirhaft (weil alles über das ASF läuft)
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.