Author
|
Topic: "dies und das" zur Version vom 30.06.2017 (Read 7609 times)
|
|
dl8mby
alter Hase
 Offline
Posts: 363
Ich liebe dieses Forum!
|
 |
Re:"dies und das" zur Version vom 30.06.2017
« Reply #45 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
|
|
 Logged
|
|
|
|
DB4PLE
positron
Urgestein
Offline
Posts: 1278
|
|
Re:"dies und das" zur Version vom 30.06.2017
« Reply #46 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
|
|
Logged
|
|
|
|
dl8mby
alter Hase
Offline
Posts: 363
Ich liebe dieses Forum!
|
|
Re:"dies und das" zur Version vom 30.06.2017
« Reply #47 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
|
|
Logged
|
|
|
|
dl8mby
alter Hase
Offline
Posts: 363
Ich liebe dieses Forum!
|
|
Re:"dies und das" zur Version vom 30.06.2017
« Reply #48 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'
|
|
Logged
|
|
|
|
DB4PLE
positron
Urgestein
Offline
Posts: 1278
|
|
Re:"dies und das" zur Version vom 30.06.2017
« Reply #49 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
|
|
Logged
|
|
|
|
dl8mby
alter Hase
Offline
Posts: 363
Ich liebe dieses Forum!
|
|
Re:"dies und das" zur Version vom 30.06.2017
« Reply #50 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
|
|
Logged
|
|
|
|
DB4PLE
positron
Urgestein
Offline
Posts: 1278
|
|
Re:"dies und das" zur Version vom 30.06.2017
« Reply #51 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
|
|
Logged
|
|
|
|
dl8mby
alter Hase
Offline
Posts: 363
Ich liebe dieses Forum!
|
|
Re:"dies und das" zur Version vom 30.06.2017
« Reply #52 on: 02. July 2017, 14:14:01 »
|
|
Danke,
der Rest des Sonntags ist damit gesichert.
Markus
|
|
Logged
|
|
|
|
dl8mby
alter Hase
Offline
Posts: 363
Ich liebe dieses Forum!
|
|
Re:"dies und das" zur Version vom 30.06.2017
« Reply #53 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( ;; );
}
|
|
Logged
|
|
|
|
DB4PLE
positron
Urgestein
Offline
Posts: 1278
|
|
Re:"dies und das" zur Version vom 30.06.2017
« Reply #54 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
|
|
Logged
|
|
|
|
dl8mby
alter Hase
Offline
Posts: 363
Ich liebe dieses Forum!
|
|
Re:"dies und das" zur Version vom 30.06.2017
« Reply #55 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
|
|
Logged
|
|
|
|
DB4PLE
positron
Urgestein
Offline
Posts: 1278
|
|
Re:"dies und das" zur Version vom 30.06.2017
« Reply #56 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
|
|
Logged
|
|
|
|
dl8mby
alter Hase
Offline
Posts: 363
Ich liebe dieses Forum!
|
|
Re:"dies und das" zur Version vom 30.06.2017
« Reply #57 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
|
|
Logged
|
|
|
|
dl8mby
alter Hase
Offline
Posts: 363
Ich liebe dieses Forum!
|
|
Re:"dies und das" zur Version vom 30.06.2017
« Reply #58 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
|
|
Logged
|
|
|
|
DB4PLE
positron
Urgestein
Offline
Posts: 1278
|
|
Re:"dies und das" zur Version vom 30.06.2017
« Reply #59 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
|
| « Last Edit: 02. July 2017, 16:29:05 by DB4PLE » |
Logged
|
|
|
|
|
|
|
