Jake-Carter
commented
2 years ago Hi Felipe, this could be the result of a mismatch between the flashed program and the debugger symbols.
With v1.3.0 flashing no longer happens automatically when you launch the debugger. See this section of the readme for more details.
I made this change so that you can quickly restart the program with the green restart arrow. On the older versions, restarting would do a full re-build and re-flash every time, which made restarting very slow.
So basically just make sure you've got the program manually flashed before you debug. Then, the debug symbols will match the actual instructions addresses on the micro and I would expect to see this strange behavior go away.
fneirab
It always start the debugging at the printf statement.
When debugging the "hello_world" example the debug console produces the following report:
`openocd: Open On-Chip Debugger 0.11.0+dev-g4f85f7914 (2021-12-16-13:53) openocd: Licensed under GNU GPL v2 openocd: For bug reports, read openocd: [http://openocd.org/doc/doxygen/bugs.html]() openocd: DEPRECATED! use 'adapter driver' not 'interface' openocd: DEPRECATED! use 'adapter srst delay' not 'adapter_nsrst_delay' openocd: DEPRECATED! use 'adapter srst pulse_width' not 'adapter_nsrst_assert_width' openocd: Info : CMSIS-DAP: SWD supported openocd: Info : CMSIS-DAP: FW Version = 1.0 openocd: Info : CMSIS-DAP: Interface Initialised (SWD) openocd: Info : SWCLK/TCK = 0 SWDIO/TMS = 0 TDI = 0 TDO = 0 nTRST = 0 nRESET = 0 openocd: Info : CMSIS-DAP: Interface ready openocd: Info : clock speed 2000 kHz openocd: Info : SWD DPIDR 0x2ba01477 openocd: Info : max32xxx.cpu: Cortex-M4 r0p1 processor detected openocd: Info : max32xxx.cpu: target has 6 breakpoints, 4 watchpoints openocd: Info : max32xxx.cpu: external reset detected openocd: Info : starting gdb server for max32xxx.cpu on 3333 openocd: Info : Listening on port 3333 for gdb connections openocd: Warn : Only resetting the Cortex-M core, use a reset-init event handler to reset any peripherals or configure hardware srst support. openocd: target halted due to debug-request, current mode: Thread openocd: xPSR: 0x01000000 pc: 0x000001b4 msp: 0x20004000 openocd: Info : Listening on port 6666 for tcl connections openocd: Info : Listening on port 4444 for telnet connections =thread-group-added,id="i1" 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=i686-w64-mingw32 --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". openocd: Info : accepting 'gdb' connection on tcp/3333 openocd: Warn : Prefer GDB command "target extended-remote :3333" instead of "target remote :3333" openocd: Warn : Only resetting the Cortex-M core, use a reset-init event handler to reset any peripherals or configure hardware srst support. openocd: target halted due to debug-request, current mode: Thread openocd: xPSR: 0x01000000 pc: 0x000001b4 msp: 0x20004000 =cmd-param-changed,param="pagination",value="off" openocd: Info : SWD DPIDR 0x2ba01477 openocd: Error: Failed to read memory at 0xfffff000 openocd: Info : SWD DPIDR 0x2ba01477 openocd: Error: Failed to read memory at 0xfffff000 openocd: Info : SWD DPIDR 0x2ba01477 openocd: Error: Failed to read memory at 0xfffff000 openocd: Info : SWD DPIDR 0x2ba01477 openocd: Error: Failed to read memory at 0xfffff000 Note: automatically using hardware breakpoints for read-only addresses.
Breakpoint 1, main () at main.c:62 62 printf("Hello World!\n"); Execute debugger commands using "-exec", for example "-exec info registers" will list registers in use (when GDB is the debugger)`
The debug console looks stops at an unspecified breakpoint, but never gets to the first break point and continues the debugging with the second break point working as expected.
Similar behavior is observed on other examples of the MAX32670EVKIT, like the I2C example. However, in this example when I press the continue button, I get am Unknown break point exception.
The terminal output does not match the I2C example:
During compile I do not get any error messages and a I2C.elf is generated.
I checked the behavior of of the "Hello_World" example with the MAX32660EVSYS and did not see the same behavior. The test with the MAX32660 was done with the latest release files.