STM32F446ret6 JTAG-Problem

[Daniel V. (voda)]

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

[6a66 (Gast)]

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

[Uwe B. (Firma: TU Darmstadt) (uwebonnes)]

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"

[Daniel V. (voda)]

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

[Jim M. (turboj)]

Mach mal "[x] Download to Flash" an.

[Daniel V. (voda)]

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

[Nop (Gast)]

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.

[Daniel V. (voda)]

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:

#include "stm32f4xx.h"
#include "stm32f4xx_gpio.h"
#include "stm32f4xx_rcc.h"


int main()
{
  uint32_t count;
  GPIO_InitTypeDef GPIO_Struct;
  
  RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOA,ENABLE);
  
  GPIO_Struct.GPIO_Pin   = GPIO_Pin_12;  
  GPIO_Struct.GPIO_Mode  = GPIO_Mode_OUT;
  GPIO_Struct.GPIO_Speed = GPIO_Speed_2MHz;
  GPIO_Struct.GPIO_PuPd  = GPIO_PuPd_NOPULL;
  GPIO_Init(GPIOA, &GPIO_Struct);   
  
  while (1)
  {
   GPIO_SetBits(GPIOA, GPIO_Pin_12);
     for (count = 0; count < 3000000; count++);
  
   GPIO_ResetBits(GPIOA, GPIO_Pin_12);
     for (count = 0; count < 3000000; count++);
  }  
}

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

[Nop (Gast)]

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.

[Daniel V. (voda)]

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

[Nop (Gast)]

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.

[Daniel V. (voda)]

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:

 #define STM32F446xx

Gruß
Daniel

[dasrotemopped (Gast)]

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.

[Daniel V. (voda)]

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

[dasrotemopped (Gast)]

als Hinweis die JTAG / SWDIO Pins am uC zur Erinnerung.

Gruß,

dasrotemopped.

[Daniel V. (voda)]

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

[dasrotemopped (Gast)]

>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 ??

[Daniel V. (voda)]

dasrotemopped schrieb:
> ?? Resetschaltung ??

Hmmmm... Normalerweise wird diese durch einen Taster realisiert. Aus 
Platzgründen habe ich einen Jumper vorgesehen.

Gruß
Daniel

[Uwe B. (Firma: TU Darmstadt) (uwebonnes)]

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...

[Daniel V. (voda)]

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

[Nop (Gast)]

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.

[Daniel V. (voda)]

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

[Arc N. (arc)]

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

[Nop (Gast)]

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.

[Nop (Gast)]

Ich seh gerad, hattest Du ja schon geschrieben weiter oben, daß 15 auf 
Reset geht. Aber nicht durch die Jumper, sondern parallel dazu, oder?

[Daniel V. (voda)]

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

[Uwe B. (Firma: TU Darmstadt) (uwebonnes)]

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").

[Daniel V. (voda)]

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

[Jim M. (turboj)]

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.

[Daniel V. (voda)]

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

[Nop (Gast)]

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?

[Daniel V. (voda)]

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

[Nop (Gast)]

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.

[Daniel V. (voda)]

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

[Nop (Gast)]

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.

[Mehmet K. (mkmk)]

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?

[Daniel V. (voda)]

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

[Uwe B. (Firma: TU Darmstadt) (uwebonnes)]

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?

[Daniel V. (voda)]

Uwe B. schrieb:
> Im ST-Link Programm "Connect under reset" aktiviert?

Ja, in Keil, Target-Einstellungen. Siehe Bilder meiner vorigen Posts.

Gruß
Daniel

[Nop (Gast)]

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?

[Daniel V. (voda)]

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

[Nop (Gast)]

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.

[Daniel V. (voda)]

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

[Nop (Gast)]

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.

[Daniel V. (voda)]

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:

/*Testprogramm*/
#include "stm32f4xx.h"
#include "stm32f4xx_gpio.h"
#include "stm32f4xx_rcc.h"

#define D8 GPIO_Pin_12

int main()
{
  uint32_t count_max = 15000000;
  volatile uint32_t count;

  GPIO_InitTypeDef GPIO_Struct;
  
  RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOA,ENABLE);
  
  GPIO_Struct.GPIO_Pin   = D8;  
  GPIO_Struct.GPIO_Mode  = GPIO_Mode_OUT;
  GPIO_Struct.GPIO_Speed = GPIO_Speed_2MHz;
  GPIO_Struct.GPIO_PuPd  = GPIO_PuPd_NOPULL;
  GPIO_Init(GPIOA, &GPIO_Struct);   
  
  while (1)
        {
  GPIO_SetBits(GPIOA, D8);
  for (count = 0; count < count_max; count++);
  
  GPIO_ResetBits(GPIOA, D8);
  for (count = 0; count < count_max; count++);
  }
}

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

[Mehmet K. (mkmk)]

