STM32 ST-Link Pins auch für IOs

[Patrick B. (p51d)]

Hallo miteinander

Ich habe mal eine Frage: Ist es möglich, die SWDAT und SWCLK Pins eines 
SMT Controller auch als normale IOs zu nutzen? Wenn ja, wie müsste die 
Schaltung aussehen?
Bei den AVRs und PIC ging das ja ohne Probleme, man musste nur ein paar 
Widerstände hinzufügen.

Ich habe leider in den Datenblättern nichts derartiges gefunden.

Gruss
Patrick

[6A66 (Gast)]

Patrick B. schrieb:
> Hallo miteinander
>
> Ich habe mal eine Frage: Ist es möglich, die SWDAT und SWCLK Pins eines
> SMT Controller auch als normale IOs zu nutzen? Wenn ja, wie müsste die
> Schaltung aussehen?
> Bei den AVRs und PIC ging das ja ohne Probleme, man musste nur ein paar
> Widerstände hinzufügen.
>
> Ich habe leider in den Datenblättern nichts derartiges gefunden.
>
> Gruss
> Patrick

Nicht richtig gesucht?
Im Reference Manual schlägt die Suche nach SWCLK sofort auf die richtige 
Seite: 171, Table 37.

rgds

[Patrick B. (p51d)]

Das stimmt schon, aber so wie ich das interpretiere kann man den 
Debug-Port wählen. Was ist aber, wenn ich alle anderen Pins schon belegt 
habe?

[6A66 (Gast)]

Patrick B. schrieb:
> Das stimmt schon, aber so wie ich das interpretiere kann man den
> Debug-Port wählen. Was ist aber, wenn ich alle anderen Pins schon belegt
> habe?

Hallo Patrick,

die Tabelle schon mal genau angesehen?
Da steht "free" drinnen, das würde ich so interpretieren (hab's selbst 
noch nicht erprobt) dass der Port-Pin jetzt frei ist für die 
Port-Funktion.

Oder wie würdest Du das interpretieren?

rgds

[Martin K. (martinko)]

Hi,

Die Debug Pins sind genau so wie (fast) alle anderen Pins auch. Der 
einzige Unterschied ist der, dass die bereits beim Reset mit einer 
Alternate Funktion (ich glaube AF0 für SYS) vorbelegt werden. Ob Du die 
nun anders belegst ist Deine Sache. Dann geht nur der Debugger nicht 
mehr ;-)

Gruß Martin

[♪Geist (Gast)]

>Ob Du die
>nun anders belegst ist Deine Sache. Dann geht nur der Debugger nicht
>mehr ;-)
Jain, man muss schon aufpassen, dass man durch die Außenbeschaltung die 
Pins nicht blockiert z.B. dauerhaftes ziehen auf LOW durch irgendein 
Transistor.

[Patrick B. (p51d)]

Ich würde sie sowieso nur als Ausgang nützen, da kann auch etwas anderes 
nicht reinpfuschen. Der Debugger funktioniert dan schon noch, nur habe 
ich halt die Signale auf den Optokopplern, was aber auch nicht weiters 
schlimm ist, da am Ausgang nichts empfindliches angeschlossen ist beim 
Debuggen.

Soll man da noch irgendwelche Widerstände vorsehen?

[holger (Gast)]

>Ich würde sie sowieso nur als Ausgang nützen, da kann auch etwas anderes
>nicht reinpfuschen. Der Debugger funktioniert dan schon noch,

Wieso sollte der Debugger noch funktionieren?
Wenn du die Pins auf Ausgang schaltest ist aus die Maus.
Nix mehr debuggen bis zum nächsten Reset oder du schaltest
die Pins selber wieder auf AF.

[Patrick B. (p51d)]

holger schrieb:
> Nix mehr debuggen bis zum nächsten Reset oder du schaltest
> die Pins selber wieder auf AF.

