Probleme mit Linux (Kernel 4.9.0) und st-flash / texane

[Ralph S. (jjflash)]

Vielleicht kann mir jemand aus dem Forum bei einem ganz speziellen 
Problem helfen.

Ausgangssituation:

4 verschiedene Computer unter Linux (Porteus Live-Linux mit Kernel 
4.9.0) jeweils getestet mit 32 und 64 Bit und alle denselben Fehler !!!

Programmieradapter:
- original STMicro ST-LINK/V2
- Chinaclone ST-LINK v2 (mit Update von ST und ohne Update von ST)
- ST-Link eines Nucleo-Boards
- ST-Link eines Discoveryboards

Ursprünglich hat mal das nachfolgende Problem funktioniert und jetzt 
nachdem ich Daten, Installationen und eigene Programme zusammenfasse und 
dokumentiere funktioniert etwas erschreckenderweise nicht mehr, was vor 
3 oder 4 Jahren (und anderem Linuxkernel) funktioniert hatte.

Was funktioniert:

Flashen eines STM32F4xx funktioniert in jeglicher Konstellation 
problemlos (auch ein schwarzes STM32F407 Chinaboard).

Lange Zeit habe ich mit der Live-Version STM32F103 (Eigenbauboard und 
BluePill) nur mittels Bootloader geflasht, ebenso STM32F030.

Jetzt wollte ich (im Zuge des Zusammenfassens) eben auch per ST-Link V2 
flashen und das will nicht mehr, egal welche Version von st-flash 
(Texane) ich installiert habe (Versionen von 1.2 bis 1.5), es will 
einfach nicht.

Egal ob Cortex M0 oder M3.

In jedem Fall zeigt sich folgendes:

Anstehendes dauerndes Reset am Zielsystem und Flashversuch (mit 
Mass-Erase) ausgeführt (funktioniert natürlich nicht), Programmer von 
USB-Anschluss getrennt und wieder eingesteckt, erneuter Flashversuch => 
Programm wird korrekt geflasht.

Nur diese gerade eben beschriebene Vorgehensweise flasht mein Zielsystem 
(was für mich natürlich inakzeptabel ist).

Was ich nicht verstehe ist, dass dieselbe Konstellation (mit gleicher 
Zielhardware) mit einer älteren Linuxversion einmal funktioniert hatte 
(welche weiß ich nicht mehr, aber als nächsten Schritt werde ich ältere 
Live-Versionen mit älteren Kerels ausprobieren).

Kann sich jemand darauf einen Reim machen und hat vielleicht einen Tip? 
Ich hatte schon ein Programm geschrieben, der den angeschlossenen 
Programmer auf dem USB sucht und diesen gezielt zurück setzt was leider 
jedoch auch nicht funktioniert!

Gibt es ein alternatives Konsolenprogramm zum Flashen unter Linux (ein 
freies Open-Source) das ich nicht kenne und verwenden kann?

[Stefan F. (Gast)]

Du hättest wenigstens die Fehlermeldung zeigen sollen.

Ich habe mit dem Programm kein Probem. Was stellt denn dein Target mit 
der SWD Schnittstelle an. Deaktiviert es diese etwa (bei Cube-MX ist das 
der Default)?

Es könnte hilfreich sein, dein Programm so umzuschreiben, dass es nach 
dem Reset ein paar Sekunden wartet, bevor es die SWD Schnittstelle 
deaktiviert.

Alternativ kannst du den Boot0 Pin auf High setzen, um zu verhindern, 
dass die SWD Schnittstelle deaktiviert wird. Der Bootloader lässt sie 
aktiv.

> Gibt es ein alternatives Konsolenprogramm zum Flashen unter Linux

Das naheliegendste Programm wäre wohl der STM32 Cube Programmer. Für die 
GUI brauchst du Oracle JRE 8, das darin enthaltene Kommandozeilentool 
läuft auch mit anderen Java Versionen.

