Title: "dies und das" zur Version vom 30.06.2017
Post by: dl8mby on 30. June 2017, 17:54:57
Hallo OM's,
hallo Andreas,
ich habe ein Problem mit der neuen FW-Version von heute.
Ich bin mir nicht sicher, ob bei Euren mchf's das Problen,
sofern es ein Problem ist, ebenso in Erscheinung tritt.
Nach dem Einschalten des TRX's schaltet sich dieser nach
einigen zig Sekunden (ca. zwei Minuten) von selber ab, auch
wenn man die Bedienelemente gerade benützt.
Die Betriebsspannung wird mit roter Schrift dargestellt, so daß
man den Eindruck bekommt, dass die Versorgungsspannung
zu gering sein könnte, was aber definitiv nicht der Fall ist.
(13V). Auch wenn ich den Spannungsmesser geeicht habe,
so daß die angezeigte Spannung mit der tatsächlichen
Versorgungsspannung übereinstimmt, schaltet der mchf sich
von selber ab.
Muss man irgendwas in der Konfiguration anpassen, damit
dieses Verhalten deaktiviert wird oder ist es noch ein Firmware
Problem?
Hat jemand dazu eine Idee oder einen Rat?
vy73
Markus
DL8MBY
|
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: OE3HKC on 30. June 2017, 18:34:55
Hallo Markus,
dann kontrolliere bitte die beiden Widerstände R13, R14 am RF-Board...
wenn die Schrift rot dargestellt wird,l erkennt der Prozessor trotz ausreichender Betriebsspannung eine zu niedrige...
an Pin 11 des Headers müssten zumindest bei 13 V UB ca 2,6 Volt anstehen...
viel Erfolg bei der Fehlersuche,
Helmut
PS: bei meinem MiniTRX musste ich im Standard-Menue diese Option auf OFF stellen, da ich ihn mit 8V betreibe und daher ständig abgeschaltet werde... ;-))
vy 73 |
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: dl8mby on 30. June 2017, 18:49:43
Hallo Helmut,
danke für Deine Antwort und den Hinweis.
Ich hatte aber bei der anderen FW, die ich davor
eingespielt habe dieses Verhalten nicht.
Ich spiele fast jede neue FW ein, die auf Andreas
Seite im OV I40 erscheint.
Dieses Verhalten habe ich bei meinen beiden Geräten,
was mich etwas stutzig macht.
Ich werde aber man am Pinheader die Spannung messen.
vy73
Markus
DL8MBY
|
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: OE3HKC on 30. June 2017, 18:59:55
Hallo Markus,
die firmware davor hatte dieses feature mit der Abschaltung bei Unterspannung ja noch nicht...
erst die vom 30.06.17...
viel Erfolg bei der Fehlersuche,
Helmut |
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: DB4PLE on 30. June 2017, 20:17:58
Hallo,
das mit der Abschaltung war mein Fehler! Es gibt jetzt eine Abschaltung, die bei zu geringer Spannungen abschaltet (im Standard-Menu ON/OFF, im Configurations Menu Spannung einstellen). Das Feature wurde von Eriks implementiert, leider habe ich dann noch ein bißchen verbessert und einen Fehler gemacht, der dazu führt, das bei den Leuten, die die Dailyfirmware einspielen, nicht der Defaultzustand aktiv (Abschaltung aus), sondern an und die Abschaltschwelle maximal hoch ist.
Wir fixen das im nächsten Daily Build. Sorry, aber danke fürs Testen ;) ! Zwischenzeitlich entweder Spannung reduzieren oder Funktion ausschalten.
73
Danilo
|
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: DB4PLE on 30. June 2017, 20:38:50
Hallo Helmut,
PS: bei meinem MiniTRX musste ich im Standard-Menue diese Option auf OFF stellen, da ich ihn mit 8V betreibe und daher ständig abgeschaltet werde... ;-))
|
|
natürlich wurde auch an Dich gedacht. Die Abschaltspannung ist einstellbar im Configuration Menu. Und zwar in dem aktuellen Daily bis runter zu 2V, in der nächsten bis 3V (niedrigere Inputspannung wird wohl niemand brauchen in nächster Zeit).
Es gibt ja Leute mit 4 Zellen, 3 Zellen, 2 Zellen LiPo, LiIo, oder mit Pb, oder, oder ....
73
Danilo
|
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: OE3HKC on 30. June 2017, 20:43:55
Danke für den Hinweis, Danilo..
an das Config-Menü hab ich nicht gedacht...
vy 73,
Helmut (der mit dem MiniTRX ;-)) |
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: dl8mby on 30. June 2017, 20:50:54
Hallo Danilo,
hallo Helmut,
hallo OM's,
danke für die Erklärung und für die
Hinweise zur Beseitigung des Verhaltens.
Wünsche Euch ein gute Nacht und ein
schönes Wochenende.
vy73
Markus
DL8MBY
|
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: dl8mby on 01. July 2017, 11:02:09
Hallo ON's,
hallo FW-Entwickler,
da bin ich schon wieder ;-)
Meine Meldung bezieht sich auf die FW-Version 2.5.1 vom 30.06.
Leider hat diese Version auch das Problem mit dem Hänger beim
Wählen des DSP-Peek Modes und der Verstellung der Peek-
Frequenz. Oft bei 685Hz von oben kommend bleibt der TRX
mit einem lauten dauernden Beep-Geräusch/Ton hängen.
Ich versuche mal ein Video von dem Verhalten zu machen und
werde hier einen Link einstellen, wenn es mir gelingt.
vy73
Markus
DL8MBY
|
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: DF8OE on 01. July 2017, 11:39:56
Hallo Markus,
es ist nicht so, dass wir Dir das nicht glauben. Insofern hilft ein Video nicht. Das Problem ist: Wir können es nicht reproduzieren bzw. nachvollziehen! Und etwas zu fixen, das man nicht nachvollziehen kann, ist sehr schwierig bis unmöglich.
Daher ist der erste Tipp immer:
Starte mal mit Defaultwerten und schau, ob das Problem dann immer noch da ist.
ist es dann nicht mehr da: ==> irgendeine Einstellung ist unverträglich
ist es dann immer noch da: ==> hohe Wahrscheinlichkeit, dass die Ursache irgendwo in der Hardware liegt.
vy 73
Andreas |
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: dl8mby on 01. July 2017, 11:58:03
Hallo Andreas,
hallo Entwickler,
nicht dass ich befürchte, dass Ihr mir nicht galaubt
war der Grund das Video zu erstellen, sondern dass
Ihr Euch ein Bild machen könnt, wie ich den TRX bediene.
Z.B. die Geschwindigkeit, mit der man die Knöpfe verstellt.
Mir ist übrigens aufgefallen, daß wenn ich M-Notch (665Hz)
einstelle und dann auf Peek stelle auch der TRX sich aufhängt.
Mir fehlt noch das Verständnis für die äußere Loop, die alle
Funktionen der mchf-FW kapselt um zu verstehen, wo der
Fehler auftritt. Ich werde dem aber nachgehen und falls ich
den Grund dafür vor Euch finde meinen Bericht hierzu
abliefern.
Im Augenblick bin ich nur reiner Beobachter, der sich
noch nicht die Mühe gemacht hat den Code darauf hin zu
analysieren.
Da der Entwicklungsstand sich derart rapide nach vorne
bewegt, war mir das bis dato noch nicht so wichtig und
ich habe angenommen, das das Phänomen sich irgendwann
von selbst erledigt.
Sollte ich zu ungeduldig sein, so bitte ich um Entschuldigung.
Anbei noch der versprochene Link.
www.dl8mby.de/mchf/mchf-peek-problem-fw-juli-2017.mts
vy73
Markus
DL8MBY
|
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: DF8OE on 01. July 2017, 12:37:20
Hallo Markus,
ich habe mir das Video angeschaut. Du benutzt anscheinend irgendeinen magnify-Mode: umindest ist der Strich in der Mitte. Mein mcHF steht zu 99,99% in "magnify = 1". Das könnte ein Problem sein. Welcher magnify-Mode?
Dein Waterfall-refresh ist "ungesund schnell". Meiner ist deutlich langsamer eingestellt. Wie schnell ist deiner eingestellt?
Und tritt der Fehler auch bei den default-Werten auf? Dann haben wir nicht dieses herumgefrage nach unterschiedlichen Einstellungen. Die default-Werte sind bei allen gleich. Bei so einem Fehler muss man total systematisch vorgehen. Also default-Werte laden, dann schreiben, was Du alles änderst, bevor Du den Peak ausprobierst, und dann stellen wir das nach.
Ich kann es nach wie vor nicht reproduzieren. Und weil das kein anderer hat ist auch noch nie danach gesucht worden und es wäre eben rein zufällig, wenn sich da was zum Guten ändert.
73
Andreas |
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: dl8mby on 01. July 2017, 13:19:22
Hallo Andreas,
kann man generell die Config-Werte irgendwie exportieren,
oder sie aus dem fw-mchf.old image, das auf USB geschrieben
wird extrahieren?
Du hast natürlich recht, wenn Du sagst, dass ich nicht
im Magnify=1 Mode bin.
Meine Einstellungen, zumindest einige, lauten wie folgt:
Standard Menu:
RX/TX Freq Xlate RX-12kHz
Configuration Menu:
Transmit Disable ON
DSP NR BufLen 256
DSP NR FIR NumTapes 128
DSP NR Post-AGC OFF
DSP Notch ConcRate 0
DSP Notch BufLen 128
DSP Notch FIRNumTap 112
Display Menu:
Spectrum Type WFALL
Spectrum Magnify x4
Spectrum Size Big
Spectrum Filter 4
Spectrum FFT Wind. Cosine
Wfall 1/Speed 6
Wfall Step Size 1
System Info:
EEP24xx1026/24CM01/128k [used]
CPU 419h
Flash Size (kB) 2048
Firmware 2.5.3
Bootloader 3.3.0
So ich hoffe das gibt jetzt etwas mehr Aufschluß über
meine Konfiguration.
Nicht auszuschließen, dass eine oder Andere Einstellung
dieses Problem mit verursacht.
Ich habe soeben den Reset Eprom Menupunkt ausgeführt.
Hatte einen weißen Bildschirm zur folge, aber ich konnte
den TRX mittels des PWR-Buttons normal ausschalten.
Habe den mchf auf 40m Band gestellt.
Menu DSP-Peek gewählt.
Voreinstellung steht auf 750Hz.
Runterdrehen der Peek-Frequenz und bei 720 ein Hänger.
Jetzt muss ich wohl doch meinen J-Link rausholen und mir
den Stack ansehen.
Habe das noch nicht bei einem mchf gemacht und bin mir
nicht sicher ob es mittels der Debugsnittstelle gehen wird.
Falls Ihr Vorschläge habt, wie am besten zu verfahren ist,
so bitte PN oder hier posten.
Danke!
vy73
Markus
DL8MBY
|
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: DF8OE on 01. July 2017, 13:26:11
Ein Reset EEPROM ist NICHT dasselbe wie ein Start mit Defaultwerten!!
Du startest mit Defaultwerten indem Du die Knöpfe F1+F3+F5 drückst und gedrückt hältst und dann den mcHF einschaltest. Solange gedrückt halten bis die Messages kommen.
Dann haben wir einen einheitlichen Stand der Einstellungen.
Wenn Du während des Testens NICHT mit langem Druck auf MENU speicherst und den mcHF nicht mit dem Powerbutton ausschaltest werden übrigens deine alten Einstellungen nicht überschrieben.
Bitte teste mit den Defaultwerten!
EDIT:
Nachdem ich deine DSP-Einstellungen gesehen habe (mit zu Berge stehenden Haaren) habeich gedacht, dass hier der hase im Pfeffer liegt. Es ist ja allgemein bekannt, dass die DSP-Dinge rund um den NR nicht wirklich funktionieren und stärkstens dazu neigen, den mcHF ins Nirwana zu schicken. Mit welchem Todesmut Du da fast alle werte nach oben geschraubt hast ::)... Ich habe es aber auch mal mit diesen Einstellungen probiert: kein Hängen, kein abstürzen. Auch nicht bei "superschnellem Wasserfall".
Ich versuche alle diese Dinge (auch wenn sie theoretisch schneller können) flach zu halten. Es kann der Stabilität nur nützen. Also steht mein Wasserfall speed auf 1/10. Aber wie gesagt: selbst mit deinen Einstellungen passiert nichts böses.
Und exportieren kann man die Einstellungen zur Zeit noch nicht.
vy 73
Andreas |
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: dl8mby on 01. July 2017, 13:56:17
Hallo Andreas,
danke für Deine Mühe und den Wagemut die
Einstellungen von mir zu probieren.
An sich hatte ich mit diesen Einstellungen keine
Probleme die letzten Monate gehabt.
Im Zuge der steigenden Lernkurve, was die Bedienung
des mchf's angeht stolpert man aber über Einstellungen,
in meinem Fall den DSP-Peek, die einen Interessieren
und man stellt fest dass es da noch Probleme gibt.
Ist halt so bei Projekten die stetig wachsen und adaptiert
werden.
Leider muss ich, wenn auch ungern, sagen, dass das Problem
trotz Deiner Anweisungen, die ich befolgt habe, immer
noch besteht.
Siehe Anhang.
Diesmal bei 655Hz, bei denen sich der mchf aufhängt.
Was mich wundert ist der NF-Ton, relativ laut, der dann
zu hören ist.
Nur ein Trennen von der Stromversorgung und abwarten
von einigen zig Sekunden ermöglicht das Wiedereinschalten.
So ich hoffe meinen Ruf nicht zu sehr ruiniert zu haben ;-)
Markus
DL8MBY |
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: DF8OE on 01. July 2017, 14:40:54
Dann muss ich Dir leider sagen, dass Du ein Hardwareproblem hast - und zwar eines der "schwierigen" Sorte. Denn keiner meine mcHFs hat bei den Defaulteinstellungen eine Fehlfunktion. Irgendwas in deiner Hardware ist anders als bei meinen mcHFs - und da sind welche mit parallel und mit SPI-LCD dabei. Einer hat auch eine Uhrenmod. Alles hat nicht zur Ursache, dass sich was bei "Peak" aufhängt.
Das wird schwer zu finden sein. Es wird keine völlige Unterbrechung und kein völliger Kurzschluss sein, sondern irgendwas mittelohmiges. Bei einer Firmware geht es "man gerade noch", bei einer anderen ist as Timing anders, und da kann sich dann über solch einen Mist-Hardwarefehler was einschleichen.
Ich drücke Dir die Daumen, dass Du die Ursache schnell findest!
vy 73
Andreas |
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: dl8mby on 01. July 2017, 15:34:00
Hallo Andreas,
möglich, dass Du recht hast, aber meine beiden TRXe
hatten das Peek-Problem.
Allerdings habe ich Deine Rückstell-Procedure auf die
Default-Werte erst bei einem der beiden mchf's gemacht.
Werde das gleich beim anderen versuchen.
Danke für die Erklärung.
vy73
Markus
DL8MBY |
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: DF8OE on 01. July 2017, 16:02:58
Tja: und bei mir hat es halt keiner. Entweder, es ist ein Hardwareproblem, oder wir machen intuitiv irgendwas, was jeder für selbstverständlich hält (und daher nicht weiter erläutert) anders...
EDIT:
Sollte das noch von Faktoren wie Eingangspegeln abhängen (evtl. auch noch frequenzabhängig), wird es richtig griffig. Ich habe es getestet einmal mit "realem 80m Empfang" und einmal mit "Testsignal injiziert mit S9".
vy 73
Andreas |
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: dl8mby on 01. July 2017, 16:59:38
Hallo Andreas,
meine letzten Test verliefen an einem 50Ohm Abschluß,
d.h. kein Signal. Ich dachte zuerst, daß eine Übersteuerung
des Audio-Pfades, wenn ich auf ein reales Signal im
Betrieb abgestimmt habe die Ursach sein könnte, weshalb
ich ab da nicht mehr an der Antenne bei der Fehlersuche
gearbeitet habe.
Jetzt bin ich gerade dabei meinen J-Link an den Debugport
anzuschließen, wobei es noch mit der Erkennung der CPU
nicht so recht geklappt.
Kann dazu jemand was sagen?
vy73
Markus
DL8MBY
Ich verwende GND, SWCK, SWIO und RST, also vier Leitungen.
In den Unterlagen von ST steht, dass man lediglich zwei
Leitungen brauchen würde, wobei GND wahrscheinlich
verschwiegen wird, weil selbstverständlich.
|
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: DF8OE on 01. July 2017, 17:05:58
Richtig. Du brauchst nur SWDIO und SWCLK. Reset würde ich weglassen.
Aber, wie gesagt:
Keiner meiner mcHFs zeigt das Verhalten und obwohl Du mit deinem Thread eine "Einladung zum Testen" versendet hast ist noch niemand darauf angesprungen...
vy 73
Andreas |
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: DB4PLE on 01. July 2017, 17:06:58
Hallo Markus,
tatsächlich brauchst Du 3 Leitungen -> RST wird nicht gebraucht. Zumindestens der ST-Link wickelt alles über die Leitungen SWDIO, SWDCLK (und GND) ab.
73
Danilo
|
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: dl8mby on 01. July 2017, 17:17:47
Hallo Andreas,
hallo Danilo,
mir ist noch nicht klar, ob ich den ST-Link oder den
J-Link oder beide dazu benützen kann, um zu sehen
wo die CPU steht, wenn sich der mchf aufhängt.
Ich dachte, wenn ich die Register auslesen könnte,
könnten wir schneller die Ursache des Problems
einkreisen.
Ich bin halt noch nicht ganz überzeugt, das es an der
Hardware liegt. Sonst hätte ich den Fehler ja identisch
bei meinen beiden mchf's machen müssen.
Ist zwar nicht auszuschließen, wäre aber schon ein
blöder Zufall.
Markus
PS: Mein J-Link Output
./JLinkExe -speed 12000 -if swd -device STM32F429VI
SEGGER J-Link Commander V5.02i ('?' for help)
Compiled Nov 3 2015 17:25:13
Info: Device "STM32F429VI" selected.
DLL version V5.02i, compiled Nov 3 2015 17:25:08
Firmware: J-Link ARM V8 compiled Nov 28 2014 13:44:46
Hardware: V8.00
S/N: XXXXXXXX
Feature(s): RDI,FlashDL,FlashBP,JFlash,GDBFULL
Emulator has Trace capability
VTarget = 0.588V
Can not connect to target.
Failed to identify target. Trying again with slow (4 kHz) speed.
Can not connect to target.
No device found at all. Selecting JTAG as default target interface.
J-Link>st
VTarget=1.087V
ITarget=0mA
TCK=0 TDI=0 TDO=0 TMS=0 TRES=1 TRST=0
Supported target interface speeds:
- 48 MHz/n, (n>=4). => 12000kHz, 9600kHz, 8000kHz, ...
- Adaptive clocking
J-Link>hwinfo
HWInfo[00] = Target power is disabled
HWInfo[02] = 0mA (ITarget)
HWInfo[03] = 0mA (ITargetPeak)
HWInfo[04] = 0mA (ITargetPeakOperation)
HWInfo[10] = 0ms (ITargetMaxTime0)
HWInfo[11] = 0ms (ITargetMaxTime1)
HWInfo[12] = 0ms (ITargetMaxTime2)
HWInfo[13] = 0x00000000
HWInfo[27] = 0x00000000
HWInfo[28] = 0x00000000
|
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: dl8mby on 01. July 2017, 17:24:02
Nachtrag,
bei der o.g. 3-Wire Verkabelung (SWIO, SWCLK, GND)
geht mir der mchf nach dem Booten in den "Input Elements Test".
???
Markus
|
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: DB4PLE on 01. July 2017, 17:24:35
Hallo Markus,
wenn es einfach nur um den aktuellen CPU Pointer geht:
ST-Link und ST-UTIL. Mit dem ST-UTIL kannst Du die Prozessorregister auslesen (Menu Target-MCU Core). Dann brauchen wir noch die passende Link map zu deiner Firmware, die muss Andreas beisteuern (es sei denn, du übersetzt selbst und flasht diese SW, dann brauchen wir deine map).
73
Danilo |
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: DB4PLE on 01. July 2017, 17:28:16
Hallo Markus,
Nachtrag,
bei der o.g. 3-Wire Verkabelung (SWIO, SWCLK, GND)
geht mir der mchf nach dem Booten in den "Input Elements Test".
???
Markus
|
|
Dann zählst Du falsch herum an P8. Einer der Pins (Pin 1) ist ja der TP_IRQ -> deswegen Button Test.
73
Danilo
|
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: dl8mby on 01. July 2017, 17:31:44
Hallo Danilo,
ich kann und habe bereits selber übersetzt, allerdings
verwende ich Eure FW, da ich die Sache nicht noch mehr
Verkomplizieren will.
Mein Compiler (Ver. 5.4.1) macht auch etwas großere
Binaries.
Ich muss auch den nano.spec Schalter im Linker
deaktivieren, damit der Linker durchläuft.
Danke für Eure Mühe.
Markus
>arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/arm-none-eabi/5/lto-wrapper
Target: arm-none-eabi
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --libdir=/usr/lib64 --libexecdir=/usr/lib64 --with-sysroot=/usr/arm-none-eabi --with-python-dir=share/arm-none-eabi/gcc/5 --with-pkgversion='openSUSE 5.4.0_20160622-3.19' --with-bugurl=https://bugs.opensuse.org/ --target=arm-none-eabi --with-multilib-list=armv6-m,armv7-m,armv7e-m,armv7-r --enable-multilib --enable-multiarch --enable-interwork --enable-plugins --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-libstdcxx-dual-abi --disable-libstdcxx-verbose --disable-nls --disable-shared --disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-gmp --with-mpfr --with-mpc --with-isl --with-libelf --enable-gnu-indirect-function --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --enable-languages=c,c++ --enable-gold --enable-target-optspace --enable-lto --without-headers --with-newlib --with-system-zlib
Thread model: single
gcc version 5.4.1 20160609 (release) [ARM/embedded-5-branch revision 237715] (openSUSE 5.4.0_20160622-3.19) |
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: dl8mby on 01. July 2017, 17:35:10
@Danilo,
die Verkabelung ist just die selbe, mit der ich den ST-Link
anschließe um die FW&BL zu flashen.
Nur das Kabel ist jetzt etwa 5cm länger, da der J-Link
etwas unhandlicher ist.
Markus |
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: dl8mby on 01. July 2017, 17:38:51
@Danilo,
so ist der J-Link angeschlossen.
Markus |
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: DB4PLE on 01. July 2017, 17:56:20
Hallo Markus,
ich habe keinerlei Erfahrung mit dem J-Link.
Außerdem lag ich falsch mit Pin1 von P8, ist TP_CS und nicht TP_IRQ. In jedem Fall kann man bei Keytest-Screen an der Zahl oben die initial gedrückten Tasten (die, die zum Start des Screens führen) ablesen. Deshalb ist diese Nummer wichtig um zu verstehen was jetzt los ist. Aber ich tippe immernoch auf Kabel. Es sind immer die Kabel.
73
Danilo
|
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: dl8mby on 01. July 2017, 18:05:46
Hallo Danilo,
leider ist es nicht der Fall, oder Gott sei Dank.
Durch das abnehmen meines Gehäuse-Bodenblechs
hat sich ein Key vekeilt, was ich nicht bemerkt habe,
deshalb dieer Einsprung in den Test nach dem Bootvorgang.
Jetzt bin ich zwar noch nicht mit der CPU verbunden,
aber ich sehe des normale GUI Bild mit Spektrum.
Jetzt werde ich versuchen deinen Vorschlag mit dem
ST-Link auszuprobieren.
Melde mich gleich wieder.
Markus
|
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: dl8mby on 01. July 2017, 18:10:50
Hallo Danilo,
Was sollte mir das sagen?
MCHF gibt den selben Ton aus, als wenn er sich aufgehängt
hätte.
Ein Ctrl-C beendet das Konzert aber.
Markus
st-util
2017-07-01T20:03:01 INFO src/stlink-usb.c: -- exit_dfu_mode
2017-07-01T20:03:01 INFO src/stlink-common.c: Loading device parameters....
2017-07-01T20:03:01 INFO src/stlink-common.c: Device connected is: F42x and F43x device, id 0x20016419
2017-07-01T20:03:01 INFO src/stlink-common.c: SRAM size: 0x40000 bytes (256 KiB), Flash: 0x200000 bytes (2048 KiB) in pages of 16384 bytes
2017-07-01T20:03:01 INFO gdbserver/gdb-server.c: Chip ID is 00000419, Core ID is 2ba01477.
2017-07-01T20:03:01 INFO gdbserver/gdb-server.c: Target voltage is 6268 mV.
2017-07-01T20:03:01 INFO gdbserver/gdb-server.c: Listening at *:4242... |
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: dl8mby on 01. July 2017, 18:13:22
@Danilo,
Mit dem Switch "--no-reset" läuft er weiter.
Was muss ich jetzt noch für Eingaben machen?
Markus
st-util --no-reset
2017-07-01T20:06:27 INFO src/stlink-common.c: Loading device parameters....
2017-07-01T20:06:27 INFO src/stlink-common.c: Device connected is: F42x and F43x device, id 0x20016419
2017-07-01T20:06:27 INFO src/stlink-common.c: SRAM size: 0x40000 bytes (256 KiB), Flash: 0x200000 bytes (2048 KiB) in pages of 16384 bytes
2017-07-01T20:06:27 INFO gdbserver/gdb-server.c: Chip ID is 00000419, Core ID is 2ba01477.
2017-07-01T20:06:27 INFO gdbserver/gdb-server.c: Target voltage is 6170 mV.
2017-07-01T20:06:27 INFO gdbserver/gdb-server.c: Listening at *:4242...
|
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: dl8mby on 01. July 2017, 18:15:00
@Danilo,
ich glaube jetzt muss ich mich mit der gdb dran connecten - richtig?
Markus
arm-none-eabi-gdb
GNU gdb (GNU Binutils; home:Tomcat42 / openSUSE_Leap_42.1) 7.10.50.20151217-cvs
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-pc-linux-gnu --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://bugs.opensuse.org/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) help
List of classes of commands:
aliases -- Aliases of other commands
breakpoints -- Making program stop at certain points
data -- Examining data
files -- Specifying and examining files
internals -- Maintenance commands
obscure -- Obscure features
running -- Running the program
stack -- Examining the stack
status -- Status inquiries
support -- Support facilities
tracepoints -- Tracing of program execution without stopping the program
user-defined -- User-defined commands
Type "help" followed by a class name for a list of commands in that class.
Type "help all" for the list of all commands.
Type "help" followed by command name for full documentation.
Type "apropos word" to search for commands related to "word".
Command name abbreviations are allowed if unambiguous.
|
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: dl8mby on 01. July 2017, 18:46:40
@Danilo,
2017-07-01T20:36:43 INFO gdbserver/gdb-server.c: Found 6 hw breakpoint registers
2017-07-01T20:36:43 INFO gdbserver/gdb-server.c: GDB connected.
...
zweites Fenster:
arm-none-eabi-gdb
GNU gdb (GNU Binutils; home:Tomcat42 / openSUSE_Leap_42.1) 7.10.50.20151217-cvs
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-pc-linux-gnu --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://bugs.opensuse.org/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) target remote localhost:4242
Remote debugging using localhost:4242
0x08038c16 in ?? ()
Jetzt bin ich wohl drin ;-)
(gdb) bt
#0 0x08038c16 in ?? ()
#1 0x0801917c in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) info all-registers
r0 0x2001fe06 537001478
r1 0x51 81
r2 0x0 0
r3 0x40003800 1073756160
r4 0x39e7 14823
r5 0x200051e0 536891872
r6 0x40003800 1073756160
r7 0x60020000 1610743808
r8 0x19 25
r9 0x20006668 536897128
r10 0x2000666c 536897132
r11 0x1d 29
r12 0x1 1
sp 0x2001fc88 0x2001fc88
lr 0x801917d 134320509
pc 0x8038c16 0x8038c16
xpsr 0x21010000 553713664
msp 0x2001fc88 0x2001fc88
psp 0x0 0x0
control 0x4 4 '\004'
faultmask 0x0 0 '\000'
basepri 0x0 0 '\000'
primask 0x0 0 '\000'
---Type <return> to continue, or q <return> to quit---
s0 1.20000005 (raw 0x3f99999a)
s1 19.2136078 (raw 0x4199b578)
s2 7.01248741 (raw 0x40e0664c)
s3 16.3655167 (raw 0x4182ec94)
s4 -13.0908833 (raw 0xc1517442)
s5 -21.803875 (raw 0xc1ae6e56)
s6 20.3660202 (raw 0x41a2ed9c)
s7 -51.7285957 (raw 0xc24eea15)
s8 28.446701 (raw 0x41e392d8)
s9 38.0424843 (raw 0x42182b81)
s10 44.0623856 (raw 0x42303fe2)
s11 0.30103001 (raw 0x3e9a209b)
s12 10.8000002 (raw 0x412ccccd)
s13 1.20000005 (raw 0x3f99999a)
s14 64 (raw 0x42800000)
s15 8.40779079e-45 (raw 0x00000006)
s16 31 (raw 0x41f80000)
s17 5000 (raw 0x459c4000)
s18 0 (raw 0x00000000)
s19 0 (raw 0x00000000)
s20 0 (raw 0x00000000)
s21 0 (raw 0x00000000)
s22 0 (raw 0x00000000)
---Type <return> to continue, or q <return> to quit---
s23 0 (raw 0x00000000)
s24 0 (raw 0x00000000)
s25 0 (raw 0x00000000)
s26 0 (raw 0x00000000)
s27 0 (raw 0x00000000)
s28 0 (raw 0x00000000)
s29 0 (raw 0x00000000)
s30 0 (raw 0x00000000)
s31 0 (raw 0x00000000)
fpscr 0x80000013 -2147483629
Markus
|
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: DB4PLE on 01. July 2017, 18:58:02
Hallo Markus,
Gratulation! Du bist drin ;D
Jetzt noch deine Map und wir können sehe, wo es hängt.
Alternative kannst Du auch ein mit -g gebautes Binary starten, dann kann der gdb sogar die Zeile ausspucken.
73
Danilo |
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: dl8mby on 01. July 2017, 19:08:52
Hallo Danilo,
ich kann zumindest mit einigen Befehlen den
Programmablauf anhalten und weiter laufen lassen.
Wie ich die Map einbinde muss ich noch herausbekommen.
Wie starte ich ein Programm, dass auf einer anderen HW-
Plattform läuft?
Wie übergebe ich den Parameter -g an das Programm auf dem
mchf?
Fragen über Fragen :-))
Markus
(gdb) continue
Continuing. |
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: DB4PLE on 01. July 2017, 19:42:27
Hallo Markus,
die Map kannst Du nicht einbinden, die muss man lesen (können). Ich kann das. Aber ich brauche die Map.
Ansonsten:
Im Makefile MACHFLAGS_F4 um "-g" ergänzen.
Dann make clean; make all und das resultierende Image flashen.
Mit dem gdb an die Stelle gehen, wo fw-mchf.elf liegt.
Problem erzeugen.
Nun kannst Du den gdb wie bisher starten
und dann das Binary in den gdb laden "file fw-mchf.elf"
Der gdb nennt jetzt nicht nur die Adresse sondern auch die zugehörige Codezeile.
73
Danilo
|
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: dl8mby on 01. July 2017, 19:56:27
Hallo Danilo,
kannst Du bitte "Mit dem gdb an die Stelle gehen, wo fw-mchf.elf liegt."
etwas genauer erläutern.
soll der arm-none-eabi-gdb erst gestartet werden, nachdem ich
ins Verzeichnis gewechselt bin, da wo das elf Image liegt?
So habe ich Dich verstanden - ist das richtig.
Markus |
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: DB4PLE on 01. July 2017, 19:58:01
Hallo Markus,
genau. Im Verzeichnis wo das elf liegt, soll der gdb gestartet werden.
73
Danilo |
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: dl8mby on 01. July 2017, 20:04:46
Danke,
werde ich morgen machen.
Jetzt muss ich meinen Akku laden, ist schon
den ganzen Tag in Betrieb.
Ich will potentialfrei an meinen Notebook arbeiten,
damit ich mir keinen Port brate ;-)
Danke und bis morgen.
Markus
DL8MBY
|
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: dl8mby on 02. July 2017, 05:42:45
Hallo Danilo,
hallo forum,
anbei mein erster Debug Versuch zum DSP Peek Mode Hänger,
der scheinbar bei niemanden sonst für Ärger sorgt.
Bitte meine englischen Kommentare zu entschuldigen,
aber das I40 Forum wird auch rege aus dem Ausland besucht.
@Danilo
ich hoffe es einigermaßen richtig gemacht zu haben.
Im Anhang mein MAP-File mit .txt Extention versehn.
Ich habe es im CR-LF Format convertiert, da ich nicht
weiß ob du mit Linux od. Windows arbeitest.
Markus
Debugging mchf FW 2.5.3 BL 3.3.0
================================
arm-none-eabi-gdb example.elf
(gdb) target extended-remote localhost:4242
Remote debugging using localhost:4242
UiDriver_MainHandler () at drivers/ui/ui_driver.c:6059
6059 if (ts.dvmode == true)
(gdb) bt
#0 UiDriver_MainHandler () at drivers/ui/ui_driver.c:6059
#1 mchfMain () at src/mchf_main.c:514
#2 0x080177ac in main () at basesw/mcHF/Src/main.c:142
(gdb) continue
Continuing.
switching to DSP-Mode Peek (Peek 750 is shown as default value)
^C
Program received signal SIGTRAP, Trace/breakpoint trap.
arm_fir_f32 (S=0x18, pSrc=0x10005a88 <fc+448>, pDst=0x7, blockSize=268464920)
at basesw/mcHF/Drivers/CMSIS/DSP_Lib/Source/FilteringFunctions/arm_fir_f32.c:682
682 acc1 += p1;
..................
during the editing of this file for documentation purpose the HW hangs without
future actions. A bt was created to see the program position.
..................
(gdb) bt
#0 arm_fir_f32 (S=0x18, pSrc=0x10005a88 <fc+448>, pDst=0x7, blockSize=268464920)
at basesw/mcHF/Drivers/CMSIS/DSP_Lib/Source/FilteringFunctions/arm_fir_f32.c:682
#1 0x0801d13a in AudioDriver_RxProcessor.lto_priv.464 (src=0x18, dst=0x10005a88 <fc+448>, blockSize=7)
at drivers/audio/audio_driver.c:3725
#2 0x0802a0c4 in AudioDriver_I2SCallback (ht=<optimized out>, size=<optimized out>, dst=<optimized out>, src=<optimized out>)
at drivers/audio/audio_driver.c:4896
#3 MchfHw_Codec_HandleBlock.lto_priv.257 (which=24) at drivers/audio/codec/mchf_hw_i2s.c:90
#4 0x0802d126 in HAL_DMA_IRQHandler (hdma=0x20007b00 <hdma_i2s3_ext_rx>)
at basesw/mcHF/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_dma.c:924
#5 0xffffffe8 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
..........................
traying to reanimate the program with a gdb continue program was not succesfull.
..........................
(gdb) continue
Continuing.
^C
Program received signal SIGTRAP, Trace/breakpoint trap.
0x08014550 in UiSpectrum_RedrawSpectrumDisplay () at drivers/ui/lcd/ui_spectrum.c:1276
1276 && (ts.menu_mode == false)
|
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: dl8mby on 02. July 2017, 05:58:54
Zweiter Versuch mit dem Gedanken,
dass eventuell der I2C-Bus zu langsam
konfiguriert war.
Leider selber Misserfolg.
Second debug attempt: Setting I2C1- and I2C2 Bus from 100kHz to 200kHz:
=======================================================================
(gdb) target extended-remote localhost:4242
Remote debugging using localhost:4242
0x080140e0 in UiDriver_MainHandler () at drivers/ui/ui_driver.c:6076
6076 if (ts.tx_stop_req == true || ts.ptt_req == true)
(gdb) continue
Continuing.
^C
Program received signal SIGTRAP, Trace/breakpoint trap.
0x0801cadc in AudioDriver_RxProcessor.lto_priv.464 (src=0xfffffc90, dst=0x200023f0 <ifalt>, blockSize=455)
at drivers/audio/audio_driver.c:4075
4075 audio_in_put_buffer(val);
(gdb) continue
Continuing.
^C
Program received signal SIGTRAP, Trace/breakpoint trap.
Error_Handler () at basesw/mcHF/Src/main.c:241
241 {
(gdb) bt
#0 Error_Handler () at basesw/mcHF/Src/main.c:241
#1 0xffffffe8 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) |
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: dl8mby on 02. July 2017, 06:30:50
Hallo Danilo,
mir ist noch nicht ganz klar, ob die o.g. Vergehensweise korrekt ist,
oder ob ich z.B. wie in der OpenOCD Duku die u.g. Befehlsfolge
verwenden muss um die FW zu debuggen.
Danke für sachdienliche Erläuterungen.
Markus
arm-none-eabi-gdb fw-mchf.elf
(gdb) target extended-remote localhost:4242
(gdb) monitor reset halt
(gdb) load
Loading section .text, size 0x6f1c8 lma 0x8010000
Loading section .ARM.exidx, size 0x8 lma 0x807f1c8
Loading section .data, size 0xe10 lma 0x807f1d0
Start address 0x8010000, load size 458720
Transfer rate: 16 KB/sec, 13900 bytes/write.
(gdb) continue |
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: dl8mby on 02. July 2017, 06:47:54
Hallo,
ich hoffe mein Input nervt Euch nicht schon,
aber die ersten Schritte beim Debuggen gestalten
sich doch etwas schwieriger wie gedacht.
Irgendwie gibt es mehrere Methoden, wie man ein
Programm im MC laden und via debug starten kann.
Bei der unten gezeigten Methode, wird der binäre
Code sofort neu geflashed, so daß er nicht explizit
vorher geladen werden muss.
Leider liefert mir diese Vorgehensweise keine Anzeige
am Bildschirm des mchf's, wenn ich im Debugger
continue nach dem load Befehl eingebe.
Markus
Window #1:
==========
st-util --no-reset
2017-07-02T08:30:30 INFO src/stlink-usb.c: -- exit_dfu_mode
2017-07-02T08:30:30 INFO src/stlink-common.c: Loading device parameters....
2017-07-02T08:30:30 INFO src/stlink-common.c: Device connected is: F42x and F43x device, id 0x20016419
2017-07-02T08:30:30 INFO src/stlink-common.c: SRAM size: 0x40000 bytes (256 KiB), Flash: 0x200000 bytes (2048 KiB) in pages of 16384 bytes
2017-07-02T08:30:30 INFO gdbserver/gdb-server.c: Chip ID is 00000419, Core ID is 2ba01477.
2017-07-02T08:30:30 INFO gdbserver/gdb-server.c: Target voltage is 6266 mV.
2017-07-02T08:30:30 INFO gdbserver/gdb-server.c: Listening at *:4242...
2017-07-02T08:31:00 INFO gdbserver/gdb-server.c: Found 6 hw breakpoint registers
2017-07-02T08:31:00 INFO gdbserver/gdb-server.c: GDB connected.
2017-07-02T08:31:10 INFO gdbserver/gdb-server.c: Found 6 hw breakpoint registers
2017-07-02T08:31:32 INFO src/stlink-common.c: Attempting to write 65536 (0x10000) bytes to stm32 address: 134283264 (0x8010000)
Flash page at addr: 0x08010000 erased
2017-07-02T08:31:33 INFO src/stlink-common.c: Finished erasing 1 pages of 65536 (0x10000) bytes
2017-07-02T08:31:33 INFO src/stlink-common.c: Starting Flash write for F2/F4/L4
2017-07-02T08:31:33 INFO src/stlink-common.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 32768
size: 32768
2017-07-02T08:31:34 INFO src/stlink-common.c: Starting verification of write complete
2017-07-02T08:31:36 INFO src/stlink-common.c: Flash written and verified! jolly good!
2017-07-02T08:31:36 INFO src/stlink-common.c: Attempting to write 131072 (0x20000) bytes to stm32 address: 134348800 (0x8020000)
Flash page at addr: 0x08020000 erased
2017-07-02T08:31:37 INFO src/stlink-common.c: Finished erasing 1 pages of 131072 (0x20000) bytes
2017-07-02T08:31:37 INFO src/stlink-common.c: Starting Flash write for F2/F4/L4
2017-07-02T08:31:37 INFO src/stlink-common.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 32768
size: 32768
size: 32768
size: 32768
2017-07-02T08:31:40 INFO src/stlink-common.c: Starting verification of write complete
2017-07-02T08:31:43 INFO src/stlink-common.c: Flash written and verified! jolly good!
2017-07-02T08:31:43 INFO src/stlink-common.c: Attempting to write 131072 (0x20000) bytes to stm32 address: 134479872 (0x8040000)
Flash page at addr: 0x08040000 erased
2017-07-02T08:31:44 INFO src/stlink-common.c: Finished erasing 1 pages of 131072 (0x20000) bytes
2017-07-02T08:31:44 INFO src/stlink-common.c: Starting Flash write for F2/F4/L4
2017-07-02T08:31:44 INFO src/stlink-common.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 32768
size: 32768
size: 32768
size: 32768
2017-07-02T08:31:47 INFO src/stlink-common.c: Starting verification of write complete
2017-07-02T08:31:50 INFO src/stlink-common.c: Flash written and verified! jolly good!
2017-07-02T08:31:50 INFO src/stlink-common.c: Attempting to write 131072 (0x20000) bytes to stm32 address: 134610944 (0x8060000)
Flash page at addr: 0x08060000 erased
2017-07-02T08:31:51 INFO src/stlink-common.c: Finished erasing 1 pages of 131072 (0x20000) bytes
2017-07-02T08:31:51 INFO src/stlink-common.c: Starting Flash write for F2/F4/L4
2017-07-02T08:31:51 INFO src/stlink-common.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 32768
size: 32768
size: 32768
size: 32768
2017-07-02T08:31:55 INFO src/stlink-common.c: Starting verification of write complete
2017-07-02T08:31:57 INFO src/stlink-common.c: Flash written and verified! jolly good!
Window #2:
==========
>arm-none-eabi-gdb fw-mchf.elf
GNU gdb (GNU Binutils; home:Tomcat42 / openSUSE_Leap_42.1) 7.10.50.20151217-cvs
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-pc-linux-gnu --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://bugs.opensuse.org/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from fw-mchf.elf...done.
(gdb) target extended-remote localhost:4242
Remote debugging using localhost:4242
Error_Handler () at basesw/mcHF/Src/main.c:241
241 {
(gdb) monitor reset halt
(gdb) load
Loading section .text, size 0x6f1c8 lma 0x8010000
Loading section .ARM.exidx, size 0x8 lma 0x807f1c8
Loading section .data, size 0xe10 lma 0x807f1d0
Start address 0x8010000, load size 458720
Transfer rate: 16 KB/sec, 13900 bytes/write. |
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: DB4PLE on 02. July 2017, 08:30:57
Hallo Markus,
noch gehts ;)
Und vorallem vorwärts.
Hallo,
ich hoffe mein Input nervt Euch nicht schon,
aber die ersten Schritte beim Debuggen gestalten
sich doch etwas schwieriger wie gedacht.
Irgendwie gibt es mehrere Methoden, wie man ein
Programm im MC laden und via debug starten kann.
Bei der unten gezeigten Methode, wird der binäre
Code sofort neu geflashed, so daß er nicht explizit
vorher geladen werden muss.
Leider liefert mir diese Vorgehensweise keine Anzeige
am Bildschirm des mchf's, wenn ich im Debugger
continue nach dem load Befehl eingebe.
|
|
Richtig, mit load wird direkt aus dem gdb geflasht. Ich weiß aber nicht, wie man genau jetzt starten sollte. Continue ist es nicht, eigentlich braucht es einen Reset.
Dein GDB Start teilt uns aber schon was mit:Type "apropos word" to search for commands related to "word"...
Reading symbols from fw-mchf.elf...done.
(gdb) target extended-remote localhost:4242
Remote debugging using localhost:4242
Error_Handler () at basesw/mcHF/Src/main.c:241
241 {
|
|
Der mcHF hängt im Error_Handler. Das ist merkwürdig, der wird eigentlich nur bei der Hardware-Initialisierung aufgerufen. Hast Du den gdb in dem Zustand verbunden, wo der Peak-Fehler aufgetreten ist?
73
Danilo
|
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: dl8mby on 02. July 2017, 10:21:58
Hallo Andreas,
hallo Danilo,
das Gute bei solchen Projekten ist, dass jeder von jedem
lernen kann. Mein kleiner Beitrag lautet zu DeinerFrage:
"Ich weiß aber nicht, wie man genau jetzt starten sollte."
(gdb) monitor reset halt
(gdb) thbreak main
Hardware assisted breakpoint 1 at 0x8016b92: file basesw/mcHF/Src/main.c, line 104.
(gdb) continue
Continuing.
Temporary breakpoint 1, HAL_Init () at basesw/mcHF/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal.c:189
189 HAL_NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_4);
(gdb) bt
#0 HAL_Init () at basesw/mcHF/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal.c:189
#1 main () at basesw/mcHF/Src/main.c:104
Bin wieder nach dem Frühstück mit der XYL am Debuggen.
Muss noch rausfinden, wie ich den breakpoint bei der Peek
Funktion setzen kann.
Markus
|
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: DB4PLE on 02. July 2017, 10:38:08
Hallo Markus,
theoretisch würde:
break functionsName
reichen.
Aber peak ist ja im eigentlichen keine isolierte Funktion.
Es gibt die Einstellung der Parameter (in ui_menu.c), das eigentliche Konfigurieren der Filter (audio_driver.c: AudioDriver_SetRxTxAudioProcessingAudioFilters(uint8_t dmod_mode) ), das Ausführen des Peak-Filters ist dann in AudioDriver_RxProcessor "versteckt".
Du kannst auch eine spezielle Zeile in einer Funktion mit einem Breakpoint versehen. Siehe gdb Manual.
"Einfacher" wäre die Nutzung von Eclipse zum Debugging, da ist das Setzen von Breakpoints trivial. Hast Du vermutlich aber nicht aufgesetzt.
73
Danilo
|
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: dl8mby on 02. July 2017, 10:59:38
Ja so ist es,
und deshalb kämpfe ich mich gerade durch das
remote debugging doc vom gdb.
Aller Anfang braucht halt etwas Aufwand.
Aber ich habe ja schon wieder einiges gelernt.
Danke für Eure/Deine Hilfe.
Markus |
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: dl8mby on 02. July 2017, 11:12:50
Meine Vorbereitung der Breakpoints
und der bt nach dem Peek Hänger.
Weiß aber noch nicht so richtig mit dem Output
umzugehen und kann nicht sagen, wie verläßlich dieser ist.
Markus
Program received signal SIGTRAP, Trace/breakpoint trap.
0x0802d07a in HAL_DMA_IRQHandler (hdma=0x20007b00 <hdma_i2s3_ext_rx>)
at basesw/mcHF/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_dma.c:780
780 if ((tmpisr & (DMA_FLAG_FEIF0_4 << hdma->StreamIndex)) != RESET)
(gdb) bt
#0 0x0802d07a in HAL_DMA_IRQHandler (hdma=0x20007b00 <hdma_i2s3_ext_rx>)
at basesw/mcHF/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_dma.c:780
#1 0x4d834c82 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) info registers
r0 0x20007b00 536902400
r1 0x200004d4 536872148
r2 0x800001 8388609
r3 0x0 0
r4 0x20007b00 536902400
r5 0x20020000 537001984
r6 0xa037a00 168000000
r7 0x0 0
r8 0x3 3
r9 0x2 2
r10 0xe000e100 -536813312
r11 0x10210000 270598144
r12 0x40023800 1073887232
sp 0x2001ff18 0x2001ff18
lr 0xfffffff9 -7
pc 0x802d07a 0x802d07a <HAL_DMA_IRQHandler+38>
xpsr 0x20002f74 536883060
msp 0x20002f74 0x20002f74 <hadc3+60>
psp 0x20002f74 0x20002f74 <hadc3+60>
control 0x4d 77 'M'
faultmask 0x83 131 '\203'
basepri 0x4c 76 'L'
primask 0x82 130 '\202' |
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: DB4PLE on 02. July 2017, 11:48:34
Hallo Markus,
das war ein bißchen "bad luck", aber es gibt einige Erkenntnisse:
a) Die Firmware läuft weiter, nach dem Hänger. Du hast nämlich den "Audio-Interrupt" unterbrochen, der kommt alle 0.666 ms.
b) Du musst schauen, wo er hängt, wenn er nicht im Interrupt ist: Also "continue" und nochmal anhalten. Bis du nicht im Interrupthandler landest.
73
Danilo
|
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: dl8mby on 02. July 2017, 13:17:09
Hallo Danilo,
mit den STLink Utils will es mir nicht auf CLI Ebene gelingen.
Ich habe mein Glück nochmals mit J-Link versucht und dessen
GDBServer zum Laufen gebracht.
Siehe Output, allerdings bin ich noch immer im Error_Handler
gelandet.
Kannst Du mit den J-Link output mehr anfangen?
Markus
Reading symbols from fw-mchf.elf...done.
(gdb) target remote localhost:2331
Remote debugging using localhost:2331
arm_fir_decimate_f32 (S=0xa0, pSrc=0x10002720 <adb+128>, pDst=0x10003840 <decimState+144>, blockSize=268449872)
at basesw/mcHF/Drivers/CMSIS/DSP_Lib/Source/FilteringFunctions/arm_fir_decimate_f32.c:267
267 acc2 += x2 * c0;
(gdb) continue
Continuing.
^C
Program received signal SIGTRAP, Trace/breakpoint trap.
0x0802e69a in arm_scale_f32 (pSrc=0x100029a0 <adb+768>, scale=10, pDst=0x100028a0 <adb+512>, blockSize=32)
at basesw/mcHF/Drivers/CMSIS/DSP_Lib/Source/BasicMathFunctions/arm_scale_f32.c:106
106 while(blkCnt > 0u)
(gdb) bt
#0 0x0802e69a in arm_scale_f32 (pSrc=0x100029a0 <adb+768>, scale=10, pDst=0x100028a0 <adb+512>, blockSize=32)
at basesw/mcHF/Drivers/CMSIS/DSP_Lib/Source/BasicMathFunctions/arm_scale_f32.c:106
#1 0x0801cb26 in AudioDriver_RxProcessor.lto_priv.464 (src=0x100029a0 <adb+768>, dst=0x100028a0 <adb+512>, blockSize=32)
at drivers/audio/audio_driver.c:4028
#2 0x0802a0c4 in AudioDriver_I2SCallback (ht=<optimized out>, size=<optimized out>, dst=<optimized out>, src=<optimized out>)
at drivers/audio/audio_driver.c:4896
#3 MchfHw_Codec_HandleBlock.lto_priv.257 (which=10656) at drivers/audio/codec/mchf_hw_i2s.c:90
#4 0x0802d14a in HAL_DMA_IRQHandler (hdma=0x20007b00 <hdma_i2s3_ext_rx>)
at basesw/mcHF/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_dma.c:845
#5 0xffffffe8 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Einsprung in den DSP-Peek Menu Mode:
================================
(gdb) cont
Continuing.
^C
Program received signal SIGTRAP, Trace/breakpoint trap.
0x08038c1c in UiLcdHy28_WriteDataOnly () at drivers/ui/lcd/ui_lcd_hy28.c:627
627 if(UiLcdHy28_SpiDisplayUsed())
(gdb) bt
#0 0x08038c1c in UiLcdHy28_WriteDataOnly () at drivers/ui/lcd/ui_lcd_hy28.c:627
#1 UiLcdHy28_BulkWrite.lto_priv.242 (pixel=0x2001fcf0, len=221) at drivers/ui/lcd/ui_lcd_hy28.c:729
#2 0x0801917c in UiLcdHy28_BulkPixel_PutBuffer (len=<optimized out>, pixel_buffer=<optimized out>)
at drivers/ui/lcd/ui_lcd_hy28.c:835
#3 UiSpectrum_RedrawWaterfall.part.2.lto_priv.545 () at drivers/ui/lcd/ui_spectrum.c:1146
#4 0x080158e2 in UiSpectrum_RedrawWaterfall () at drivers/ui/lcd/ui_spectrum.c:939
#5 UiSpectrum_RedrawSpectrumDisplay () at drivers/ui/lcd/ui_spectrum.c:1285
#6 UiDriver_MainHandler () at drivers/ui/ui_driver.c:6097
#7 mchfMain () at src/mchf_main.c:514
#8 0x080177ac in main () at basesw/mcHF/Src/main.c:142
(gdb) cont
Continuing.
Veränderung der Peek-Freq. und Hänger bei 655:
======================================
^C
Program received signal SIGTRAP, Trace/breakpoint trap.
Error_Handler () at basesw/mcHF/Src/main.c:241
241 {
(gdb) bt
#0 Error_Handler () at basesw/mcHF/Src/main.c:241
#1 0xffffffe8 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) info register
r0 0x3fd0fcbb 1070660795
r1 0x3ffa1f97 1073356695
r2 0x0 0
r3 0xff43f2e 267665198
r4 0x80685a0 134645152
r5 0x200003c4 536871876
r6 0x0 0
r7 0x20005324 536892196
r8 0x0 0
r9 0x100079d0 268466640
r10 0x8055ae2 134568674
r11 0x1000f390 268497808
r12 0x0 0
sp 0x2001fe18 0x2001fe18
lr 0xffffffe9 4294967273
pc 0x8039570 0x8039570 <Error_Handler>
xpsr 0x91010003 2432761859
MSP 0x2001fe18 537001496
PSP 0x0 0
PRIMASK 0x0 0
BASEPRI 0x0 0
FAULTMASK 0x0 0
CONTROL 0x0 0
|
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: DB4PLE on 02. July 2017, 13:27:47
Hallo Markus,
ich habe mal in meine map geschaut und siehe da: Error_Handler und HardFault_Handler liegen auf der gleichen Adresse (Gute Optimierung des Compilers, schwieriges Debugging: Beide haben identischen Code!).
Also wird es wohl einen HardFault geben. Dessen Ursache gilt es zu ergründen.
Also flink einen Breakpoint auf den Error_Handler gesetzt und weiter gehts.
Hier mal Lektüre (google! habe ich auch noch nicht gelesen):
http://www.freertos.org/Debugging-Hard-Faults-On-Cortex-M-Microcontrollers.html
https://www.mikrocontroller.net/topic/261691#2715774
Processor Manual sollte auch helfen können...
73
Danilo |
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: dl8mby on 02. July 2017, 14:14:01
Danke,
der Rest des Sonntags ist damit gesichert.
Markus |
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: dl8mby on 02. July 2017, 15:03:13
HalloDanilo,
so wie ich den Link zu den Hardfaults verstanden habe,
muss ich jetzt an geeigneter Stelle im MCHF FW-Code
mir die u.g. Hilfsfunktionen einbauen, um überhaupt
die Stelle zu finden, wo dieser Hard-Fault entsteht - richtig?
Wenn das Ereignis/Fault stattfindet, dann finden sich die
zugehörigen Stack-Variablen gesichert und zum Betrachten
via Debugger, in der "volatile uint32_t r0, r1, ..." Struktur.
Markus
/* The prototype shows it is a naked function - in effect this is just an
assembly function. */
static void HardFault_Handler( void ) __attribute__( ( naked ) );
/* The fault handler implementation calls a function called
prvGetRegistersFromStack(). */
static void HardFault_Handler(void)
{
__asm volatile
(
" tst lr, #4 \n"
" ite eq \n"
" mrseq r0, msp \n"
" mrsne r0, psp \n"
" ldr r1, [r0, #24] \n"
" ldr r2, handler2_address_const \n"
" bx r2 \n"
" handler2_address_const: .word prvGetRegistersFromStack \n"
);
}
void prvGetRegistersFromStack( uint32_t *pulFaultStackAddress )
{
/* These are volatile to try and prevent the compiler/linker optimising them
away as the variables never actually get used. If the debugger won't show the
values of the variables, make them global my moving their declaration outside
of this function. */
volatile uint32_t r0;
volatile uint32_t r1;
volatile uint32_t r2;
volatile uint32_t r3;
volatile uint32_t r12;
volatile uint32_t lr; /* Link register. */
volatile uint32_t pc; /* Program counter. */
volatile uint32_t psr;/* Program status register. */
r0 = pulFaultStackAddress[ 0 ];
r1 = pulFaultStackAddress[ 1 ];
r2 = pulFaultStackAddress[ 2 ];
r3 = pulFaultStackAddress[ 3 ];
r12 = pulFaultStackAddress[ 4 ];
lr = pulFaultStackAddress[ 5 ];
pc = pulFaultStackAddress[ 6 ];
psr = pulFaultStackAddress[ 7 ];
/* When the following line is hit, the variables contain the register values. */
for( ;; );
}
|
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: DB4PLE on 02. July 2017, 15:15:36
Hallo Markus,
musst Du nicht, du kannst Dir das auch direkt im Speicher (Stack) anschauen, aber mit dem Code ist das etwas bequemer.
Breakpoint auf die pul Funktion und wenn Du bei der for Schleife bist, sind alle Register in den lokalen Variablen. Wo bei uns eigentlich erstmal nur der "pc" Wert interessiert (und die dazugehörige Codezeile).
73
Danilo |
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: dl8mby on 02. July 2017, 15:16:56
Hallo Danilo,
ich schon wieder ;-)
Ich habe alles einfach zwanglos in die mchf_main.c reingewürgt,
ganz am Anfang.
Bin gespannt, was dabei rauskommt, wenn ich die FW uploade
und den TRX starte.
Bis zum nächsten Post ;-)
Markus
mchf_main.c ergänzt um die u.g. Code:
...
uchar wd_init_enabled = 0;
// catch and debug hard faults
/* The prototype shows it is a naked function -
in effect this is just an assembly function. */
static void HardFault_Handler( void ) __attribute__( ( naked ) );
/* The fault handler implementation calls a function called
prvGetRegistersFromStack(). */
static void HardFault_Handler(void)
{
__asm volatile
(
" tst lr, #4 \n"
" ite eq \n"
" mrseq r0, msp \n"
" mrsne r0, psp \n"
" ldr r1, [r0, #24] \n"
" ldr r2, handler2_address_const \n"
" bx r2 \n"
" handler2_address_const: .word prvGetRegistersFromStack \n"
);
}
void prvGetRegistersFromStack( uint32_t *pulFaultStackAddress )
{
/* These are volatile to try and prevent the compiler/linker optimising them
away as the variables never actually get used. If the debugger won't show the
values of the variables, make them global my moving their declaration outside
of this function. */
volatile uint32_t r0;
volatile uint32_t r1;
volatile uint32_t r2;
volatile uint32_t r3;
volatile uint32_t r12;
volatile uint32_t lr; /* Link register. */
volatile uint32_t pc; /* Program counter. */
volatile uint32_t psr;/* Program status register. */
r0 = pulFaultStackAddress[ 0 ];
r1 = pulFaultStackAddress[ 1 ];
r2 = pulFaultStackAddress[ 2 ];
r3 = pulFaultStackAddress[ 3 ];
r12 = pulFaultStackAddress[ 4 ];
lr = pulFaultStackAddress[ 5 ];
pc = pulFaultStackAddress[ 6 ];
psr = pulFaultStackAddress[ 7 ];
/* When the following line is hit, the variables contain the register values. */
for( ;; );
}
// end catch and debug hard faults
....
Compiler- und Linker-Lauf:
...mchfTRX/wrk/20170701/
>make -j2 all
fatal: Kein Git-Repository (oder irgendein Elternverzeichnis bis zum Einhängepunkt /)
Stoppe bei Dateisystemgrenze (GIT_DISCOVERY_ACROSS_FILESYSTEM nicht gesetzt).
[CC] src/mchf_main.o
src/mchf_main.c: In function 'prvGetRegistersFromStack':
src/mchf_main.c:115:19: warning: variable 'psr' set but not used [-Wunused-but-set-variable]
volatile uint32_t psr;/* Program status register. */
^
src/mchf_main.c:114:19: warning: variable 'pc' set but not used [-Wunused-but-set-variable]
volatile uint32_t pc; /* Program counter. */
^
src/mchf_main.c:113:19: warning: variable 'lr' set but not used [-Wunused-but-set-variable]
volatile uint32_t lr; /* Link register. */
^
src/mchf_main.c:112:19: warning: variable 'r12' set but not used [-Wunused-but-set-variable]
volatile uint32_t r12;
^
src/mchf_main.c:111:19: warning: variable 'r3' set but not used [-Wunused-but-set-variable]
volatile uint32_t r3;
^
src/mchf_main.c:110:19: warning: variable 'r2' set but not used [-Wunused-but-set-variable]
volatile uint32_t r2;
^
src/mchf_main.c:109:19: warning: variable 'r1' set but not used [-Wunused-but-set-variable]
volatile uint32_t r1;
^
src/mchf_main.c:108:19: warning: variable 'r0' set but not used [-Wunused-but-set-variable]
volatile uint32_t r0;
^
[LD] fw-mchf.elf
[BIN] fw-mchf.hex
[OBJC] fw-mchf.bin
text data bss dec hex filename
text data bss dec hex filename
455120 3600 92532 551252 86954 fw-mchf.elf
455120 3600 92532 551252 86954 fw-mchf.elf
copy from `fw-mchf.elf' [elf32-littlearm] to `fw-mchf.hex' [ihex]
copy from `fw-mchf.elf' [elf32-littlearm] to `fw-mchf.bin' [binary]
[H2D] fw-mchf.dfu
text data bss dec hex filename
0 458720 0 458720 6ffe0 fw-mchf.hex
./support/hex2dfu/hex2dfu.py fw-mchf.hex fw-mchf.dfu
Loading fw-mchf.hex...
Start: 0x08010000
End : 0x0807ffdf
Saving fw-mchf.dfu...
Device ID: 0x0483:0xdf11
Target name: application
# compile the ARM-executables .bin / .elf and .dfu for mcHF SDR TRx, generate .map
using \c
arm-none-eabi-gcc (openSUSE 5.4.0_20160622-3.19) 5.4.1 20160609 (release) [ARM/embedded-5-branch revision 237715]
rm fw-mchf.hex
|
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: DB4PLE on 02. July 2017, 15:19:19
Hallo Markus,
passt schon. Der Compiler kann ja nicht wissen, dass wir dann mit dem Debugger in die Register-Variablen reinschauen werden.
73
Danilo |
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: dl8mby on 02. July 2017, 16:06:11
Noch eine Frage,
ich sehe zwar die Funktion prvGetRegistersFromStack im main
Object File, nicht aber in der fw-mchf.map, was mich etwas
irritiert.
Muss ich sie mit extern in die mchf_main.h einbauen,
dass sie sichtbar wird?
Man kann doch auch lokale Funktionen debuggen und
auch die haben Debug-Symbole, obwohl global nicht sichtbar.
Markus
>strings mchf_main.o | grep prvGetRegistersFromStack
prvGetRegistersFromStack
.gnu.lto_prvGetRegistersFromStack.5e30b3ce4f097606
>strings fw-mchf.map | grep prvGetRegistersFromStack
markus@HP87:~/mchfTRX/wrk/20170701
|
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: dl8mby on 02. July 2017, 16:17:51
Frage und Ursache selber beantwortet/behoben.
Vergessen in der mchfmain Fkt den Aufruf zu platzieren.
// cetch and debug hard-faults
HardFault_Handler();
Nun passt es:
>strings fw-mchf.map | grep HardFault_Handler
0x000000000803958c HardFault_Handler
Und es geht weiter ;-)
Markus |
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: DB4PLE on 02. July 2017, 16:23:04
Hallo Markus!
ACHTUNG: Das funktioniert so nicht.
EDIT:
Warum nicht:
Der HardFault_Handler in die Interrupt-Tabelle eingetragen werden.
D.h. dein HardFault_Handler muss vom Linker als der richtige Eintrag für diese Tabelle erkannt werden.
Dazu muss das static vor dem HardFault_Handler entfernen, dann sieht der Linker deine Funktion als den richtigen HardFault_Handler an.
Selbst den HardFault_Handler aufrufen geht nicht/darf man nicht.
73
Danilo
|
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: dl8mby on 02. July 2017, 16:36:28
Hallo Danilo,
danke!
Das erklärt wohl meinen Linker Fehler, den ich prompt bekommen
habe.
/tmp/ccWMTk9W.ltrans1.ltrans.o: In function `HardFault_Handler':
~/mchfTRX/wrk/20170701/src/mchf_main.c:89: undefined reference to `prvGetRegistersFromStack'
collect2: error: ld returned 1 exit status
Makefile:247: recipe for target 'fw-mchf.elf' failed
make: *** [fw-mchf.elf] Error 1
Werde es entsprechend ausbessern.
Markus
|
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: dl8mby on 02. July 2017, 16:43:37
Leider sind beim Linken noch Probleme aufgetreten:
[LD] fw-mchf.elf
basesw/mcHF/Src/stm32f4xx_it.o (symbol from plugin): In function `OTG_HS_IRQHandler':
(.text+0x0): multiple definition of `HardFault_Handler'
src/mchf_main.o (symbol from plugin):(.text+0x0): first defined here
basesw/mcHF/Src/stm32f4xx_it.c:69:6: error: 'HardFault_Handler' has already been defined
void HardFault_Handler(void)
^
src/mchf_main.c:87:6: note: previously defined here
void HardFault_Handler(void)
^
lto1: fatal error: errors during merging of translation units
compilation terminated.
lto-wrapper: fatal error: /usr/bin/arm-none-eabi-g++ returned 1 exit status
compilation terminated.
/usr/lib64/gcc/arm-none-eabi/5/../../../../arm-none-eabi/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
Makefile:247: recipe for target 'fw-mchf.elf' failed
make: *** [fw-mchf.elf] Error 1
Markus
|
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: DF8OE on 02. July 2017, 16:46:35
Das Ganze hat auch für mich (nur vom Mitlesen) einen hohen Lernfaktor. Ich tippe aber, dass es sich NICHT um einen "HardFault" handelt. Nullreferenzierte Zeiger etc. kommen entweder bei allen vor oder bei keinem. Und da alle meine mcHFs (und scheinbar auch die aller anderen OMs) eben diesen Fehler nicht zeigen, vermute ich eine andere Ursache. Und ich bin gespannt, ob man die mit diesem "Waffenarsenal" ermitteln kann.
Ich lese begeistert mit!
Viel Erfolg
vy 73
Andreas |
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: DF8OE on 02. July 2017, 16:48:12
Nimm mal deine Definition aus mchf_main.c:87:6 raus. Die Funktion ist bereits definiert.
EDIT:
Bedeutet, dass Du den Code von der main.c in die andere Datei schieben musst. Oder dort die Codeteile ausdokumentieren.
vy 73
Andreas |
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: dl8mby on 02. July 2017, 16:53:26
Hallo Andreas,
hallo Danilo,
habe es gerade selber gesehen und
in dieser Datei die Ergänzung, die den
Registersatz sichert eingebaut.
Hoffe, dass das Compilieren jetzt klappt.
Markus
../basesw/mcHF/Src/stm32f4xx_it.c
void HardFault_Handler(void)
{
/* USER CODE BEGIN HardFault_IRQn 0 */
__asm volatile
(
" tst lr, #4 \n"
" ite eq \n"
" mrseq r0, msp \n"
" mrsne r0, psp \n"
" ldr r1, [r0, #24] \n"
" ldr r2, handler2_address_const \n"
" bx r2 \n"
" handler2_address_const: .word prvGetRegistersFromStack \n"
);
/* USER CODE END HardFault_IRQn 0 */
while (1)
{
}
/* USER CODE BEGIN HardFault_IRQn 1 */
/* USER CODE END HardFault_IRQn 1 */
} |
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: DB4PLE on 02. July 2017, 17:06:11
Hallo Markus,
ja, Du musst natürlich den "alten" HardFault_Handler aus der stm32f7xx_it.c rauswerfen.
Aber das ist ein gutes Zeichen, denn dass heißt, der will den von Dir eingefügten Handler auch verwenden.
@Andreas: Es muss ein HardFault sein (alles andere wäre noch unlogischer). Wenn es dass nicht ist, dann werden wir viel gelernt haben und weitersuchen...
73
Danilo |
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: dl8mby on 02. July 2017, 17:14:38
Hallo Danilo,
jetzt brauche ich noch einen Tipp, wie ich den XXX-Teil
zu nennen habe, damit der Linker in der stm32f4xx_it.c
die Referent auf die prvGetRegistersFromStack
Funktion findet.
Oder gehört dies nicht an diese Stelle.
extern habe ich schon versucht, hat aber nicht geklappt.
extern void prvGetRegistersFromStack( uint32_t *pulFaultStackAddress ) eine Zeile vor den HardFault_Handler
in der stm32f4xx_it.c deklariert, leider kein Erfolg.
stm32f4xx_it.c
.....
/* External variables --------------------------------------------------------*/
extern PCD_HandleTypeDef hpcd_USB_OTG_FS;
extern HCD_HandleTypeDef hhcd_USB_OTG_HS;
extern DMA_HandleTypeDef hdma_spi3_tx;
extern DMA_HandleTypeDef hdma_i2s3_ext_rx;
extern DMA_HandleTypeDef hdma_spi2_tx;
extern XXX_HandleTypeDef prvGetRegistersFromStack;
....
/**
* @brief This function handles Hard fault interrupt.
*/
void HardFault_Handler(void)
{
/* USER CODE BEGIN HardFault_IRQn 0 */
__asm volatile
(
" tst lr, #4 \n"
" ite eq \n"
" mrseq r0, msp \n"
" mrsne r0, psp \n"
" ldr r1, [r0, #24] \n"
" ldr r2, handler2_address_const \n"
" bx r2 \n"
" handler2_address_const: .word prvGetRegistersFromStack \n"
);
/* USER CODE END HardFault_IRQn 0 */
while (1)
{
}
/* USER CODE BEGIN HardFault_IRQn 1 */
/* USER CODE END HardFault_IRQn 1 */
}
oder meine erste Variante:
stm32f4xx_it.c
...
extern void prvGetRegistersFromStack( uint32_t *pulFaultStackAddress );
void HardFault_Handler(void)
{
/* USER CODE BEGIN HardFault_IRQn 0 */
__asm volatile
(
" tst lr, #4 \n"
" ite eq \n"
" mrseq r0, msp \n"
" mrsne r0, psp \n"
" ldr r1, [r0, #24] \n"
" ldr r2, handler2_address_const \n"
" bx r2 \n"
" handler2_address_const: .word prvGetRegistersFromStack \n"
);
....
Markus |
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: DB4PLE on 02. July 2017, 17:18:58
Hallo Markus,
jetzt ganz langsam:
stm32f7xx_it.c:
In original Zustand versetzen:
git checkout <pfad_zu>/stm32f7xx_it.c
Dann kommentierst Du einfach in stm32f7xx_it.c die Funktion HardFault_Handler aus. Am besten #if 0 ... #endif um die Funktion rum.
Nun findet der Linker deine Funktion HardFault_Handler in mchf_main.c und nutzt die, d.h. die Kompilierung funktioniert.
73
Danilo
|
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: dl8mby on 02. July 2017, 17:29:50
Hallo Danilo,
während Du den Post geschrieben hast, habe ich den
Teil des HardFault_Handler aus basesw/mcHF/Src/stm32f4xx_it.c
entfernt (Auskommentiert mit //) und den HardFault_Handler
wieder in der mchf_main.c aktiviert, den ich zuvor auskommentiert
habe.
Trotzdem habe ich noch einen LD Error.
Werde nun Deine Vorgehensweise anwenden.
Markus
mchf_main.c
===========
// catch and debug hard faults
/* The prototype shows it is a naked function -
in effect this is just an assembly function. */
//void HardFault_Handler( void ) __attribute__( ( naked ) );
static void prvGetRegistersFromStack( uint32_t *pulFaultStackAddress )
{
/* These are volatile to try and prevent the compiler/linker optimising them
away as the variables never actually get used. If the debugger won't show the
values of the variables, make them global my moving their declaration outside
of this function. */
volatile uint32_t r0;
volatile uint32_t r1;
volatile uint32_t r2;
volatile uint32_t r3;
volatile uint32_t r12;
volatile uint32_t lr; /* Link register. */
volatile uint32_t pc; /* Program counter. */
volatile uint32_t psr;/* Program status register. */
r0 = pulFaultStackAddress[ 0 ];
r1 = pulFaultStackAddress[ 1 ];
r2 = pulFaultStackAddress[ 2 ];
r3 = pulFaultStackAddress[ 3 ];
r12 = pulFaultStackAddress[ 4 ];
lr = pulFaultStackAddress[ 5 ];
pc = pulFaultStackAddress[ 6 ];
psr = pulFaultStackAddress[ 7 ];
/* When the following line is hit, the variables contain the register values. */
for( ;; );
}
/* The fault handler implementation calls a function called
prvGetRegistersFromStack(). */
void HardFault_Handler(void)
{
__asm volatile
(
" tst lr, #4 \n"
" ite eq \n"
" mrseq r0, msp \n"
" mrsne r0, psp \n"
" ldr r1, [r0, #24] \n"
" ldr r2, handler2_address_const \n"
" bx r2 \n"
" handler2_address_const: .word prvGetRegistersFromStack \n"
);
}
// end catch and debug hard faults
[LD] fw-mchf.elf
/tmp/ccK0rSXl.ltrans1.ltrans.o: In function `HardFault_Handler':
~/mchfTRX/wrk/20170701/src/mchf_main.c:118: undefined reference to `prvGetRegistersFromStack'
collect2: error: ld returned 1 exit status
Makefile:247: recipe for target 'fw-mchf.elf' failed
make: *** [fw-mchf.elf] Error 1
markus@HP87:~/mchfTRX/wrk/20170701
>vi ./src/mchf_main.c |
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: dl8mby on 02. July 2017, 17:33:10
PS.:
hast Du dich da verschrieben mit der 7 statt der 4 bei
git checkout <pfad_zu>/stm32f7xx_it.c.
Ich compiliere für für den 407 (bzw. den 429 aber mit 407
Setting im Makefile)
MACHFLAGS_F4 := .... -DSTM32F407xx ....
Markus
|
Title: Re:"dies und das" zur Version vom 30.06.2017
Post by: DB4PLE on 02. July 2017, 17:47:04
Sorry,
Richtig: stm32f4xx_it.c. Habe zuviel am OVI40 gemacht die Tage...
Du musst noch dass static vor der Funktion prvGet ... entfernen, dann sieht das der Linker auch, wenn er mal nachschaut.
73
Danilo |
Diskussions- und Newsboard des DARC-Ortsverbandes I40 | Powered by YaBB SE
© 2001-2003, YaBB SE Dev Team. All Rights Reserved.
|