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
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.
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.
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.
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.
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.
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).
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.
Eine eigene Frage?
Dieser Thread ist über 7 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
Screenshot_Fehler.png
(97 KB)
fehlermeldung.png
(550 KB)
WhatsApp_Image_2019-07-31_at_10.31.38.jpeg
(140 KB)