https://www.st.com/en/development-tools/stm32cubeprog.html

Das Kommandozeilentool ist 
/opt/STM32CubeProgrammer/bin/STM32_Programmer.sh

Für dieses Programm musst du allerdings wahrscheinlich die Firmware 
deines ST-Link aktualisieren. In der GUI sind dazu nur wenige 
offensichtliche Klicks nötig, geht auch mit dem China-Stick.

[jjflash (Gast)]

Stefanus F. schrieb:
> Ich habe mit dem Programm kein Probem. Was stellt denn dein Target mit
> der SWD Schnittstelle an. Deaktiviert es diese etwa (bei Cube-MX ist das
> der Default)?

Ich werkel mit libopencm3... für das Flashen mit texane st-flash habe 
ich jetzt ein "Bare-Metal" Version eines einfachen Blinkprogramms 
gemacht. Geht auch nicht.

Eine ältere Liveversion (mit Kernel 3.17.4) funktioniert lustigerweise 
problemlos (wobei ich irgendwie nicht so recht daran glaube, dass der 
Kernel schuld daran ist, sondern irgendein nachgeladener Treiber).

Stefanus F. schrieb:
> Alternativ kannst du den Boot0 Pin auf High setzen, um zu verhindern,
> dass die SWD Schnittstelle deaktiviert wird. Der Bootloader lässt sie
> aktiv.

