Closed gsmcmullin closed 7 years ago
By my understanding, the flash is only programmable through the AXIM interface, so the ITCM addresses should not be added. I haven't worked with these devices myself.
The code in question was added in https://github.com/blacksphere/blackmagic/commit/c906a8614f77f12a9f72f8ef6a9612b46f4edca2#diff-54d626d784ddecb1ff223db74ae84c02R189.
@alex31 can you please add your input.
In my understanding, the linker is supposed to use addresses in the ITCM/Flash region, but has to put the code into normal flash. So what is the intention to define additional itc, flash regions?
The default linker script for F7 device provided by ChibiOS RTOS use ITCM : STM32F76xxG.ld. I have made this pull request to be able to debug ChibiOS based application. Before this patch was done, i wasnt' able to debug since gdb was not able to access memory from ICTM addresses.
Maybe my lack of knowledge about black magic probe code has made me propose a wrong fix, i am open to cleaner solution as long as one can continue to debug F7 device.
Thanks for the clarification. It looks like that LD script correctly uses the ITCM, but uses the AXIM interface for the load address.
Can you describe the problem you had before this patch? GDB's load
command should have done the right thing. I suspect having the ITCM missing from the memory map may have caused problems if you have not done set mem inaccessible-by-default off
.
I think the best would be to add the ITCM as a single ROM region. This will allow it to be read but not written by GDB. Writes need to be done through the AXIM interface, which is the physical reality. Adding ROM to the memory map is not currently implemented in the BMP firmware.
Ouch,
it seems there are STM32F7 linker scripts out there, even provided in the ST example, that place text dircetly at 0x00200000. An example is from ST Cube Projects/STM32F767ZI-Nucleo/Templates_LL/SW4STM32/STM32F767ZI_Nucleo_ITCM_FLASH/STM32F767ZITx_FLASH_ITCM.ld
/ Specify the memory areas / MEMORY { RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 512K FLASH_ITCM (rx) : ORIGIN = 0x00200000, LENGTH = 2048K } Even so I think the right way would be to load text at 0x0800000 with a logical load address of 0x00200000, BMP should cope with these wrong linker scripts.
Probably my conclusion of putting ITCM data at 0x08000000 with LMA 0x00200000 is wrong. The STM32F7 reference manuals tells in section 3 "Embedded Flash memory (FLASH)" in the flash organization tables that Block base address on ICTM interface is based at 0x00200000.
Can you describe the problem you had before this patch? GDB's load command should have done the right thing. I suspect having the ITCM missing from the memory map may have caused problems if you have not done set mem inaccessible-by-default off.
Here is the transcript of a gdb session using black magic probe master WITHOUT itcm patch for the F7
GNU gdb (GNU Tools for ARM Embedded Processors) 7.10.1.20160923-cvs
(gdb) target extended-remote /dev/bmp_gdb
Remote debugging using /dev/bmp_gdb
(gdb) set pagination off
(gdb) monitor version
Black Magic Probe (Firmware v1.6-rc0-268-g4e8a23b) (Hardware Version 1)
Copyright (C) 2015 Black Sphere Technologies Ltd.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
(gdb) monitor swdp_scan
Target voltage: 0.0V
Available Targets:
No. Att Driver
1 STM32F7xx
(gdb) attach 1
Attaching to program: /home/alex/DEV/STM32/CHIBIOS/C3NEXT/DEVBOARDM767/devbm7_tp01_led/build/ch.elf, Remote target
_idle_thread (p=0x2006db <_idle_thread+10>) at ../../../ChibiOS_next/os/rt/src/chsys.c:79
79 port_wait_for_interrupt();
(gdb) set mem inaccessible-by-default off
(gdb) load
Loading section .vectors, size 0x200 lma 0x8000000
Loading section .text, size 0x277c lma 0x8000200
Loading section .rodata, size 0x3ac lma 0x800297c
Start address 0x200200, load size 11560
Transfer rate: 14 KB/sec, 889 bytes/write.
(gdb) break main
Breakpoint 1 at 0x202952: file main.c, line 22.
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/alex/DEV/STM32/CHIBIOS/C3NEXT/DEVBOARDM767/devbm7_tp01_led/build/ch.elf
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x202952
and now a session witch actual black magic probe master WITH itcm patch for the F7
GNU gdb (GNU Tools for ARM Embedded Processors) 7.10.1.20160923-cvs
(gdb) target extended-remote /dev/bmp_gdb
Remote debugging using /dev/bmp_gdb
(gdb) set pagination off
(gdb) monitor version
Black Magic Probe (Firmware v1.6-rc0-267-ga0791f9) (Hardware Version 1)
Copyright (C) 2015 Black Sphere Technologies Ltd.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
(gdb) monitor swdp_scan
Target voltage: 0.0V
Available Targets:
No. Att Driver
1 STM32F7xx
(gdb) attach 1
Attaching to program: /home/alex/DEV/STM32/CHIBIOS/C3NEXT/DEVBOARDM767/devbm7_tp01_led/build/ch.elf, Remote target
0x002006da in _idle_thread (p=0x0) at ../../../ChibiOS_next/os/rt/src/chsys.c:79
79 port_wait_for_interrupt();
(gdb) set mem inaccessible-by-default off
(gdb) load
Loading section .vectors, size 0x200 lma 0x8000000
Loading section .text, size 0x277c lma 0x8000200
Loading section .rodata, size 0x3ac lma 0x800297c
Start address 0x200200, load size 11560
Transfer rate: 14 KB/sec, 889 bytes/write.
(gdb) break main
Breakpoint 1 at 0x202952: file main.c, line 22.
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/alex/DEV/STM32/CHIBIOS/C3NEXT/DEVBOARDM767/devbm7_tp01_led/build/ch.elf
Note: automatically using hardware breakpoints for read-only addresses.
Breakpoint 1, main () at main.c:22
22 halInit();
The fix actually included for F7 is perhaps not correct and should be fixed, but it cannot be simply removed, otherwise it will break F7 debugging.
Thanks, @alex31. This is great. Please try the changes in #189 and see if this works correctly for you.
Gareth,
the linker example above uses only 0x00200000 for flash. I guess your solution will not work in that situation...
@UweBonnes: No, but I don't believe that it would have worked before either. It would be easy enough to have the driver do the address translation. I'm going to close the PR for now then anyway. I'll take a look again if someone can demonstrate that it doesn't work the way it is.
Thanks, @alex31. This is great. Please try the changes in #189 and see if this works correctly for you.
It works, thanks !
From @UweBonnes via https://sourceforge.net/p/blackmagicdebug/mailman/message/35690822/