Flashen von Mikrocontroller plötzlich nicht mehr möglich

[Dominik H. (Gast)]

Hallo zusammen,

für ein Projekt verwenden wir ein STM32-P103 Board von Olimex. Dieses 
arbeitet mit dem STM32F103RBT6 ARM 32-Bit CORTEX M3 Mikrocontroller. Als 
IDE benutzen wir Eclipse mit GNU ARM Embedded GCC Toolchain und OpenOCD. 
Die Verbindung zum Board erfolgt über JTAG mit dem ARM-USB-TINY-H.

Bisher konnten wir unseren Code auf das Board flashen und debugen und es 
hat eigentlich soweit alles funktioniert. Um den Code zu testen haben 
wir dann das Board ein eine etwas komplexere Peripherie eingebunden 
wobei alles gut funktionierte.
Nachfolgend konnten wir jedoch nicht mehr auf den µC zugreifen und 
nichts mehr drauf flashen.

Softwareseitig haben wir nichts geändert. Wir haben es auch schon mit 
anderen Programmen (LED blinky) versucht, auch dies ist nicht mehr 
möglich.

Kann sich jemand erklären woher das kommen kann und weiß hier Abhilfe.
Wir stehen etwas unter Zeitdruck und würden uns sehr über Hilfe freuen.

MfG Dominik



Es kamen folgende Fehlermeldungen:

Error in final launch sequence
Failed to execute MI command:
load D:\\neuer_eclipse_workspace\\temp\\Debug\\temp.elf
Error message from debugger back end:
Error finishing flash operation
Failed to execute MI command:
load D:\\neuer_eclipse_workspace\\temp\\Debug\\temp.elf
Error message from debugger back end:
Error finishing flash operation
Error finishing flash operation

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

GNU MCU Eclipse 64-bit Open On-Chip Debugger 0.10.0+dev-00462-gdd1d90111 
(2019-01-18-11:42)
Licensed under GNU GPL v2
For bug reports, read
  http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "jtag". To 
override use 'transport select <transport>'.
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
none separate
cortex_m reset_config sysresetreq
Started by GNU MCU Eclipse
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED
Info : clock speed 1000 kHz
Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b 
(ARM Ltd.), part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32f1x.bs tap/device found: 0x16410041 (mfg: 0x020 
(STMicroelectronics), part: 0x6410, ver: 0x1)
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
Error: stm32f1x.cpu -- clearing lockup after double fault
Polling target stm32f1x.cpu failed, trying to reexamine
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : Listening on port 3333 for gdb connections
Info : accepting 'gdb' connection on tcp/3333
Info : device id = 0x20036410
Info : flash size = 128kbytes
Error: JTAG-DP STICKY ERROR
Error: Failed to read memory at 0xfffff000
Error: JTAG-DP STICKY ERROR
Error: Failed to read memory at 0xfffff000
Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b 
(ARM Ltd.), part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32f1x.bs tap/device found: 0x16410041 (mfg: 0x020 
(STMicroelectronics), part: 0x6410, ver: 0x1)
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
semihosting is enabled
Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b 
(ARM Ltd.), part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32f1x.bs tap/device found: 0x16410041 (mfg: 0x020 
(STMicroelectronics), part: 0x6410, ver: 0x1)
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc, semihosting
Info : Padding image section 0 at 0x08005db5 with 3 bytes
Error: Invalid ACK (7) in DAP response
Error: Failed to write memory at 0x200005f4
Error: error writing to flash at address 0x08000000 at offset 0x00000000
Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b 
(ARM Ltd.), part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32f1x.bs tap/device found: 0x16410041 (mfg: 0x020 
(STMicroelectronics), part: 0x6410, ver: 0x1)
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000220 msp: 0x20005000, semihosting
Info : dropped 'gdb' connection

[Christopher J. (christopher_j23)]

Dominik H. schrieb:
> Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED

Da liegt wohl der Hund begraben

Edit:
Daran liegt es wohl doch nicht unbedingt. Der Fehler kommt daher, dass 
OpenOCD zuerst die VCP-Schnittstelle des JTAG-Adapters benutzen will, 
was nicht geht.

[Dominik H. (Gast)]

Danke Christopher für deine schnelle Antwort.

Im Anhang haben wir noch die Konsolenausgabe beigefügt, als alles noch 
funktioniert hatte.

Da hatten wir auch schon den Fehler
>Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED

Neu dazugekommen sind (z.B.):
>Error: JTAG-DP STICKY ERROR
>Error: Invalid ACK (7) in DAP response

Allerdings konnten wir mit diesen Fehlermeldungen das Problem nicht 
lösen.

[W.S. (Gast)]