Daniel V. schrieb:
> Überbrücke ich den Widerstand mit einem Draht, komme ich gar nicht auf
> den Controller drauf.

Nicht überbrücken, sondern entfernen.

[Daniel V. (voda)]

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

[Mehmet K. (mkmk)]

Daniel V. schrieb:
> Wüsste ich jetzt nicht, was das für ein Unterschied machen soll.

Ueberbrücken -> 0R
Entfernen -> 30k interner Widerstand

[Daniel V. (voda)]

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

[Torsten S. (tse)]

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.

[Daniel V. (voda)]

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

[Daniel V. (voda)]

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

[Uwe B. (Firma: TU Darmstadt) (uwebonnes)]

Beachte auch das Errata ES2098
2.1.3 Full JTAG configuration without NJTRST pin cannot be used . . 10

[Nop (Gast)]

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?

[Daniel V. (voda)]

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

[Nop (Gast)]

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):

  else
  { /* If HSE fails to start-up, the application will have wrong clock
         configuration. User can add here some code to deal with this error */
  }

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.

[Daniel V. (voda)]

Da könnte ich aber trotzdem debuggen und die LED über das ODR-Register 
ansteuern, oder?

[Nop (Gast)]

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.

[Daniel V. (voda)]

Ja, der bleibt beim Booten hängen und das ist komisch. Die LED leuchtet 
daher dauerhaft.

[Daniel V. (voda)]

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

[Torsten S. (tse)]

Vielleicht liegt Dein Programm im falschen Speicher.

[Daniel V. (voda)]

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.

[Torsten S. (tse)]

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)

[Daniel V. (voda)]

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

[Torsten S. (tse)]

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?

[Daniel V. (voda)]

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.

[Daniel V. (voda)]

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.

[Daniel V. (voda)]

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...

[Daniel V. (voda)]

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

[Nop (Gast)]

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ß!

[Torsten S. (tse)]

Danke dass Du uns das wissen läßt.

[Daniel V. (voda)]

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.

[Daniel V. (voda)]

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

/*Quarz = 25 MHz, Einstellen bei HSE_VALUE  */
#elif defined (STM32F412xG) || defined(STM32F446xx)
 #if !defined  (HSE_VALUE) 
 #define HSE_VALUE    ((uint32_t)25000000U) /*!< Value of the External oscillator in Hz  dvo war 8000000 */
 #endif /* HSE_VALUE */

system_stm32f4xx.c

#elif defined(STM32F412xG) || defined (STM32F446xx)
 #define PLL_M      25        // vorher 8

/*CLOCK FÜR EXTERNEN QUARZ

f_CPU =  (f_HSE * PLL_N) / (PLL_M * PLL_P)
  
      =  (25 * 360) / (25 * 2)
  
      = 180 MHz
*/
#if defined(STM32F427_437xx) || defined(STM32F429_439xx) || defined(STM32F446xx) || defined(STM32F469_479xx)
#define PLL_N      360         // vorher 336  
/* SYSCLK = PLL_VCO / PLL_P */
#define PLL_P      2
#endif /* STM32F427_437x || STM32F429_439xx || STM32F446xx || STM32F469_479xx */

Nun habe ich den o.a. Pfad in CMSIS-Schreibweise nachprogrammiert:

/*Testprogramm*/
#include "stm32f4xx.h"
#include "stm32f4xx_gpio.h"
#include "stm32f4xx_rcc.h"

void RCC_config()
{
 /*Clock - Konfiguration */
 RCC->CR     |= 0x01010000;   /*  Bit 16: HSE ON; Bit 24: PLL ON */
   
 /* Bit  0 - 5  [PLLM= /16]  = 010000      
    Bit  6 - 14 [PLLN= *192] = 0110 0000 0 
    Bit 15 - 17 [PLLP= /2]   = 00           */
 RCC->PLLCFGR |= 0x00403010;
  
 /* SystemClock = PLLCLK 
    AHB-Precaler = /1    */
 RCC-> CFGR    |= 0x00000001;  /*Bit 0 und 1: 01 HSE as System Clock*/
  
 /* (25/16)MHz*(192/2)MHz=(150/4) = 37,5 MHz     */
 RCC->AHB1ENR  |= 0x00000001;   /*Bit 1: Takt eingeschaltet für GPIOA*/
}

void GPIO_config()
{
 /*Konfiguration GPIOA */
  GPIOA->MODER  |= 0x01000000;  /*PA12 als Ausgang*/
}

int main()
{
  SystemInit();
  RCC_config(); 
  GPIO_config();   
  
  uint32_t count_max = 1000000; 
  volatile uint32_t count;  
  
  while (1)
  {
  GPIOA->BSRRL |= (1<<12);
    for (count = 0; count < count_max; count++);
  
  GPIOA->BSRRH |= (1<<12);
    for (count = 0; count < count_max; count++);
  }
}

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