Das kann ich mitlerweile so nicht bestätigen: Sobald ich die Pins von 
SWDat und SWClk als normale IO's einmal eingestellt habe, konnte ich den 
Prozesser weder debuggen noch neu programmieren. Ich musste über den 
UART Bootloader den Prozessor löschen. Erst dann war der J-Link und das 
ST-Link wieder brauchbar.

Ich habs jetzt so gelöst, dass diese Pins für LEDs verwendet werden und 
ich diese erst bei einem Release berücksichtige.

[Gerd E. (robberknight)]

Patrick B. schrieb:
> holger schrieb:
>> Nix mehr debuggen bis zum nächsten Reset oder du schaltest
>> die Pins selber wieder auf AF.
>
> Das kann ich mitlerweile so nicht bestätigen: Sobald ich die Pins von
> SWDat und SWClk als normale IO's einmal eingestellt habe, konnte ich den
> Prozesser weder debuggen noch neu programmieren. Ich musste über den
> UART Bootloader den Prozessor löschen. Erst dann war der J-Link und das
> ST-Link wieder brauchbar.

Huh, also selbst für nen paar Minuten komplett stromlos machen hilft 
nicht?

Das hieße ja, daß der sich das irgendwo im Flash merken muss, richtig? 
Damit hätte ich jetzt nicht gerechnet.

[Patrick B. (p51d)]

Ich hatte das Board etwa 10 Min vom Netzgerät getrennt, weil ich etwas 
anderes noch ändern musste (Drahtbrücken).
Ich kenn jetzt die Abläufe beim Programmieren nicht, aber ein 
Arbeitskollege hatte auch schon den Prozessor so verschossen: Nur hatte 
er anstelle die Pins zu verodern einfach jeweils ein Komma dazwischen 
gesetzt. Der Compiler hatte nicht gemeckert, aber dann lief weder das 
Programmieren/Debuggen noch das Programm. Musste ebenfalls über den 
UART-Bootloader gelöscht werden.

Es könnte ja sein, dass hier ev. die Dauer zwischen Reset-Flanke und 
Programmierung starten zu kurz ist oder was auch immer.
Ich werde aber meine Erkenntnisse und die Lösung ev. noch hier im 
Tutorial hinterlegen, damit nicht jeder so lange suchen muss. Beim 
Kollegen dauerte es 2 Tage bis wir (3 Personen) die passende Lösung 
hatten (obwohl es einen Aufwand von <2 Minuten wäre).

[Martin K. (martinko)]

Patrick B. schrieb:
> Ich hatte das Board etwa 10 Min vom Netzgerät getrennt, weil ich etwas
> anderes noch ändern musste (Drahtbrücken).
> Ich kenn jetzt die Abläufe beim Programmieren nicht, aber ein
> Arbeitskollege hatte auch schon den Prozessor so verschossen: Nur hatte
> er anstelle die Pins zu verodern einfach jeweils ein Komma dazwischen
> gesetzt. Der Compiler hatte nicht gemeckert, aber dann lief weder das
> Programmieren/Debuggen noch das Programm. Musste ebenfalls über den
> UART-Bootloader gelöscht werden.
>
> Es könnte ja sein, dass hier ev. die Dauer zwischen Reset-Flanke und
> Programmierung starten zu kurz ist oder was auch immer.
> Ich werde aber meine Erkenntnisse und die Lösung ev. noch hier im
> Tutorial hinterlegen, damit nicht jeder so lange suchen muss. Beim
> Kollegen dauerte es 2 Tage bis wir (3 Personen) die passende Lösung
> hatten (obwohl es einen Aufwand von <2 Minuten wäre).

hmm, ich wüsste nicht wo der STM32 das speichern sollte.
Ich habe mich auch schon aus versehen abgehängt nachdem ich die 
Stromspartipps von STM ausprobiert habe (nicht benutzte Ports als Analog 
Ein schalten). Der Debugger war natürlich nicht mehr benutzbar, aber neu 
flashen konnte ich immer und bis zur "Abhängroutine" single steppen ging 
auch. Ist/War vielleicht das Reset Signal vom JTAG/SWD nicht 
angeschlossen?

Gruß Martin

