Kann mein Mikro nicht debuggen

-1

Seit ich meine Firmware-Version stm32cubef1 bis zu 1.6.0 hochgeladen habe, kann ich mein Board nicht mehr debuggen. Ich verwende SWSTM32 und ST-LINK/V2. Sobald ich die Taste „Play“ wie Taste, wenn ich versuche, es ein Windows öffnet sich zu stoppen, und es sagt:Kann mein Mikro nicht debuggen

"No source available for "dt_TPS()at 0x20000004"

wo dt_TPS einer meiner Variablen ist. im Fenster am unteren Rand der Seite las ich dies:

Open On-Chip Debugger 0.10.0-dev-00302-gc211ca5-dirty (2017-07-03-10:41) 
Licensed under GNU GPL v2 
For bug reports, read 
    http://openocd.org/doc/doxygen/bugs.html 
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD 
adapter speed: 1000 kHz 
adapter_nsrst_delay: 100 
srst_only separate srst_nogate srst_open_drain connect_assert_srst 
srst_only separate srst_nogate srst_open_drain connect_assert_srst 
Info : clock speed 1000 kHz 
Info : STLINK v2 JTAG v28 API v2 SWIM v6 VID 0x0483 PID 0x3748 
Info : vid/pid are not identical: 0x0483/0x374B 0x0483/0x3748 
Info : using stlink api v2 
Info : Target voltage: 3.239921 
Info : Unable to match requested speed 1000 kHz, using 950 kHz 
Info : STM32F105R8Tx.cpu: hardware has 6 breakpoints, 4 watchpoints 
Info : accepting 'gdb' connection on tcp/3333 
STM32F105R8Tx.cpu: target state: halted 
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x200001e0 msp: 0x20005000 
Info : device id = 0x10016418 
Info : flash size = 64kbytes 
STM32F105R8Tx.cpu: target state: halted 
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x200001e0 msp: 0x20005000 
STM32F105R8Tx.cpu: target state: halted 
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x200001e0 msp: 0x20005000 
Info : Padding image section 0 with 4 bytes 
STM32F105R8Tx.cpu: target state: halted 
target halted due to breakpoint, current mode: Thread 
xPSR: 0x61000000 pc: 0x2000003a msp: 0x20005000 
STM32F105R8Tx.cpu: target state: halted 
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x200001e0 msp: 0x20005000 
Error: address + size wrapped(0xffffffff, 0x00000004) 
Error: address + size wrapped(0xffffffff, 0x00000002) 
Error: address + size wrapped(0xffffffff, 0x00000004) 
Error: address + size wrapped(0xffffffff, 0x00000002)

Weitere Infos: meine aktuelle Toolchain ist: AC6 STM32 MCU GCC, aktuelle Builder: Gnu Builder machen und die Mikro verwendete ich ist STM32F105R8T6 jemand tut Wissen was los ist?

Quelle

2017-07-17 Sandro Sartoni

Fast vergessen: mein Mikro ist STM32F105R8 –

Sie sollten die Auslassung durch Bearbeiten der Frage beheben, nicht durch Hinzufügen eines Kommentars. Das heißt, das Ziel wird deutlich in der OCD-Ausgabe angegeben. Die Fehlermeldung weist darauf hin, dass nach einer _function_ 'dt_TPS' an einer RAM-Adresse gesucht wird. Hast du einen Clean & Build gemacht? Die Adresse deutet darauf hin, dass Sie den Boot-Modus auf SRAM statt auf Flash gesetzt haben - hat Ihr Board dafür einen Jumper? – Clifford

Sie scheinen Code aus SRAM auszuführen, statt zu blinken. Das ist ungewöhnlich und möglicherweise nicht beabsichtigt.

Der Prozessor wird beim Zurücksetzen von SRAM ausgeführt, wenn die Pins BOOT0 und BOOT1 beide hoch sind. Normalerweise lädt und führt man Code vom Flash aus (BOOT0 niedrig, BOOT1 ist nicht wichtig) - dein Board hat möglicherweise Jumper für die Auswahl des Boot-Modus.

Quelle

2017-07-17 22:15:28 Clifford

Hallo Clifford, danke für deine Antwort. In meiner Platine wählte ich einen Schalter, um den Boot-Modus zu wählen, und ich denke, dass es vom Blitz startet, denn wenn ich das Netzteil ausschalte und einschalte, kann ich mit dem Oszilloskop sehen, dass der MCU meinen Code ausführt. Ich habe meine Firmware-Version heruntergestuft und alles funktioniert jetzt wie vorher. Vielleicht ist es die neue Firmware-Version? Ich weiß nicht, aber ich denke, ich bleibe bei der älteren Version, bis ein neues Update verfügbar sein wird –

@SandroSartoni - die PC-Adressen in Ihrer Ausgabe gezeigt sind eindeutig im RAM, nicht Flash. Entweder hat die Ausführung dort begonnen, oder es wurde im Flash gestartet und in den Arbeitsspeicher übertragen, möglicherweise aufgrund von Stapelfehlern oder einer anderen Art von Runaway. –

Ockhams Rasierer schlägt vor, dass der Fehler in Ihrem Code enthalten ist. STM32Cube ist keine 'Firmware', sondern nur eine Bibliothek (von der Sie _ihre_ Firmware erstellen). Sie sollten debuggen, indem Sie einen Haltepunkt an der Reset-Adresse setzen, wenn es nicht zu main() kommt, und den Code schrittweise weiterleiten, um herauszufinden, wofür er sich aus dem RAM aufregt. Es ist verdächtig, da 0x02000004 der Reset-Vektor im SRAM-Bootmodus ist. – Clifford

Kann mein Mikro nicht debuggen

Antwort

Verwandte Themen