Werde ich mit der Bluepill ausprobieren (bei meinem Eigenbauboard wird 
Booto und Boot1 über einen ATtiny13 gesteuert, der den Bootloadermodus 
aktiviert. Auf diesem Board sind SWDIO und SWCLK nur als gedachter 
Rettungsanker vorhanden.

Stefanus F. schrieb:
> Das naheliegendste Programm wäre wohl der STM32 Cube Programmer. Für die
> GUI brauchst du Oracle JRE 8, das darin enthaltene Kommandozeilentool
> läuft auch mit anderen Java Versionen.
>
> https://www.st.com/en/development-tools/stm32cubeprog.html
>
> Das Kommandozeilentool ist
> /opt/STM32CubeProgrammer/bin/STM32_Programmer.sh

Werde ich ausprobieren wobei ich die GUI nicht benötige. Allerdings muß 
ich gucken, ob der Cubeprogrammer freie Software ist, ansonsten hat es 
sich für mich da dann erledigt (weil ich das LiveLinux weitergeben 
möchte).

[Christopher J. (christopher_j23)]

Ralph S. schrieb:
> Gibt es ein alternatives Konsolenprogramm zum Flashen unter Linux (ein
> freies Open-Source) das ich nicht kenne und verwenden kann?

OpenOCD fungiert nicht nur als GDB-Server, sondern man kann damit auch 
flashen.

Warum es mit st-flash nicht geht ist schwer einzuschätzen. Hast du denn 
die ST-Link Firmware auf dem neuesten Stand? Falls nicht würde ich das 
als erstes mal aktualisieren.

Wenn du mal den genauen Konsolen-In- und Output von st-flash hier rein 
packst kann ich es mal bei mir versuchen zu reproduzieren (mit einem 4.x 
Kernel, wobei ich x nicht im Kopf habe aber es ist ein Arch-Linux, also 
auf jeden Fall ein aktueller Kernel)

[Harry L. (mysth)]

UDEV-Ruke in /etc/udev/rules.d vorhanden?

harry@hl-blue:/etc/udev/rules.d$ ls -l
insgesamt 36
-rw-rw-r-- 1 root  root    627 Apr 23 23:24 49-stlinkv2-1.rules
-rw-rw-r-- 1 root  root    503 Apr 23 23:24 49-stlinkv2.rules
-rw-rw-r-- 1 root  root    885 Apr 23 23:24 49-stlinkv3.rules
-rw-rw-r-- 1 root  root  18450 Apr 23 22:49 99-jlink.rules

Ich hab die passende Datei mal angehängt.

[Ralph S. (jjflash)]

Mein Makefile beherbergt direkt aufeinanderfolgende Aufrufe:

st-flash erase

st-flash write blinky.bin 0x8000000

Targetsystem: BluePill

Fehlermeldung 1 (ohne irgendetwas am BluePill gemacht zu haben):

root@porteus:/home/mcu/develop/stm32f103/blinky# make flash
st-flash erase
st-flash 1.5.1-25-gcf67780
2019-05-02T20:25:26 INFO common.c: Loading device parameters....
2019-05-02T20:25:26 WARN common.c: unknown chip id! 0x5fa0004

Ausgabe bei permanent betätigtem Reset:

root@porteus:/home/mcu/develop/stm32f103/blinky# make flash
st-flash erase
st-flash 1.5.1-25-gcf67780
2019-05-02T20:30:21 INFO common.c: Loading device parameters....
2019-05-02T20:30:21 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2019-05-02T20:30:21 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0 bytes (0 KiB) in pages of 1024 bytes
Mass erasing
st-flash write blinky.bin 0x8000000
st-flash 1.5.1-25-gcf67780
2019-05-02T20:30:21 INFO common.c: Loading device parameters....
2019-05-02T20:30:21 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2019-05-02T20:30:21 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0 bytes (0 KiB) in pages of 1024 bytes
Unknown memory region

Nach dieser Aktion mit dem permanent betätigtem Reset gelingt ein 
korrektes Flashen, wenn man Reset gedrückt hält und mit dem Aufruf den 
Reset loslässt:

root@porteus:/home/mcu/develop/stm32f103/blinky# make flash
st-flash erase
st-flash 1.5.1-25-gcf67780
2019-05-02T20:32:47 INFO common.c: Loading device parameters....
2019-05-02T20:32:47 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2019-05-02T20:32:47 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
Mass erasing
st-flash write blinky.bin 0x8000000
st-flash 1.5.1-25-gcf67780
2019-05-02T20:32:47 INFO common.c: Loading device parameters....
2019-05-02T20:32:47 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2019-05-02T20:32:47 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
2019-05-02T20:32:47 INFO common.c: Attempting to write 1504 (0x5e0) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08000400 erased
2019-05-02T20:32:47 INFO common.c: Finished erasing 2 pages of 1024 (0x400) bytes
2019-05-02T20:32:47 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2019-05-02T20:32:47 INFO flash_loader.c: Successfully loaded flash loader in sram
  2/2 pages written
2019-05-02T20:32:47 INFO common.c: Starting verification of write complete
2019-05-02T20:32:47 INFO common.c: Flash written and verified! jolly good!

Ist der Flashvorgang einmal gelungen, bewirkt ein Betätigen des Resets, 
dass anschließend ein Flashvorgang korrekt durchgeführt wird.

Dieses Verhalten ist bei allen benutzten Programmern (Chinaclone, 
Originaler ST-Link und ST-Link der Nucleo und Discoveyboards) gleich.

Leider besitze ich kein Nucleo oder Discovery-Board mit STM32F103, hier 
hätte ich dann ST-Link mit dem Nucleoboard noch getestet.

[Ralph S. (jjflash)]

Harry L. schrieb:
> UDEV-Ruke in /etc/udev/rules.d vorhanden?

Rules sind vorhanden:

root@porteus:/etc/udev/rules.d# ls -l
insgesamt 33
-rw-r--r-- 1 root root  120 Aug  3  2013 10-porteus-fstab-update.rules
-rw-r--r-- 1 root root  471 Apr 26 21:41 49-stlinkv1.rules
-rw-r--r-- 1 root root  654 Apr 26 21:41 49-stlinkv2-1.rules
-rw-r--r-- 1 root root  530 Apr 26 21:41 49-stlinkv2.rules
-rw-r--r-- 1 root root 1025 Apr 26 21:41 49-stlinkv3.rules
-rw-r--r-- 1 root root  295 Apr 25 17:11 70-persistent-cd.rules
-rw-r--r-- 1 root root  632 Apr 25 17:30 70-persistent-net.rules
-rw-r--r-- 1 root root  203 Apr 26 14:45 99-USBasp.rules
-rw-r--r-- 1 root root  256 Apr 25 17:13 net_rules_clean

Inhalt 49-stlinkv2.rules:

stm32 discovery boards, with onboard st/linkv2
# ie, STM32L, STM32F4.
# STM32VL has st/linkv1, which is quite different

SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="3748", \
    MODE:="0666", \
    SYMLINK+="stlinkv2_%n"

Inhalt lsusb:

root@porteus:/home/mcu/develop/stm32f103/blinky# lsusb
Bus 002 Device 003: ID 064e:f111 Suyin Corp. 
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 005: ID 0483:3748 STMicroelectronics ST-LINK/V2
Bus 007 Device 002: ID 046d:c03d Logitech, Inc. M-BT96a Pilot Optical Mouse
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 002: ID 0b05:1751 ASUSTek Computer, Inc. BT-253 Bluetooth Adapter
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Das heißt, die VID und PID des Programmers stimmt (natürlich) auch 
überein.

Abgesehen davon hab ich mich hierfür als root eingeloggt.

[G. K. (zumsel)]

Mach mal einen strace für den Gutfall und den Schlechtfall.

[Ralph S. (jjflash)]

Weil die Ausgaben von strace lang sind, im Anhang

[Dr. Sommer (Gast)]

Ralph S. schrieb:
> Ist der Flashvorgang einmal gelungen, bewirkt ein Betätigen des Resets,
> dass anschließend ein Flashvorgang korrekt durchgeführt wird.

Klingt nach dem Klassiker: Wenn das Programm auf dem uC die 
"WFI"-Instruktion benutzt, kann der ST-Link keine Verbindung aufbauen. 
Der J-Link hat damit kein Problem. Einer der Gründe warum sich diese 
Investition lohnt...

[Zock (Gast)]

Ralph S. schrieb:
> Weil die Ausgaben von strace lang sind, im Anhang

Da ist clone() drin bitte noch mal mit "-f"

[jjflash (Gast)]

Dr. Sommer schrieb:
> Wenn das Programm auf dem uC die
> "WFI"-Instruktion benutzt

Tut es aber nicht !

Abgesehen davon funktioniert das alles korrekt mit alter Liverversion 
und mit neuer eben nicht. Gerade habe ich Einen STM32F3xx probiert: Hier 
funktioniert es (genauso wie oben bereits geschrieben mit F4)

[Ralph S. (jjflash)]

Zock schrieb:
> Da ist clone() drin bitte noch mal mit "-f"

-f zeichnet auch die Kindprozesse auf, dann sind die Ausgaben noch 
länger (und clone sowieso).

Wie dem auch sei, strace mit Option -f

[Zock (Gast)]

Ralph S. schrieb:
> Wie dem auch sei, strace mit Option -f

Auf den ersten und zweiten Blick sehe ich da nix, man könnte mit 
wireshark noch mal den USB-Traffic sniffen, aber usb ist nicht mein 
Spezialgebiet, allerdings reicht da manchmal auch nachdenken und 
schlussfolgern.

Der Unterschied ist hier:

1399  timerfd_settime(8, TFD_TIMER_ABSTIME, {it_interval={0, 0}, 
it_value={228, 759814000}}, NULL) = 0
1399  ioctl(9, USBDEVFS_SUBMITURB, 0x84225f8) = 0
1399  poll([{fd=6, events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, 
events=POLLOUT}], 3, 60000) = 1 ([{fd=9, revents=POLLOUT}])
1399  ioctl(9, USBDEVFS_REAPURBNDELAY, 0xbf92563c) = 0
1399  timerfd_settime(8, 0, {it_interval={0, 0}, it_value={0, 0}}, NULL) 
= 0
1399  ioctl(9, USBDEVFS_REAPURBNDELAY, 0xbf92563c) = -1 EAGAIN (Resource 
temporarily unavailable)
1399  stat64("/etc/localtime", {st_mode=S_IFREG|0777, st_size=2335, 
...}) = 0
1399  write(2, "2019-05-02T21:49:58 ", 20) = 20
1399  write(2, "WARN common.c: ", 15)   = 15
1399  write(2, "unknown chip id! 0x5fa0004\n", 27) = 27
1399  write(7, "\1", 1)                 = 1
1399  close(9)                          = 0
1399  read(6, "\1", 1)                  = 1
1399  poll([{fd=6, events=POLLIN}, {fd=8, events=POLLIN}], 2, 0) = 0 
(Timeout)
1399  write(7, "\1", 1)                 = 1

----------------------------------------------------


1446  ioctl(9, USBDEVFS_SUBMITURB, 0x91035f8) = 0
1446  poll([{fd=6, events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, 
events=POLLOUT}], 3, 60000) = 1 ([{fd=9, revents=POLLOUT}])
1446  ioctl(9, USBDEVFS_REAPURBNDELAY, 0xbfe8990c) = 0
1446  timerfd_settime(8, 0, {it_interval={0, 0}, it_value={0, 0}}, NULL) 
= 0
1446  ioctl(9, USBDEVFS_REAPURBNDELAY, 0xbfe8990c) = -1 EAGAIN (Resource 
temporarily unavailable)
1446  stat64("/etc/localtime", {st_mode=S_IFREG|0777, st_size=2335, 
...}) = 0
1446  write(2, "2019-05-02T21:52:29 ", 20) = 20
1446  write(2, "INFO common.c: ", 15)   = 15
1446  write(2, "Device connected is: F1 Medium-d"..., 61) = 61
1446  stat64("/etc/localtime", {st_mode=S_IFREG|0777, st_size=2335, 
...}) = 0
1446  write(2, "2019-05-02T21:52:29 ", 20) = 20
1446  write(2, "INFO common.c: ", 15)   = 15
1446  write(2, "SRAM size: 0x5000 bytes (20 KiB)"..., 87) = 87
1446  rt_sigaction(SIGINT, {0x80494b0, [INT], SA_RESTART}, {SIG_DFL, [], 
0}, 8) = 0
1446  rt_sigaction(SIGTERM, {0x80494b0, [TERM], SA_RESTART}, {SIG_DFL, 
[], 0}, 8) = 0
1446  rt_sigaction(SIGSEGV, {0x80494b0, [SEGV], SA_RESTART}, {SIG_DFL, 
[], 0}, 8) = 0
1446  clock_gettime(CLOCK_MONOTONIC, {376, 129890934}) = 0

[jjflash (Gast)]

Mein Problem ist gefixed !

Das hier habe ich im Netz gefunden (aber den Link dazu finde ich nicht 
mehr).

Die Datei common.c um einen Eintrag ergänzen hat es gebracht:

diff --git a/src/common.c b/src/common.c
index ebc1f8e..448c83d 100644
--- a/src/common.c
+++ b/src/common.c
@@ -628,6 +628,9 @@ int stlink_load_device_params(stlink_t *sl) {

 int stlink_reset(stlink_t *sl) {
     DLOG("*** stlink_reset ***\n");
+
+    // Write SYSRESETREQ to NVIC AIRCR.
+    stlink_write_debug32(sl, 0xE000ED0C, (0x5FA << 16) | (1 << 2));
     return sl->backend->reset(sl);
 }

Warum auch immer das hier hilft, es hilft. Vielen Dank an alle die mir 
Ratschläge gegeben haben.