Hallo zusammen, leider verzweifle ich an einem Problem: Ich möchte gerne mein Code, den ich in Keil µVision 5 geschrieben habe auf den Controller per JTAG (20polig) flashen. Dies geht aber nicht. Es erfolgt die Fehlermeldung: Can't halt the core Im Layout habe ich einen Jumper für BOOT0 vorgesehen. Lege ich auf Boot0 3,3V an, kann ich flashen, aber nicht vernünftig debuggen. Ich habe ebenfalls eine "Debug-LED" auf der Platine vorgesehen, die an PA12 angeschlossen ist. Im Debugmode kann ich diese nicht an, oder ausschalten (über das ODR-Register). Sie leuchtet dauerhaft. Der gleiche Code (nur die GPIO angepasst) läuft hingegen auf meinem Nucleoboard mit gleichem Controller einwandfrei (allerdings SW). Dort blinkt die LED mit meinem Testcode und ich kann vernünftig debuggen. Als Programmiergerät verwende ich den ST-Link/V2. Alle JTAG-Anschlüsse passen und die µC-Pins haben alle Masse und 3,3V wo diese auch vorgehen sind und sind auch mit 100 nF abgestützt. Wo kann der Fehler liegen? Danke euch und Gruß Daniel
:
Bearbeitet durch User
Daniel V. schrieb: > auf den Controller per JTAG (20polig) flashen. Dies geht aber nicht. Es > erfolgt die Fehlermeldung: > > Can't halt the core Das kann an zwei verschiedenen Punkten liegen: a) mit welcher Leitung kannd er Debugger/Flasher die CPU erreichen? Normalerweise geht da eine Leitung auf den normalen Reset der CPU. b) Schau dir die Resestrategie deines Debuggers an, was da eingestellt ist. Im Prinzip kann man auch ohne externen Reset mit SWD und nur den Leiteungen SWDCLK und SWDDATA Flashen. rgds
Welches Programm steuert den Stlink an? Bei der STM32 ST-Link Utility solltest Du unter ST-LINK->Settings/Mode "Connect under reset" setzen, falls auch die Resetleitung angeschlossen ist. Falls die Resetleiting fehlt, geht Openocd mit "reset_config init none"
Das geht ja schnell hier, dankeschön :-) Uwe B. schrieb: > Welches Programm steuert den Stlink an? Bei der STM32 ST-Link Utility > solltest Du unter ST-LINK->Settings/Mode "Connect under reset" setzen, > falls auch die Resetleitung angeschlossen ist. Falls die Resetleiting > fehlt, geht Openocd mit "reset_config init none" Ist in Keil integriert. Mit den Einstellungen, die ich im Bild hinzugefügt habe, kann ich nun flashen, aber der Controller läuft nicht los. Im Debugmode passiert folgendes: Bei Beenden des Codes kommt diese Fehlermeldung: Could not stop Cortex-M-Device! Please check the JTAG-Cable und wenn ich im ODR-Register den ODR12 setzte (siehe Bild 2), geht alles auf 0. Beende ich den Debugger, erscheint ebenfalls diese Fehlermeldung. 6a66 schrieb: > a) mit welcher Leitung kannd er Debugger/Flasher die CPU erreichen? > Normalerweise geht da eine Leitung auf den normalen Reset der CPU. Genau. Beim JTAG-Stecker ist Pin 15 mit Reset verbunden. Auch über einen Jumper, der auf NRST geht bzw NRST ist mit einem Jumper verbunden, d.h. es liegen auf Reset 3,3 V an. Setzte ich den Jumpper um, ziehe ich die Spannung auf Masse (abgepuffert mit einem 100 nF) und es liegen 0 V an. Hab ich auch nachgemessen das passt. Vielen Dank im voraus! Gruß Daniel
:
Bearbeitet durch User
Jim M. schrieb: > Mach mal "[x] Download to Flash" an. Leider ohne Erfolg. Ich kann flashen aber danach schmeißt er mich raus, sobald ich debuggen will. Selbst beenden kann ich die Routine nicht. Ändere ich irgendwas, alles geht auf 0 und beende ich den Debugger kommt die oben angegebene Fehlermeldung. Das Kabel selber ist in Ordnung, habe mittlerweile drei Stück ausprobiert. Der Fehler tritt auch mit einem Keil Ulink2 auf, also muss ja irgendwas falsch verdrahtet sein, hab ich aber alles nachgeprüft und auch durchgemessen. Ich hab echt keinen Schimmer mehr, woran es liegen kann... Gruß Daniel
Vielleicht mal die Frequenz etwas drosseln, 1.12MHz ist ja schon nicht ganz wenig? Spielst Du in der Software womöglich mit dem Port rum, auf dem auch JTAG liegt? Das hatte ich mal - aus Versehen in der Software JTAG weggeschaltet und als GPIO konfiguriert.
Nop schrieb: > Vielleicht mal die Frequenz etwas drosseln, 1.12MHz ist ja schon > nicht > ganz wenig? > > Spielst Du in der Software womöglich mit dem Port rum, auf dem auch JTAG > liegt? Das hatte ich mal - aus Versehen in der Software JTAG > weggeschaltet und als GPIO konfiguriert. Bei dem ST-Link V2 ist die Frequenz fix. Mit dem Ulink2 habe ich diese auf die niedrigste Frequenz gedrosselt. Das selbe Fehlerbild. Der Code ist ein Blinkytestcode, damit ich überhaupt sehe, das der Controller arbeitet. Hier mal der Testcode:
1 | #include "stm32f4xx.h" |
2 | #include "stm32f4xx_gpio.h" |
3 | #include "stm32f4xx_rcc.h" |
4 | |
5 | |
6 | int main() |
7 | { |
8 | uint32_t count; |
9 | GPIO_InitTypeDef GPIO_Struct; |
10 | |
11 | RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOA,ENABLE); |
12 | |
13 | GPIO_Struct.GPIO_Pin = GPIO_Pin_12; |
14 | GPIO_Struct.GPIO_Mode = GPIO_Mode_OUT; |
15 | GPIO_Struct.GPIO_Speed = GPIO_Speed_2MHz; |
16 | GPIO_Struct.GPIO_PuPd = GPIO_PuPd_NOPULL; |
17 | GPIO_Init(GPIOA, &GPIO_Struct); |
18 | |
19 | while (1) |
20 | { |
21 | GPIO_SetBits(GPIOA, GPIO_Pin_12); |
22 | for (count = 0; count < 3000000; count++); |
23 | |
24 | GPIO_ResetBits(GPIOA, GPIO_Pin_12); |
25 | for (count = 0; count < 3000000; count++); |
26 | } |
27 | } |
Auf dem Nucleoboard mit dem gleichen µC habe ich den Code getestet. Am D8- Port ist eine LED angeschlossen, d.h. der Code funktioniert (natürlich musste der Pin auf 8 geändert werden). Hier wurde allerdings mit SWD geflasht. Der Controller rennt direkt los und ich kann debuggen. Auf meiner Platine hingegen muss ich mit JTAG flashen und debuggen. Der JTAG liegt bei dem Controller auf PA13 (JTMS), PA14 (JTCK), PA15 (JTDI), PB3 (JTDO) und PB4 (JTRST) und sind auch aktiv (GPIOA->AFR[1] |= 0x00000000), sprich man muss die AF schon wissentlich setzen. Reset (3V3) hole ich von der Resetschaltung vom Controller über einen Jumper. Der JTAG-Stecker ist der 20 polige Standardstecker. Auch hier stimmt die Belegung. Irgendwo muss eine Einstellung im Keil getätigt werden. Der Controller ist auch richtig gewählt. Komisch ist, das ich flashen kann, aber der Controller läuft einfach nicht los. Ist Boot0 auf 3V3 kann ich flashen, aber debuggen geht auch nicht und die LED leuchtet dauerhaft. Gruß Daniel
:
Bearbeitet durch User
Hm, also jedenfalls könnte der Keil schonmal die die Delayschleifen rausoptimieren, weil count eine lokale Variable ist statt eine globale volatile. Wenn in dem Projekt die Optimierungs-Settings anders sind, wäre das auch eine Problemquelle. Was passiert, wenn Du den Code flasht und dann ohne Debugger mal laufen läßt (reset / repower)? Blinkt es? Wie ist das mit Power? Ich hab schon Beispiele gesehen, wo Power rein über JTAG ging, und andere, wo das nicht gereicht hat. Je nach Boardbeschaltung. Das müßte aber in der Doku des Boards stehen.
Nop schrieb: > Hm, also jedenfalls könnte der Keil schonmal die die Delayschleifen > rausoptimieren, weil count eine lokale Variable ist statt eine globale > volatile. Wenn in dem Projekt die Optimierungs-Settings anders sind, > wäre das auch eine Problemquelle. volatile hab ich auch schon probiert, geht nicht. Nop schrieb: > Was passiert, wenn Du den Code flasht und dann ohne Debugger mal laufen > läßt (reset / repower)? Blinkt es? Nein. Nop schrieb: > Wie ist das mit Power? Ich hab schon Beispiele gesehen, wo Power rein > über JTAG ging, und andere, wo das nicht gereicht hat. Je nach > Boardbeschaltung. Das müßte aber in der Doku des Boards stehen Nach der JTAG-Spec liegt an 1 und 2 die Controllerspannung an. Jetzt habe ich aber im Debug-Mode mit der Einstellung [x] Download to Flash folgende Fehlermeldung im Debug-Mode: Internal command error Cannot access Memory d.h. ich kann nicht auf den Speicherbereich zugreifen, obwohl ich den Controller STM32F446ret6 in Keil ausgewählt habe. Siehe Bild. Jetzt habe ich nach der Meldung gesehen, das der StartUp stm32f429_439xx.s ist. Da könnte es naheliegen, das der Speicherbereich anders ist. Nur, wie zur Hölle kommt er auf den StartUp stm32f429_439? [EDIT]: Es war im StartUp-Ordner die Datei stm32f429_439. enthalten. Diese habe ich durch die stm32f446xx.s ersetzt. Das Fehlerbild ist dennoch der gleiche. Gruß Daniel Gruß Daniel
:
Bearbeitet durch User
Daniel V. schrieb: > volatile hab ich auch schon probiert, geht nicht. Das war auch mehr gemeint als ein "kann man bei der Gelegenheit fixen" ;-) > Nop schrieb: >> Was passiert, wenn Du den Code flasht und dann ohne Debugger mal laufen >> läßt (reset / repower)? Blinkt es? > > Nein. Ja gut, Du meintest aber doch, flashen geht? Wenn er geflasht hat, müßte er auch nach einem Powerreset loslaufen. Es sei denn, daß der Code selber nicht geht, oder daß das Flashen doch nicht geht. > d.h. ich kann nicht auf den Speicherbereich zugreifen, obwohl ich den > Controller STM32F446ret6 in Keil ausgewählt habe. Mal das Linkerscript / Scatterfile beguckt? Das ist da in dem Konfigdialog von dem Screenshot unter "Linker". Die Adressen, die da so drinstehen, müssen natürlich auch zum Board passen. Das Mapfile wäre auch interessant, ob denn Code/RO-Data/Initdata wirklich da hingelinkt werden, wo das Flash ist. > Siehe Bild. Jetzt habe > ich nach der Meldung gesehen, das der StartUp stm32f429_439xx.s ist. Da > könnte es naheliegen, das der Speicherbereich anders ist. Unwahrscheinlich, weil die Speicherbereiche normalerweise nicht im Startup festgelegt werden, sondern im Linkerfile. Kann aber sein, daß der Startupcode trotzdem noch Merkwürdigkeiten enthält. Andererseits läuft der ja auf demselben Controller des anderen Boards auch. > Nur, wie zur Hölle kommt er auf den StartUp stm32f429_439? Wahrscheinlich über die Projektsettings, oder weil das Startupfile kompatibel ist auch für Deinen Controller.
Nop schrieb: > Ja gut, Du meintest aber doch, flashen geht? Wenn er geflasht hat, müßte > er auch nach einem Powerreset loslaufen. Es sei denn, daß der Code > selber nicht geht, oder daß das Flashen doch nicht geht. Ja, genau, das bereitet mir ja die Kopfschmerzen. Ich habe mal die Build Output als Bild angehängt. Nop schrieb: > Mal das Linkerscript / Scatterfile beguckt? Das ist da in dem > Konfigdialog von dem Screenshot unter "Linker". Die Adressen, die da so > drinstehen, müssen natürlich auch zum Board passen. Habe ich ebenfalls als Bild hinzugefügt. Immer noch das selbe Fehlerbild. Den Haken bei Download to Flash habe ich entfernt, da kommt die Fehlermeldung Could not stop Cortex-M-Device! Please check the JTAG-Cable. Auch in der stm32f4xx.h habe ich folgende define unkommentiert:
1 | #define STM32F446xx |
Gruß Daniel
:
Bearbeitet durch User
schon mal den Schaltplan des Boards konsultiert ? Der uC hat zwar JTAG, aber das bedeutet ja nicht zwangsläufig, das diese Leitungen auch an der Programmierschnittstelle angeschlossen sind. Meist wird SW statt JTAG benutzt. Und ältere JTAG Programmer können kein SW. Auf der 20-poligen Anschlussleiste kann beides anliegen. Gruß, dasrotemopped.
dasrotemopped schrieb: > schon mal den Schaltplan des Boards konsultiert ? > Der uC hat zwar JTAG, aber das bedeutet ja nicht zwangsläufig, das diese > Leitungen auch an der Programmierschnittstelle angeschlossen sind. Das ist ja mein eigenes selbst entwickeltes Board und da habe ich JTAG definitiv angeschlossen. Ich habe es heute Morgen auch nochmal nachgeprüft um Fehler auf der PCB auszuschließen. Gruß Daniel
:
Bearbeitet durch User
Schrieb ich an dieser Stelle schon: Daniel V. schrieb: > Der JTAG liegt bei dem Controller auf PA13 (JTMS), PA14 (JTCK), PA15 > (JTDI), PB3 (JTDO) und PB4 (JTRST) und sind auch aktiv (GPIOA->AFR[1] |= > 0x00000000), sprich man muss die AF schon wissentlich setzen. Reset > (3V3) hole ich von der Resetschaltung vom Controller über einen Jumper. Steckerbelegung stimmt auch. Deswegen weiss ich ja nicht weiter. Ich kann auch mit SW flashen, aber der Controller rennt auch hier nicht los und debuggen geht auch nicht. Es erscheint die Fehlermeldung: Could not stop Cortex-M-Device! Please check the JTAG-Cable. Auch die Frequenz habe ich im SW-Mode mal auf 100 kHz gesetzt. Gleiches Fehlerbild. Gruß Daniel
:
Bearbeitet durch User
>Reset(3V3) hole ich von der Resetschaltung vom Controller über einen >Jumper.
Der Programmer will Reset selbst ziehen und loslassen. Hart auf Pegel
gezogen-> Fehler
?? Resetschaltung ??
dasrotemopped schrieb: > ?? Resetschaltung ?? Hmmmm... Normalerweise wird diese durch einen Taster realisiert. Aus Platzgründen habe ich einen Jumper vorgesehen. Gruß Daniel
:
Bearbeitet durch User
In engen Schleifen wie for (count = 0; count < 3000000; count++); hat der Debugger haeufig Schwierigkeiten das Programm zu unterbrechen. Der Debugger muss entweder ueber die Resetleitung oder uber Jtag ein Reset erzeugen...
Uwe B. schrieb: > In engen Schleifen wie > for (count = 0; count < 3000000; count++); > hat der Debugger haeufig Schwierigkeiten das Programm zu unterbrechen. > > Der Debugger muss entweder ueber die Resetleitung oder uber Jtag ein > Reset erzeugen... Ja, aber warum funktioniert das auf dem Nucleoboard? Wegen SW? Gruß Daniel
Guck Dir doch mal die Schematics des Olimex H405 an, wie der Reset da mit JTAG verknüpft ist: https://www.olimex.com/Products/ARM/ST/STM32-H405/resources/STM32-H405_sch.pdf Ich hab das Board selber, und damit geht JTAG problemlos. Ist natürlich ein STM32F405RG drauf, der evtl. vom Pinning her anders ist, aber halt das Prinzip, das sollte auch für Deine CPU gelten.
Nop schrieb: > Guck Dir doch mal die Schematics des Olimex H405 an, wie der Reset > da > mit JTAG verknüpft ist: > > https://www.olimex.com/Products/ARM/ST/STM32-H405/... > > Ich hab das Board selber, und damit geht JTAG problemlos. Ist natürlich > ein STM32F405RG drauf, der evtl. vom Pinning her anders ist, aber halt > das Prinzip, das sollte auch für Deine CPU gelten. Öhm, das ist ja genauso wie ich es habe. Ein 10k Pullup auf 3V3, ein 100 nF auf Masse und der Jumper zieht den je nach Stellung auf Masse. Gruß Daniel
Daniel V. schrieb: > Genau. Beim JTAG-Stecker ist Pin 15 mit Reset verbunden. Auch über einen > Jumper, der auf NRST geht bzw NRST ist mit einem Jumper verbunden, d.h. > es liegen auf Reset 3,3 V an. Setzte ich den Jumpper um, ziehe ich die > Spannung auf Masse (abgepuffert mit einem 100 nF) und es liegen 0 V an. > Hab ich auch nachgemessen das passt. Zum Verständnis: NRST geht wie zu VDD bzw. Masse? Direkt über den Jumper oder mit Pullup/Pulldown? Welcher Widerstand? Laut DB ziehen auch die internen Resets NRST direkt auf Low oder versuchen es zumindest... Edit: Sollte dann eigentlich passen
:
Bearbeitet durch User
Ja, was den Taster angeht schon. Aber der ist ja auch nicht das Problem, sondern was ist bei Dir mit JTAG Pin 15? Bei der Olimex-Schematic ist mir allerdings "U2" nicht ganz klar, was das Ding eigentlich tut.
Ich seh gerad, hattest Du ja schon geschrieben weiter oben, daß 15 auf Reset geht. Aber nicht durch die Jumper, sondern parallel dazu, oder?
Nop schrieb: > Ja, was den Taster angeht schon. Aber der ist ja auch nicht das Problem, > sondern was ist bei Dir mit JTAG Pin 15? Die ist mit 3V3 vom Reset verbunden. Hier liegen auch 3,3 V an. Setzte ich den Jumper auf 2 und 3 werden diese auf Masse gezogen. Auch auf Pin 15. Nop schrieb: > Ich seh gerad, hattest Du ja schon geschrieben weiter oben, daß 15 auf > Reset geht. Aber nicht durch die Jumper, sondern parallel dazu, oder? Ja, parallel. [EDIT]: Sorry für das Doppelbild ;) Gruß Daniel
:
Bearbeitet durch User
Daniel V. schrieb: > Uwe B. schrieb: >> In engen Schleifen wie >> for (count = 0; count < 3000000; count++); >> hat der Debugger haeufig Schwierigkeiten das Programm zu unterbrechen. >> >> Der Debugger muss entweder ueber die Resetleitung oder uber Jtag ein >> Reset erzeugen... > > Ja, aber warum funktioniert das auf dem Nucleoboard? Wegen SW? > Auch auf Nucleo Boards machen enge Schleifen ein Problem. Aber auf dem Nucleo Boards kann der Debugger einen NRST ausloesen und damit die Scheife aufbrechen ("Connect under reset").
Uwe B. schrieb: > Auch auf Nucleo Boards machen enge Schleifen ein Problem. Aber auf dem > Nucleo Boards kann der Debugger einen NRST ausloesen und damit die > Scheife aufbrechen ("Connect under reset"). Keine Chance, läuft nicht. Der Controller läuft nach Neustart noch nicht mal los... Ich bin mit meinem Latein am Ende und hab keinen Dunst woran das noch liegen kann. Gruß Daniel
Daniel V. schrieb: > Auf meiner Platine hingegen muss ich mit JTAG flashen und debuggen. Wieso? Sind da noch mehr Devices in der JTAG Chain? Wenn nein, dann mal einfach SWD ausprobieren. Bei einzelnem Device müssten die Pins stimmen. Wenn die nicht stimmen ist IMO die Pinbelegung flsach.
Jim M. schrieb: > Wenn nein, dann mal einfach SWD ausprobieren. Bei einzelnem Device > müssten die Pins stimmen. Wenn die nicht stimmen ist IMO die Pinbelegung > flsach. Zeigt leider das selbe Fehlerbild. Die Pinbelegung habe ich durchgemessen und auch überprüft. Siehe Bilder von meinen letzten Posts. Gruß Daniel
Hmm, mal eine grundsätzliche Frage: Die Platine hast Du also selbst entworfen. Haben Tests denn zweifelsfrei ergeben, daß das Board selber erstens von der Konstruktion her überhaupt funktioniert, und zweitens, haben Tests bewiesen, daß dieses konkrete Exemplar intakt ist?
Nop schrieb: > Hmm, mal eine grundsätzliche Frage: Die Platine hast Du also selbst > entworfen. Haben Tests denn zweifelsfrei ergeben, daß das Board selber > erstens von der Konstruktion her überhaupt funktioniert, und zweitens, > haben Tests bewiesen, daß dieses konkrete Exemplar intakt ist? Nein, das ist ein Prototyp und daher ungetestet, daher stelle ich ja hier die Frage in der Hoffnung eine Lösung für mein Problem zu finden, da ich m.M alles was mit dem Controller zu tun nachgeprüft habe (Pinbelegung, Kondensatoren, usw...) und ich nicht mehr weiter weiß und alles mögliche hinterfragt habe. Getestet habe ich bisher: Platine selber, optische Prüfung, Lötbrücken usw. -> OK Kurzschlusswiderstand bei Erhalt der Platine -> OK (ca 110k) Spannungen (5V Versorgung durch Labornetzteil oder durch USB), 3,3V hinter den Spannungsregler -> OK Pinbelegungen des Controllers -> OK Hat der Controller auf jeder Seite Masse und 3,3V? -> OK Liegt Masse, 3V3, 5V für den FTDI an? -> OK Betriebsstrom laut Netzteil im Leerlauf: 0,1 A -> Habe ich erwartet, OK Stimmen die JTAG-Anschlüsse wie im Datenblatt usw. -> OK Eine komplette Design Verification habe ich natürlich nicht durchgeführt. Bei der Entwicklung in Eagle wurde der ERC sowie der DRC auch bestanden und ein anderer Entwickler hat auch nochmal drübergeguckt. Normalerweise müsste ich also auf den Controller zugreifen und debuggen können. Flashen kann ich ja aber Debuggen halt nicht und der Controller läuft nach einem Powerreset nicht los. Es scheint so, als beharrt er in einem undefinierten Zustand. Gruß Daniel
:
Bearbeitet durch User
OK, von Hardware habe ich nicht soviel Ahnung, aber ich würde die Fehlersuche systematisieren. Im Moment kann es das Design sein, das konkrete Board, der JTAG-USB-Adapter oder die Keil-Umgebung. Wenn Du Dir ein Evalboard besorgst wie etwa das Olimex H405 für 15 Euro, das geht auch über JTAG zu machen. Damit könntest Du erstmal den Fehler systematisch eingrenzen und alles außer dem Design/Board ausschließen. Gerade bei dem Ulink2 erinnere ich, daß es gelegentlich Probleme gab, wenn das Ding jemals an einem Win8-Rechner angeschlossen war und dann an einem Win7-Rechner seine Arbeit verrichten soll. Irgendwas mit der Firmware, genaueres gibt's aber auf der Keil-Seite.
Nop schrieb: > OK, von Hardware habe ich nicht soviel Ahnung, aber ich würde die > Fehlersuche systematisieren. Im Moment kann es das Design sein, das > konkrete Board, der JTAG-USB-Adapter oder die Keil-Umgebung Genau systematisieren. Fehler im Design ist nicht auszuschließen, halte ich aber für unwahrscheinlich. Das Board habe ich durchgemessen, Reset, JTAG alles passt soweit. Der Spannungsregler kann bis zu 1A Strom liefern, schließe ich auch aus. Ich habe ja alles durch, bevor ich mich ans Forum gewendet habe. Der JTAG-USB-Adapter ST/Link V2 habe ich neu von ST bekommen. Mit dem ULink2 (war niemals an einem Win8-Rechner) konnte ich den Fehler reproduzieren. In der Keilumgebung, da vermute ich auch den Fehler. Allerdings werde ich morgen mal recherchieren ob ich auf dem Nucleoboard auch mit JTAG den dortigen Controller flashen kann. Geht das, dann liegt das definitiv am Design. Aber wo, das ist die Frage... Gruß Daniel
:
Bearbeitet durch User
Daniel V. schrieb: > Das Board habe ich durchgemessen, Reset, > JTAG alles passt soweit. Wie schließt Du einen Defekt an einem der Bauteile aus? Kann ja auch sein, daß der Controller z.B. mal durch ESD gegrillt wurde.
Soweit ich mich erinnere, habe ich am Reseteingang eines STM32 noch nie ein Pullup eingesetzt. Die Empfehlung von ST ist auch dementsprechend (siehe Bild). Interner Widerstand: min. 30k, externer Widerstand: 10k ergibt 7,5k Kann es vielleicht daran liegen?
Nop schrieb: > Wie schließt Du einen Defekt an einem der Bauteile aus? Kann ja auch > sein, daß der Controller z.B. mal durch ESD gegrillt wurde. ESD-Schlappen und eine ESD-Schutzschaltung (die aber auf USB-Seite sitzt, also nicht gerade wirksam ist) Mehmet K. schrieb: > Soweit ich mich erinnere, habe ich am Reseteingang eines STM32 noch nie > ein Pullup eingesetzt. > Die Empfehlung von ST ist auch dementsprechend (siehe Bild). > Interner Widerstand: min. 30k, externer Widerstand: 10k ergibt 7,5k > Kann es vielleicht daran liegen? Überbrücke ich den Widerstand mit einem Draht, komme ich gar nicht auf den Controller drauf. Fehlermeldung: Can't halt the core. Eine allgemeine Frage: Beim Reset wird doch die Spannung auf Pin 15 (JTAG) vom ST/Link auf Masse gezogen. Jetzt habe ich mal mit dem Oszi geguckt. Die Spannung ist dauerhaft auf 3,3 V d.h. zur keiner Zeit fällt die Spannung kurzzeitig ab, diese beharrt auf 3,3V der Controller wird also nie resettet. Gruß Daniel
:
Bearbeitet durch User
Daniel V. schrieb: > Eine allgemeine Frage: > > Beim Reset wird doch die Spannung auf Pin 15 (JTAG) vom ST/Link auf > Masse gezogen. Jetzt habe ich mal mit dem Oszi geguckt. Die Spannung ist > dauerhaft auf 3,3 V d.h. zur keiner Zeit fällt die Spannung kurzzeitig > ab, diese beharrt auf 3,3V der Controller wird also nie resettet. > Im ST-Link Programm "Connect under reset" aktiviert?
Uwe B. schrieb: > Im ST-Link Programm "Connect under reset" aktiviert? Ja, in Keil, Target-Einstellungen. Siehe Bilder meiner vorigen Posts. Gruß Daniel
Bei den Optionen ganz weit oben im Thread steht für Reset: "autodetect". Kann man da vielleicht sowas wie "hardware" einstellen? Und bei dem Reiter für Flash Download, kannst davon mal nen Screenshot machen?
Nop schrieb: > Bei den Optionen ganz weit oben im Thread steht für Reset: "autodetect". > Kann man da vielleicht sowas wie "hardware" einstellen? Und bei dem > Reiter für Flash Download, kannst davon mal nen Screenshot machen? Sehr gerne (Bild 1). So, jetzt habe ich mit dem Oszi mal angeschaut ob der Reset durch den JTAG auf Masse gezogen wird. Im Flashvorgang wird der Reset insgesmt 3x für 16,3 ms auf Masse gezogen.(Bild 2, 3) Im Debugmodus wird ebenfalls der Reset 3x auf Masse gezogen.(siehe Bild 3) Danach springt alles auf 0 und die Fehlermeldung mit dem JTAG-Kabel erscheint. Ich weiss gerade nicht, wie ich das bewerten soll. Gruß Daniel
:
Bearbeitet durch User
Daniel V. schrieb: > Sehr gerne (Bild 1). OK, da steht jetzt ja auch "hardware", also wird der Reset gezogen. Auf dem Board kommt das auch an, wie man auf dem Oszi sieht. Was ist mit dem anderen Reiter in dem Config-Dialog, der rechte Reiter, wo "Flash Download" steht? Gibt's da irgendwas Interessantes? Übrigens würde ich immer "verify flash download" auch noch anschalten, jedenfalls sofern Deine Software keine CRC über sich selbst bildet und auf dem Target auch prüft. Du könntest Dir natürlich auch CoFlash mal installieren, das sollte mit ST-Link umgehen können: http://www.coocox.org/software/CoFlash.php Wenn's damit geht, dann liegt es mit Sicherheit an der Keil-Umgebung.
Nop schrieb: > Was ist mit dem anderen Reiter in dem Config-Dialog, der rechte Reiter, > wo "Flash Download" steht? Gibt's da irgendwas Interessantes? Liefere ich gerne nach (Bild 5). Ich habe mir schon gedacht, das hier die Speicheradressen falsch sind. Daher versucht der Debugger auf Bereiche zuzugreifen die gar nicht oder nur fehlerhaft beschrieben sind. Aber ich kann nur diesen wählen (Bild 6). Er verweilt irgendwo und deshalb rennt er nach einem Powerreset nicht los. Gruß Daniel
:
Bearbeitet durch User
Nee, die RAM-Adressen sind genau das, was ich bei einem STM32F4 auch erwarten würde. Da starten die bei meinem H405 ja auch, auch wenn das ein F405 ist und kein F446. Also ich würd erstmal CoFlash anwerfen, und wenn das auch nicht geht, über die 15 Euro für ein H405 nachdenken - das wird nämlich mit funktionierender Software ausgeliefert und über JTAG geladen, so daß man überhaupt schonmal beim Anwerfen sieht, ob die Hardware an sich intakt ist. Du wärest nicht der Erste hier, der sehr merkwürdige Probleme dieser Art hat und wo sich am Ende rausstellt, es war ein defekter Controller.
Nop schrieb: > Also ich würd erstmal CoFlash anwerfen, und wenn das auch nicht geht, > über die 15 Euro für ein H405 nachdenken - das wird nämlich mit > funktionierender Software ausgeliefert und über JTAG geladen, so daß man > überhaupt schonmal beim Anwerfen sieht, ob die Hardware an sich intakt > ist. So, ich habe mir das Programm jetzt mal angeschaut. Flashe ich mit Keil das u.a. Programm und gehe dann mit CooCox auf Erase kommt ein Timeout. Setzte ich den Jumper für Boot0, also Boot0 ziehe ich auf 3,3V und lösche den Bootbereich, kann ich anschließend bei Boot0=LOW auch den Flash-Bereich löschen. Zudem leuchtet die LED dauerhaft und es liegen vor dem Widerstand 2 V an. Das ist komisch, wenn doch der Bootbereich gelöscht wurde. Nach einem Powerreset ist die LED aus. Flashe ich das axf.File mit CooCox, funktioniert es und auch die Verify ist erfolgreich. Der Controller rennt dennoch nach einem Powerreset nicht los. Die Pin-Belegung der LED ist PA12. Das Blinkyprogramm habe ich nochmal umgeschrieben:
1 | /*Testprogramm*/ |
2 | #include "stm32f4xx.h" |
3 | #include "stm32f4xx_gpio.h" |
4 | #include "stm32f4xx_rcc.h" |
5 | |
6 | #define D8 GPIO_Pin_12 |
7 | |
8 | int main() |
9 | { |
10 | uint32_t count_max = 15000000; |
11 | volatile uint32_t count; |
12 | |
13 | GPIO_InitTypeDef GPIO_Struct; |
14 | |
15 | RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOA,ENABLE); |
16 | |
17 | GPIO_Struct.GPIO_Pin = D8; |
18 | GPIO_Struct.GPIO_Mode = GPIO_Mode_OUT; |
19 | GPIO_Struct.GPIO_Speed = GPIO_Speed_2MHz; |
20 | GPIO_Struct.GPIO_PuPd = GPIO_PuPd_NOPULL; |
21 | GPIO_Init(GPIOA, &GPIO_Struct); |
22 | |
23 | while (1) |
24 | { |
25 | GPIO_SetBits(GPIOA, D8); |
26 | for (count = 0; count < count_max; count++); |
27 | |
28 | GPIO_ResetBits(GPIOA, D8); |
29 | for (count = 0; count < count_max; count++); |
30 | } |
31 | } |
Ich habe die Blinkfrequenz niedriger gestellt. Der Code funktioniert auf dem Nucleo wunderbar (mit #define D8 GPIO_Pin_9). Auf meinem Board rührt sich nichts. Um auszuschließen das die LED zu träge ist, bin ich mit dem Oszi dran um eventuelle Pulse auszuschließen. Es sind keine Pulse da. Nach einem Powerreset ist die LED aus und es liegt keine Spannung an. Gruß Daniel
:
Bearbeitet durch User
Daniel V. schrieb: > Überbrücke ich den Widerstand mit einem Draht, komme ich gar nicht auf > den Controller drauf. Nicht überbrücken, sondern entfernen.
Mehmet K. schrieb: > Nicht überbrücken, sondern entfernen. Wüsste ich jetzt nicht, was das für ein Unterschied machen soll. Widerstand ist zwecklos ;). Zudem ist oben bei dem Evalboard auch ein Pullup eingebaut. Ich kenn das auch nicht anders. Zumal der JTAG den Reset zieht, siehe Oszibilder. Folgende Fragestellungen habe ich jetzt untersucht: Design? hab ich jetzt auch kontrolliert und wüsste jetzt nicht, wo da noch der Fehler liegt. Der JTAG-Stecker ist zudem nah am Controller. ISt ein Prototyp und ist auf jeden Fall möglich. Verdrahtung? Ist in Ordnung. Hab ich mehrmals gemessen. Keil-Umgebung? Controller lässt sich flashen, läuft aber nicht los. Debuggen geht nicht. Flashe ich den Controller mit Keil, kann ich mit CooCox den Speicher nicht löschen, erst wenn BOOT0=High und ich den Bootbereich gelöscht habe. Hier kann noch ein Fehler in der Targeteinstellung sein. Nop schrieb: > Du wärest nicht der Erste hier, der sehr merkwürdige Probleme dieser Art > hat und wo sich am Ende rausstellt, es war ein defekter Controller. Ich hoffe nicht, aber ich ahne es und ich hab keinen zweiten da. Sonst weiss ich nicht mehr weiter. Gruß Daniel
:
Bearbeitet durch User
Daniel V. schrieb: > Wüsste ich jetzt nicht, was das für ein Unterschied machen soll. Ueberbrücken -> 0R Entfernen -> 30k interner Widerstand
Mehmet K. schrieb: > Ueberbrücken -> 0R > Entfernen -> 30k interner Widerstand Ich hab nichts gesagt. Durch die Brücke mache ich den 30k ebenfalls "sinnlos" ;) Um auch diesen Fehler auszuschließen, habe ich das auch getan :) Ich kam gar nicht auf den Controller drauf (Can't halt the core). Gruß Daniel
:
Bearbeitet durch User
Hatte an meinem 32F407 mal so ein ähnliches Problem. Ist zu lange her, weis nur noch, das ich an den BOOT0 / BOOT1 -Jumpern spielen muste um das Board zu reanimieren.
Torsten S. schrieb: > Hatte an meinem 32F407 mal so ein ähnliches Problem. Ist zu lange her, > weis nur noch, das ich an den BOOT0 / BOOT1 -Jumpern spielen muste um > das Board zu reanimieren. Und da habe ich einen Fehler gemacht. BOOT1 ist komplett frei, weder gegen Masse noch gegen 3V3. Da habe ich mir aber auch mit einer Brücke beholfen einmal auf 3V3 und einmal gegen Masse und an den Jumper von BOOT0 herumprobiert. Das selbe Ergebnis. Gruß Daniel
:
Bearbeitet durch User
Torsten S. schrieb: > Hatte an meinem 32F407 mal so ein ähnliches Problem. Ist zu lange her, > weis nur noch, das ich an den BOOT0 / BOOT1 -Jumpern spielen muste um > das Board zu reanimieren. Dein Tipp bringt mich wohl auf die richtige Spur. Der Controller bleibt im Bootvorgang hängen und verhindert ein weiteres flashen. Zudem liegt ein Design-Fehler vor, denn ich habe leider den Boot1-Pin nicht belegt und werde nun irgendwie ein dünnen Draht nach Masse über einen 10k verlöten. Auch die USART1 habe ich zum FTDI gelegt, fällt also auch weg (mit Boot0=High und Boot1=High kann man den Controller auch über die USART1 flashen) Gruß Daniel
Beachte auch das Errata ES2098 2.1.3 Full JTAG configuration without NJTRST pin cannot be used . . 10
Was noch merkwürdig ist - immerhin geht die LED ja an. Also irgendwas muß da ja laufen, denn per Default sind IO-Pins als Input konfiguriert. Hast Du das Teil mal längere Zeit stehen lassen, ob die LED dann vielleicht wieder ausgeht?
Das ganze Verhalten ist merkwürdig. Mein Bestücker und tech. Berater kann den Fehler auf meinen anderen Platinen ebenfalls reproduzieren. Also kein defekter µC sondern ein Designfehler. Aber was bloß? Ich hatte bisher auch den BOOT1 immer freigelassen und BOOT0 einen Jumper gesetzt (LOW). Was habe ich bisher gemacht? Flashe ich mit Keil und BOOT0=LOW und BOOT1=LOW (ich habe ein dünnen CU-Draht an das µC-Beinchen gelötet und dann über einen 10k an einem Masse-VIA verbunden) das o.a. Programm, leuchtet die LED dauerhaft. Keine Pulse. Nach Powerreset ist die LED aus. Versuche ich mit CoFlash den Bereich zu löschen, kommt ein Timeout. Setzte ich aber den Jumper BOOT0=HIGH und lösche den Speicherbereich (LED bleibt danach auch an!) dann erst kann ich den anderen Speicherbereich bei BOOT0=LOW löschen. Nop schrieb: > Was noch merkwürdig ist - immerhin geht die LED ja an. Also irgendwas > muß da ja laufen, denn per Default sind IO-Pins als Input konfiguriert. Eben. Nur PA12 ist Output. > Hast Du das Teil mal längere Zeit stehen lassen, ob die LED dann > vielleicht wieder ausgeht? Gute Idee. Gruß Daniel
:
Bearbeitet durch User
Meine Idee hier ist - wenn der XTAL nicht anschwingt, dann wird bei SystemInit() das Umschalten auf den externen Quartz nicht gehen. Das ist in system_stm32f4xx.c die Funktion SystemInit(), welche wiederum die Funktion SetSysClock() aufruft. Und in selbiger findet sich am Ende dieses Codefragment (Peripherals Standard Libraby, die HAL-Version könnte anders sein):
1 | else
|
2 | { /* If HSE fails to start-up, the application will have wrong clock |
3 | configuration. User can add here some code to deal with this error */
|
4 | }
|
Dann läuft das System weiterhin mit 16MHz direkt auf dem HSI, was im Vergleich zu den 168MHz ein Faktor 10 weniger an Geschwindigkeit wäre. Da die Delayschleifen mit Berechnungen gemacht sind, dauern die dann natürlich richtig lange, während die auf dem Nucleo mit funktionierendem XTAL viel schneller durch sind. Daher die Frage, ob die LED irgendwann auch wieder ausgeht.
Ich vermute schon, aber so genau kenne ich die Keil-Umgebung jetzt auch nicht. Zumal er im Debug-Modus eigentlich am Einsprung des Reset-Handlers stehenbleiben sollte, so kenne ich das.
Ja, der bleibt beim Booten hängen und das ist komisch. Die LED leuchtet daher dauerhaft.
:
Bearbeitet durch User
Ich habe gerade gesehen, dass die USART3-Pins belegt sind, nicht die USART1. Wenn ich jetzt BOOT0=High und BOOT1=High über SWD auf die USART1 gehe, kann ich den Controller reanimieren? Kann ich den Code, den ich oben geschrieben habe flashen? Wieso hängt in der jetzigen Konfiguration überhaupt im Bootvorgang fest? JTAG ist angeschlossen, Reset zieht er auch, Boot0 = LOW (über einen 10k) und Boot1 war gar nicht belegt. Muss bei dieser Konfiguration Boot1 immer Masse haben? Kann das der Fehler beim allerersten flashen gewesen sein? Da fehlt mir jetzt doch die gewisse Erfahrung. Gruß Daniel
:
Bearbeitet durch User
Ja, genauso hatte ich das allererste Mal mein Testcode über JTAG geflasht. BOOT0=0 und BOOT1=nicht belegt und der Controller rennt nicht los und ich konnte nicht debuggen, Diverse Fehlermeldungen (Can't halt the core, Could not stop Cortex-M-Device! Please check the JTAG-Cable). Dieser Fehler konnte auch meinen anderen Boards reproduziert werden, spricht für ein Design-Fehler auf der PCB. Nur bis jetzt habe ich nicht herausgefunden, woran es liegen (Außer das BOOT1=x) kann. Deshalb ist die UART-Variante meine letzte Chance den Controller wiederzubeleben.
:
Bearbeitet durch User
Also hab mal kurz das DS10693 und die AN2606 überflogen. Ich denke mal das noch nichts verloren ist. Man kann nicht nur über UART, sondern auch über SPI, USB, I2C und CAN flashen wenn man BOOT0/1 auf Systemmemory jumpert. Was ich nicht weiss, welches Tool das unterstützt. (Gibts da nicht ein Kommandozeilen-Tool von ST? Ach bin zu lange raus)
Torsten S. schrieb: > Also hab mal kurz das DS10693 und die AN2606 überflogen. Ich denke > mal > das noch nichts verloren ist. Man kann nicht nur über UART, sondern auch > über SPI, USB, I2C und CAN flashen wenn man BOOT0/1 auf Systemmemory > jumpert. Was ich nicht weiss, welches Tool das unterstützt. (Gibts da > nicht ein Kommandozeilen-Tool von ST? Ach bin zu lange raus) Hmmm, ich habe ein FTDI an den USART3 hängen, für die spätere Datenübertragung. Ich weiss jetzt nur nicht ob das mit dem µC geht, mit einem Discovery scheint es zu gehen. http://stm32f4-discovery.net/2014/09/program-stm32f4-with-uart/ Da wird auch das Flashtool von ST verwendet. Ich verstehe halt immer noch nicht, warum der Flashvorgang überhaupt schief geht. Das muss doch ein Grund haben. Gruß Daniel
:
Bearbeitet durch User
Daniel V. schrieb: > http://stm32f4-discovery.net/2014/09/program-stm32f4-with-uart/ Ahh, das kannte ich noch gar nicht. Spann uns nicht auf die Folter und probiers doch einfach mal aus. > Ich verstehe halt immer noch nicht, warum der Flashvorgang überhaupt > schief geht. Das muss doch ein Grund haben. Als Unbeteiligter kann man auch nur raten. Vielleicht ist Dein Programm fürs Sram kompiliert und befindet sich nun im Flash? Linkerscript gecheckt?
Torsten S. schrieb: > Daniel V. schrieb: >> http://stm32f4-discovery.net/2014/09/program-stm32... > > Ahh, das kannte ich noch gar nicht. Spann uns nicht auf die Folter und > probiers doch einfach mal aus. Morgen werde ich das ausprobieren. >> Ich verstehe halt immer noch nicht, warum der Flashvorgang überhaupt >> schief geht. Das muss doch ein Grund haben. > > Als Unbeteiligter kann man auch nur raten. > > Vielleicht ist Dein Programm fürs Sram kompiliert und befindet sich nun > im Flash? Linkerscript gecheckt? Da muss ich jetzt echt passen. Ich weiss gerade nicht wie und wo das bei Keil geht. Die Targeteinstellungen sind ja im Thread abgebildet. Werde ich morgen auch mal recherchieren.
:
Bearbeitet durch User
So, ich habe das ganze mal mit einem USB->UART-Wandler in der Tat umgesetzt. Dabei ist TX PA9 und RX PA10. Es kommt folgende Fehlermeldung: stm flash loader unrecognized device Tja... Der Controller will mich fertig machen xD Gruß Daniel PS: Vertauschen auch probiert.
:
Bearbeitet durch User
so, der Controller läuft, aaaaber es gibt einen Haken: Den Code habe ich mit dem CubeMX erzeugt. Es ist also kein Designproblem sondern ein Codeproblem. Ich werde nun den von Cube erzeugten Code analysieren. Blöd nur, das der o.a. Code auf dem Nucleo läuft...
:
Bearbeitet durch User
Fehler gefunden So, ihr lieben, für die Leute, die auch irgendwann mal vor diesem Problem stehen: Der Fehler ist bei der Clockkonfiguration zu suchen. Da ich einen externen Quarz angeschlossen habe, muss dieser beim Start konfiguriert werden. Da die Ports generell auf Input konfiguriert sind, muss dieser im RCC aktiviert werden und die Timer entsprechend eingestellt werden. Als ersten Test habe ich den Quarz heruntergenommen und siehe da, der Controller läuft und die LED blinkt lustig vor sich hin. Gruß Daniel
:
Bearbeitet durch User
Daniel V. schrieb: > Der Fehler ist bei der Clockkonfiguration zu suchen. Da ich einen > externen Quarz angeschlossen habe, muss dieser beim Start konfiguriert > werden. Und ich hab bei einem meiner vorherigen Posts noch auf die Konfig des Quarz verwiesen. (: Merkwürdig ist nur, wenn der nicht hochkommt, dann rennt die Stdlib einfach auf den HSI weiter, dann halt nur mit 16 MHz. Hätte also gehen müssen, ggf. halt zehnmal langsamer. Ich nutze ja die Stdlib nicht, aber bei meinem Zeugs habe ich für den Fall "externer Quarz läuft nicht an" einen eigenen Fehler-Eintrag im POST. Kann ja auch sein, daß der vor dem Bestücken runtergefallen und zerbrochen ist. Nur schalte ich dann eben als Fallback die PLL auf den HSI, damit es geordnet weitergeht. Aber cool, daß der Krimi sich lösen ließ!
Nop schrieb: > Und ich hab bei einem meiner vorherigen Posts noch auf die Konfig des > Quarz verwiesen. (: Merkwürdig ist nur, wenn der nicht hochkommt, dann > rennt die Stdlib einfach auf den HSI weiter, dann halt nur mit 16 MHz. > Hätte also gehen müssen, ggf. halt zehnmal langsamer. Ja, Dein Tipp ging in die richtige Richtung. Erst nachdem der von CubeMX erzeugte Code funktionierte (da war die Taktquelle explizit definiert) konnte ein Hardwarefehler sicher ausgeschlossen werden. Das Problem war aber, das er sich im Debugmode komplett aufgehangen hat. Irgendwo war kein Timer eingeschaltet oder ein Teiler auf 0. Ich weiss es noch nicht. Torsten S. schrieb: > Danke dass Du uns das wissen läßt Sehr gerne ;). Ich habe aber auch wertvolle Tipps bekommen. Ich werde auch noch einen funktionierenden Testcode (ohne CubeMX) die Tage posten.
:
Bearbeitet durch User
Wie versprochen gibt es jetzt eine genaue Fehleranalyse für die Nachwelt: Fehlerbeschreibung Es wurde ein STM32F446ret6 mit einem externen Schwinger mit 25 MHz verbaut. Das Problem stand darin, das der Controller sich zwar flashen lies aber nicht losrannte. Im Debugmode kamen folgende Fehlermeldungen: Can't halt the core, Could not stop Cortex-M-Device! Please check the JTAG-Cable Als IDE wurde Keil µVersion 5 verwendet. Als Programmiergerät kam ein ST-Link/V2 zum Einsatz. Nachdem die Hardware ausgeschlossen werden konnte (durch einen Testcode, generiert von CubeMX) musste es an der Software liegen. Ohne Quarz lief der Controller ohne Probleme. Lösung Der Fehler lag in der stm32f4xx.h und in der stm32f4xx.c. Dort war als HSE ein 8 MHz-Quarz konfiguriert, dementsprechend waren die PLL-Parameter ebenfalls falsch konfiguriert. Für einen 25 MHz-Quarz auf einen STM32F446 muss folgendes modifiziert werden: stm32f4xx.h
1 | /*Quarz = 25 MHz, Einstellen bei HSE_VALUE */
|
2 | #elif defined (STM32F412xG) || defined(STM32F446xx)
|
3 | #if !defined (HSE_VALUE)
|
4 | #define HSE_VALUE ((uint32_t)25000000U) /*!< Value of the External oscillator in Hz dvo war 8000000 */ |
5 | #endif /* HSE_VALUE */ |
system_stm32f4xx.c
1 | #elif defined(STM32F412xG) || defined (STM32F446xx)
|
2 | #define PLL_M 25 // vorher 8
|
3 | |
4 | /*CLOCK FÜR EXTERNEN QUARZ
|
5 | |
6 | f_CPU = (f_HSE * PLL_N) / (PLL_M * PLL_P)
|
7 |
|
8 | = (25 * 360) / (25 * 2)
|
9 |
|
10 | = 180 MHz
|
11 | */
|
12 | #if defined(STM32F427_437xx) || defined(STM32F429_439xx) || defined(STM32F446xx) || defined(STM32F469_479xx)
|
13 | #define PLL_N 360 // vorher 336
|
14 | /* SYSCLK = PLL_VCO / PLL_P */
|
15 | #define PLL_P 2
|
16 | #endif /* STM32F427_437x || STM32F429_439xx || STM32F446xx || STM32F469_479xx */ |
Nun habe ich den o.a. Pfad in CMSIS-Schreibweise nachprogrammiert:
1 | /*Testprogramm*/
|
2 | #include "stm32f4xx.h" |
3 | #include "stm32f4xx_gpio.h" |
4 | #include "stm32f4xx_rcc.h" |
5 | |
6 | void RCC_config() |
7 | {
|
8 | /*Clock - Konfiguration */
|
9 | RCC->CR |= 0x01010000; /* Bit 16: HSE ON; Bit 24: PLL ON */ |
10 | |
11 | /* Bit 0 - 5 [PLLM= /16] = 010000
|
12 | Bit 6 - 14 [PLLN= *192] = 0110 0000 0
|
13 | Bit 15 - 17 [PLLP= /2] = 00 */
|
14 | RCC->PLLCFGR |= 0x00403010; |
15 | |
16 | /* SystemClock = PLLCLK
|
17 | AHB-Precaler = /1 */
|
18 | RCC-> CFGR |= 0x00000001; /*Bit 0 und 1: 01 HSE as System Clock*/ |
19 | |
20 | /* (25/16)MHz*(192/2)MHz=(150/4) = 37,5 MHz */
|
21 | RCC->AHB1ENR |= 0x00000001; /*Bit 1: Takt eingeschaltet für GPIOA*/ |
22 | }
|
23 | |
24 | void GPIO_config() |
25 | {
|
26 | /*Konfiguration GPIOA */
|
27 | GPIOA->MODER |= 0x01000000; /*PA12 als Ausgang*/ |
28 | }
|
29 | |
30 | int main() |
31 | {
|
32 | SystemInit(); |
33 | RCC_config(); |
34 | GPIO_config(); |
35 | |
36 | uint32_t count_max = 1000000; |
37 | volatile uint32_t count; |
38 | |
39 | while (1) |
40 | {
|
41 | GPIOA->BSRRL |= (1<<12); |
42 | for (count = 0; count < count_max; count++); |
43 | |
44 | GPIOA->BSRRH |= (1<<12); |
45 | for (count = 0; count < count_max; count++); |
46 | }
|
47 | }
|
Der Fehler lag einzig und allein an der falschen Einstellung des externen Quarzes und die dadurch resultierenden falschen PLL-Parameter in den o.a. Dateien. Deshalb lief der Code ohne Probleme auf dem Nucleoboard denn da ist kein externer Quarz verbaut und die PLL-Parameter stimmten für den internen 16 MHz-RC-Schwinger. Nop schrieb: > Meine Idee hier ist - wenn der XTAL nicht anschwingt, dann wird bei > SystemInit() das Umschalten auf den externen Quartz nicht gehen. Das war letztendlich der richtige Hinweis. Der Quarz war am schwingen, was ich auch mit dem Oszi nachkontrolliert habe, hatte aber den Fehler in der Beschaltung vermutet. Ich hoffe, es hilft denjenigen, der ebenfalls vor dieser Herausforderung steht (die Fehlersuche hat fast 2 Wochen gedauert). Vielen Dank an Euch allen! Gruß Daniel
:
Bearbeitet durch User
Bitte 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.