[Patrick B. (p51d)]

Das Resetsignal sowie alle anderen sind über einen Tac-Connect Stecker 
via Adapterplatine an den J-Link angeschlossen. Aus- und wieder 
einstellen brachte auch nichts.
Ev. war mein Programm schuld:
Ich erstelle globale Klassen, von denen später einige Funktionen 
(GPIO_Init....) aufgerufen werden. Kann mir also auch nicht vorstellen 
was hier schieff lief. Wie gesagt, kein Programmieren/Debuggen mehr 
möglich, nach dem einmaligen setzen der GPIOs.

Nachtrag (STM32F051K8U6):
Ich habe dieses Programm hier mit IAR und mit Atollic getestet, selbes 
Ergebniss. Beim ersten Programmieren hatte ich die GPIOA-Init Zeile 
nicht auskommentiert.

int main(void){
  GPIO_InitTypeDef GPIO_InitStructure;
  volatile uint32_t Delay = 100000;
  RCC_AHBPeriphClockCmd(RCC_AHBPeriph_GPIOA | RCC_AHBPeriph_GPIOB, ENABLE);
  GPIO_InitStructure.GPIO_Pin = GPIO_Pin_13 | GPIO_Pin_14;
  GPIO_InitStructure.GPIO_Mode = GPIO_Mode_OUT;
  GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
//  GPIO_Init(GPIOA, &GPIO_InitStructure);   

  GPIO_InitStructure.GPIO_Pin = GPIO_Pin_2;
  GPIO_Init(GPIOB, &GPIO_InitStructure);
  while(1){
    GPIOB->ODR ^= GPIO_Pin_2;
    while((Delay--) > 0);
    Delay = 100000;
  }
  return 0;
}

Anschliessend kamen diese Meldungen beim Debugger-Output:

Reading all registers
Removing breakpoint @ address 0x08000342, Size = 2
Read 4 bytes @ address 0x08000342 (Data = 0x607B4B1E)
Reading 64 bytes @ address 0x20001FC0
Starting target CPU...
ERROR: Can not read register 15 (R15) while CPU is running
...Target halted (PC = 0x00000000)
Reading all registers
ERROR: Can not read register 0 (R0) while CPU is running
ERROR: Can not read register 1 (R1) while CPU is running
ERROR: Can not read register 2 (R2) while CPU is running
.... u.s.w.

Beim Versuch obiges Programm zu brennen (mit Auskommentierung)

'Launching test.elf' has encountered a problem.

Failed to execute MI command:
target extended-remote localhost:2331

Error message from debugger back end:
Remote communication error. Target disonnected.: No error.

Zum "Wiederbeleben" habe ich folgendes gemacht:
- BOOT0 Pin auf Vcc
- Terminal (Baudrate: 9600, Databits: 8, Stopbits: 1, Parity: Even
- Kommandos: Config (0x7F), Extended Erase (0x44 0xBB), Mass Erase (0xFF 
0xFF 0x00)

25.07.2013 13:42:34.483 [TX] - 7F 
25.07.2013 13:42:34.499 [RX] - 79 
25.07.2013 13:42:35.812 [TX] - 44 BB 
25.07.2013 13:42:35.827 [RX] - 79 
25.07.2013 13:42:36.358 [TX] - FF FF 00 
25.07.2013 13:42:36.392 [RX] - 79

- BOOT0 Pin auf GND
Anschliessend konnte ich wieder normal Programmieren.

Gruss

[MichaK (Gast)]

Auf den Effekt mit dem Abhängen des SWD-Interfaces durch das eigene 
Programm bin ich auch hereingefallen.
Man muss allerdings nicht das Flash über den UART-Bootloader löschen. Es 
reicht, die BOOTx Pins so zu konfigurieren, dass der UART-Bootloader 
ausgeführt wird. Dann kann ein neues Programm über ST-Link geflashed 
werden.

Bei STM32F3DISCOVERY heißt das: BOOT0 auf 3V legen und man kann ein 
neues Programm reinflashen.

Gruß Micha