通过openocd和gdb调试stm32f407时，Rust调试不会在断点处停止

如何解决通过openocd和gdb调试stm32f407时，Rust调试不会在断点处停止

调试stm32f407vet6板和rust代码时出现问题。问题的关键在于GDB会忽略断点。设置断点并在gdb中执行“ continue”命令后，程序将继续忽略所有断点。停止程序运行的唯一方法是使用“ ctrl + c”命令引起中断。执行此命令后，开发板将在当前正在执行的行上停止执行。我尝试在所有可以设置断点的行上设置断点，但是所有尝试均未成功。

$ openocd
Open On-Chip Debugger 0.10.0 (2020-07-01) [https://github.com/sysprogs/openocd]
Licensed under GNU GPL v2
libusb1 09e75e98b4d9ea7909e8837b7a3f00dda4589dc3
For bug reports,read
        http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 2000 kHz
Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED
Info : STLINK V2J35S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 6.436364
Info : stm32f4x.cpu: hardware has 6 breakpoints,4 watchpoints
Info : starting gdb server for stm32f4x.cpu on 3333
Info : Listening on port 3333 for gdb connections

$ arm-none-eabi-gdb -q target\thumbv7em-none-eabihf\debug\test_blink
Reading symbols from target\thumbv7em-none-eabihf\debug\test_blink...                                                                                                        
(gdb) target remote :3333                                                                                                                                                    
Remote debugging using :3333                                                                                                                                                 
0x00004070 in core::ptr::read_volatile (src=0xe000e010) at C:\Users\User\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib/rustlib/src/rust\src/libcore/ptr/mod.rs:1005   
1005    pub unsafe fn read_volatile<T>(src: *const T) -> T {                                                                                                                 
(gdb) load                                                                                                                                                                   
Loading section .vector_table,size 0x1a8 lma 0x0                                                                                                                            
Loading section .text,size 0x47bc lma 0x1a8                                                                                                                                 
Loading section .rodata,size 0xbf0 lma 0x4970                                                                                                                               
Start address 0x47a2,load size 21844                                                                                                                                        
Transfer rate: 100 KB/sec,5461 bytes/write.                                                                                                                                 
(gdb) b main                                                                                                                                                                 
Breakpoint 1 at 0x1f2: file src\main.rs,line 15.                                                                                                                            
(gdb) continue                                                                                                                                                               
Continuing.                                                                                                                                                                  
                                                                                                                                                                             
Program received signal SIGINT,Interrupt.                                                                                                                                   
0x00001530 in cortex_m::peripheral::syst::<impl cortex_m::peripheral::SYST>::has_wrapped (self=0x1000fc6c)                                                                   
    at C:\Users\User\.cargo\registry\src\github.com-1ecc6299db9ec823\cortex-m-0.6.3\src\peripheral/syst.rs:135                                                               
135         pub fn has_wrapped(&mut self) -> bool {                                                                                                                          
(gdb) bt                                                                                                                              
#0  0x00001530 in cortex_m::peripheral::syst::<impl cortex_m::peripheral::SYST>::has_wrapped (self=0x1000fc6c)                        
    at C:\Users\User\.cargo\registry\src\github.com-1ecc6299db9ec823\cortex-m-0.6.3\src\peripheral/syst.rs:135                        
#1  0x00003450 in <stm32f4xx_hal::delay::Delay as embedded_hal::blocking::delay::DelayUs<u32>>::delay_us (self=0x1000fc6c,us=500000) 
    at C:\Users\User\.cargo\registry\src\github.com-1ecc6299db9ec823\stm32f4xx-hal-0.8.3\src/delay.rs:69                              
#2  0x0000339e in <stm32f4xx_hal::delay::Delay as embedded_hal::blocking::delay::DelayMs<u32>>::delay_ms (self=0x1000fc6c,ms=500)    
    at C:\Users\User\.cargo\registry\src\github.com-1ecc6299db9ec823\stm32f4xx-hal-0.8.3\src/delay.rs:32                              
#3  0x00000318 in test_blink::__cortex_m_rt_main () at src\main.rs:40                                                                 
#4  0x000001f6 in main () at src\main.rs:15

memory.x文件：

MEMORY
{
  /* NOTE 1 K = 1 KiBi = 1024 bytes */
  /* TODO Adjust these memory regions to match your device memory layout */
  /* These values correspond to the LM3S6965,one of the few devices QEMU can emulate */
  
  CCMRAM : ORIGIN = 0x10000000,LENGTH = 64K
  RAM : ORIGIN = 0x20000000,LENGTH = 128K
  FLASH : ORIGIN = 0x00000000,LENGTH = 512K
}

/* This is where the call stack will be allocated. */
/* The stack is of the full descending type. */
/* You may want to use this variable to locate the call stack and static
   variables in different memory regions. Below is shown the default value */
_stack_start = ORIGIN(CCMRAM) + LENGTH(CCMRAM);

/* You can use this symbol to customize the location of the .text section */
/* If omitted the .text section will be placed right after the .vector_table
   section */
/* This is required only on microcontrollers that store some configuration right
   after the vector table */
/* _stext = ORIGIN(FLASH) + 0x400; */

/* Example of putting non-initialized variables into custom RAM locations. */
/* This assumes you have defined a region RAM2 above,and in the Rust
   sources added the attribute `#[link_section = ".ram2bss"]` to the data
   you want to place there. */
/* Note that the section will not be zero-initialized by the runtime! */
/* SECTIONS {
     .ram2bss (NOLOAD) : ALIGN(4) {
       *(.ram2bss);
       . = ALIGN(4);
     } > RAM2
   } INSERT AFTER .bss;
*/

openocd.cfg文件：

# Sample OpenOCD configuration for the STM32F3DISCOVERY development board

# Depending on the hardware revision you got you'll have to pick ONE of these
# interfaces. At any time only one interface should be commented out.

# Revision C (newer revision)
source [find interface/stlink.cfg]

# Revision A and B (older revisions)
# source [find interface/stlink-v2.cfg]

source [find target/stm32f4x.cfg]

# use hardware reset,connect under reset
# reset_config none separate

main.rs文件：

#![no_main]
#![no_std]
#![allow(unsafe_code)]

// Halt on panic
#[allow(unused_extern_crates)] // NOTE(allow) bug rust-lang/rust#53964
extern crate panic_halt; // panic handler

use cortex_m;
use cortex_m_rt::entry;
use stm32f4xx_hal as hal;

use crate::hal::{prelude::*,stm32};

#[entry]
fn main() -> ! {
    if let (Some(dp),Some(cp)) = (
        stm32::Peripherals::take(),cortex_m::peripheral::Peripherals::take(),) {
        let rcc = dp.RCC.constrain();
        let clocks = rcc
            .cfgr
            .sysclk(168.mhz())
            .freeze();

        let mut delay = hal::delay::Delay::new(cp.SYST,clocks);

        let gpioa = dp.GPIOA.split();

        let mut l1 = gpioa.pa6.into_push_pull_output();
        let mut l2 = gpioa.pa7.into_push_pull_output();

        loop {
            l1.set_low().unwrap();
            l2.set_high().unwrap();
            delay.delay_ms(500u32);
            l1.set_high().unwrap();
            l2.set_low().unwrap();
            delay.delay_ms(500u32);
        }
    }

    loop {}
}

Cargo.toml文件：

[package]
name = "test_blink"
version = "0.1.0"
authors = ["Alex"]
edition = "2018"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
embedded-hal = "0.2"
nb = "0.1.2"
cortex-m = "0.6"
cortex-m-rt = "0.6"
# Panic behaviour,see https://crates.io/keywords/panic-impl for alternatives
panic-halt = "0.2"
cortex-m-log="0.6.2"

[dependencies.stm32f4xx-hal]
version = "0.8.3"
features = ["rt","stm32f407"]

我刚接触rust嵌入式，也许做错了什么，但是我已经尝试了可以在Internet上找到的所有选项。最初，我认为这是vscode的cortex-debug插件存在问题，甚至创建了issue，但这些家伙帮不了我，因为问题显然不在他们身边。

在cubeIDE中调试“ C”代码是可行的，因此我敢于假设问题出在rust--gdb--openocd中。也许我缺少了一些东西，但不幸的是我自己还找不到。

我希望能有任何资源或想法来解决此问题。

解决方法

我希望您签出了以下资源： Discovery - debug

从 arm-none-eabi-gdb 的屏幕抓取中确实可以看到它没有达到断点。

您应该以后会看到此消息：

注意：自动将硬件断点用于只读地址。断点1，主（）位于...

您是否使用符号编译了源代码，并且未对其进行优化？

否则，您的配置对我来说都是正确的。

通过openocd和gdb调试stm32f407时，Rust调试不会在断点处停止

如何解决通过openocd和gdb调试stm32f407时，Rust调试不会在断点处停止

解决方法

相关推荐