Menu
▾
▴
Re: [OpenOCD-user] What target file for an ST ARM M33 processor
|
From: Antonio B. <bor...@gm...> - 2022-12-13 16:56:56
|
Hi, why read at address 0? You have PC pointing to flash memory at 0x08008c70; what about reading there? Also SP is pointing to SRAM at 0x2000c238; can you read/write there? Antonio On Tue, Dec 13, 2022 at 5:46 PM David 'Miller' Lowe <mi...@gm...> wrote: > > Hi Paul and openocd user group! > > I had to update my openocd to use the stm32l5x.cfg but did not get a much different result than with the xxxl4x.cfg. > > I can connect, reset, halt, reg, but not dump memory or connect gdb. > > Is there a recommended guide anywhere that I can use to align the .cfg file and my new processor? I do have all the data sheets but can't share them yet due to an NDA. > > Miller > > > I did the following: > > Updated my openocd to Open On-Chip Debugger 0.12.0-rc2+dev-00989-g9501b263e (2022-12-13-08:01) > Used the command line: $ /usr/local/bin/openocd -d2 -f interface/cmsis-dap.cfg -f target/stm32l5x.cfg > > > Here is the openocd invocation... > > miller@goliath:[~] > $ /usr/local/bin/openocd -d2 -f interface/cmsis-dap.cfg -f target/stm32l5x.cfg > Open On-Chip Debugger 0.12.0-rc2+dev-00989-g9501b263e (2022-12-13-08:01) > Licensed under GNU GPL v2 > For bug reports, read > http://openocd.org/doc/doxygen/bugs.html > debug_level: 2 > > Info : auto-selecting first available session transport "swd". To override use 'transport select <transport>'. > Info : Listening on port 6666 for tcl connections > Info : Listening on port 4444 for telnet connections > Info : CMSIS-DAP: SWD supported > Info : CMSIS-DAP: JTAG supported > Info : CMSIS-DAP: FW Version = 1.0 > Info : CMSIS-DAP: Interface Initialised (SWD) > Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 0 nRESET = 1 > Info : CMSIS-DAP: Interface ready > Info : clock speed 500 kHz > Info : SWD DPIDR 0x6ba02477 > Info : [stm32l5x.cpu] Cortex-M33 r0p4 processor detected > Info : [stm32l5x.cpu] target has 8 breakpoints, 4 watchpoints > Info : starting gdb server for stm32l5x.cpu on 3333 > Info : Listening on port 3333 for gdb connections > Info : accepting 'telnet' connection on tcp/4444 > > When I telnet to 4444 I can get some more info > > $ telnet localhost 4444 > Trying 127.0.0.1... > Connected to localhost. > Escape character is '^]'. > Open On-Chip Debugger > > I am able to reset and halt. > > > reset > > halt > [stm32l5x.cpu] halted due to debug-request, current mode: Thread > xPSR: 0x29000000 pc: 0x08008c70 msp: 0x2000c238 > > I can dump registers > > reg > ===== arm v7m registers > (0) r0 (/32): 0x40004800 > (1) r1 (/32): 0x00000000 > (2) r2 (/32): 0x00000000 > (3) r3 (/32): 0x00000873 > (4) r4 (/32): 0x00000005 > (5) r5 (/32): 0x2000b544 > (6) r6 (/32): 0x00000020 > (7) r7 (/32): 0x00000873 > (8) r8 (/32): 0x00000000 > (9) r9 (/32): 0x000000ff > (10) r10 (/32): 0xffffffff > (11) r11 (/32): 0xffffffff > (12) r12 (/32): 0x00000003 > (13) sp (/32): 0x2000c238 > (14) lr (/32): 0x08008c21 > (15) pc (/32): 0x08008c70 > (16) xPSR (/32): 0x29000000 > (17) msp (/32): 0x2000c238 > (18) psp (/32): 0x2000c2b0 > (20) primask (/1): 0x00 > (21) basepri (/8): 0x00 > (22) faultmask (/1): 0x00 > (23) control (/3): 0x04 > (24) msp_ns (/32): 0x00000000 > (25) psp_ns (/32): 0x00000000 > (26) msp_s (/32): 0x00000000 > (27) psp_s (/32): 0x00000000 > (28) msplim_s (/32): 0x00000000 > (29) psplim_s (/32): 0x00000000 > (30) msplim_ns (/32): 0x00000000 > (31) psplim_ns (/32): 0x00000000 > (33) primask_s (/1): 0x00 > (34) basepri_s (/8): 0x00 > (35) faultmask_s (/1): 0x00 > (36) control_s (/3): 0x00 > (38) primask_ns (/1): 0x00 > (39) basepri_ns (/8): 0x00 > (40) faultmask_ns (/1): 0x00 > (41) control_ns (/3): 0x00 > (42) d0 (/64): 0x4974240043700000 > (43) d1 (/64): 0x460000003f800000 > (44) d2 (/64): 0x0000000000000000 > (45) d3 (/64): 0x0000000000000000 > (46) d4 (/64): 0x0000000000000000 > (47) d5 (/64): 0x0000000000000000 > (48) d6 (/64): 0x0000000000000000 > (49) d7 (/64): 0x0000000000000000 > (50) d8 (/64): 0x0000000000000000 > (51) d9 (/64): 0x0000000000000000 > (52) d10 (/64): 0x0000000000000000 > (53) d11 (/64): 0x0000000000000000 > (54) d12 (/64): 0x0000000000000000 > (55) d13 (/64): 0x0000000000000000 > (56) d14 (/64): 0x0000000000000000 > (57) d15 (/64): 0x0000000000000000 > (58) fpscr (/32): 0x02000000 > ===== Cortex-M DWT registers > > > When I try to dump some memory I get a failure > > > read_memory 0 32 10 > SWD DPIDR 0x6ba02477 > Failed to read memory at 0x00000000 > read_memory: read at 0x00000000 with width=32 and count=10 failed > read_memory: failed to read memory > > > Just for fun (Which I knew would fail) I connected gdb to see what would work. > > $ /home2/miller/bin/gcc-arm-none-eabi-9-2019-q4-major/bin/arm-none-eabi-gdb ~/src/vip-rcip/vip/build/debug/vip.elf > GNU gdb (GNU Tools for Arm Embedded Processors 9-2019-q4-major) 8.3.0.20190709-git > Copyright (C) 2019 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-linux-gnu --target=arm-none-eabi". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>. > 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 /home2/miller/src/vip-rcip/vip/build/debug/vip.elf... > (gdb) target extended-remote :3333 > Remote debugging using :3333 > Remote connection closed > (gdb) > > > On Tue, Dec 13, 2022 at 12:15 AM Paul Fertser <fer...@gm...> wrote: >> >> Hi David, >> >> On Mon, Dec 12, 2022 at 06:22:15PM -0800, David 'Miller' Lowe wrote: >> > Does anyone have a working cfg file to use for a M33 ST core? >> >> That should work with cortex_m target with the current code, and some >> additional work is being done too, see >> e.g. https://review.openocd.org/c/openocd/+/7265 >> >> Flash driver is another question of course. First you need to see if >> debug works. >> >> -- >> Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! >> mailto:fer...@gm... > > _______________________________________________ > OpenOCD-user mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openocd-user |