Dominik H. schrieb:
> unseren Code auf das Board flashen und debugen und es
> hat eigentlich soweit alles funktioniert...

..und jetzt glaubst du, alle anderen Forumsteilnehmer wühlen sich durch 
die von dir gepostete Flut von Meldungen, um herauszufinden, was da 
schief gelaufen sein könnte.

Gerade beim Benutzen von JTAG/SWD-Geschirre wird die Sache regelmäßig 
kompliziert, wenn's mal nicht klappt. Habt ihr evtl. die für SWD 
benutzten Pins umkonfiguriert? Oder findet das Programm den SWD-Adapter 
nicht? Oder sollte euer .elf File eigentlich einen anderen Namen haben? 
Oder..oder..oder..

Mein Rat wäre, das Ganze mal mit meinem STM32-Brennprogramm per 
eingebautem Bootlader zu probieren. Das kann man schrittweise tun, also 
zuerst testen, ob man den USB/Serial-Adapter überhaupt erreicht, dann 
testen, ob RxD, TxD /reset und boot vom Adapter her passend 
angeschlossen sind und dann den Bootlader nach seinen Specs abfragen. 
Dann programmieren.

So kann man sich Stück für Stück vorarbeiten - und braucht nicht zu 
jammern, wenn man auf den großen General-Programmier-Knopf gedrückt hat 
und lediglich ein spartanisches "geht nicht" zur Antwort gekriegt hat.

Ich sag's mal so: Wer ein Tool benutzt, der sollte auch erlernt haben, 
selbiges zu verstehen und zu beherrschen - und wenn es ein kompliziertes 
Tool wie JTAG/SWD ist, dann umso mehr, weil eben auch umso mehr schief 
gehen kann.

W.S.

[Christopher J. (christopher_j23)]

Dominik H. schrieb:
> Neu dazugekommen sind (z.B.):
>> Error: JTAG-DP STICKY ERROR
>> Error: Invalid ACK (7) in DAP response

Ich tippe mal, dass ihr die JTAG-Pins des F103 umkonfiguriert habt und 
somit, während das Programm läuft nicht mehr per JTAG auf die Hardware 
kommt. Lösung des Problems ist ein "connect under reset". Eventuell kann 
man da bei GnuMcuEclipse irgendwo ein Häkchen setzen. Ansonsten einfach 
den Resetbutton gedrückt halten, Flashvorgang starten und dann, wenn die 
Stelle mit dem JTAG-DP STICKY ERROR erscheinen würde, loslassen.

PS: Man kann auch die Bootpins so umjumpern, dass er in den 
UART-Bootloader startet. Da hat man dann die JTAG-Pins wieder verfügbar 
und man kann das Programm ganz normal per JTAG flashen.

[Dominik H. (Gast)]

Christopher J. schrieb:
> PS: Man kann auch die Bootpins so umjumpern, dass er in den
> UART-Bootloader startet. Da hat man dann die JTAG-Pins wieder verfügbar
> und man kann das Programm ganz normal per JTAG flashen.

Das hat unser Problem erst mal gelöst. Die Fehlermeldungen erscheinen 
zwar nach wie vor, aber wir können nun auf jeden Fall wieder Code auf 
den µC flashen.

Vielen Dank für die Antwort.

[Dr. Sommer (Gast)]

Benutzt ihr die "WFI"-Instruktion um den Prozessorkern schlafen zu 
legen? Darüber stolpern JTAG-Adapter zuverlässig. Man muss genau im 
richtigen Moment vor dem Flashen den "Reset"-Button betätigen.

Dominik H. schrieb:
> Wir stehen etwas unter Zeitdruck und würden uns sehr über Hilfe freuen.

Wenn's wichtig ist kauft man sich einen vernünftigen™ JWD/JTAG-Debugger 
wie den Segger J-Link. Der funktioniert einfach und spart graue Haare 
und Zeit. Das o.g. Problem mit "WFI" stört den auch nicht (sofern die 
Reset-Leitung korrekt verbunden ist; ggf. "RSetType 3" einstellen).

[Stefan F. (Gast)]

Dr. Sommer schrieb:
> Das o.g. Problem mit "WFI" stört den auch nicht (sofern die
> Reset-Leitung korrekt verbunden ist;

Das trifft auf ST-Link und Klone davon ebenso zu.

Kleiner Tipp: Baue in dein Programm eine Warteschleife (ca 1s) ein, 
bevor es zum ersten mal einen Sleep Modus nutzt oder die 
Programmierschnittstelle umkonfiguriert. Dann ist das Timing beim 
manuellen Drücken des Reset Buttons sehr viel entspannter.