Author
|
Topic: "dies und das" zur Version vom 30.06.2017 (Read 8159 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
|
|
|
|
|
|
|