Flashing via OpenOCD does not allow the embedded program to run, however running using GDB with an OpenOCD bridge works fine

Question

I am running into an issue with using Rust for embedded purposes where I can run and debug programs just fine, but if I try to flash programs such that they can run without being connected to my computer they do not work.

For reference, I am using an stm32f303 chip. This also seems to be a recent issue, since I haven't had a problem before.

Code being flashed (its just blinky):

#![feature(used)]
#![no_std]

extern crate cortex_m;
extern crate cortex_m_rt;
extern crate panic_abort; // panicking behavior
extern crate stm32f30x_hal as hal;

use hal::prelude::*;
use hal::stm32f30x;
use hal::delay::Delay;

fn main() {
    let cp = cortex_m::Peripherals::take().unwrap();
    let dp = stm32f30x::Peripherals::take().unwrap();

    let mut flash = dp.FLASH.constrain();
    let mut rcc = dp.RCC.constrain();

    let clocks = rcc.cfgr.freeze(&mut flash.acr);

    let mut gpioc = dp.GPIOC.split(&mut rcc.ahb);

    let mut led1 = gpioc
        .pc13
        .into_push_pull_output(&mut gpioc.moder, &mut gpioc.otyper);

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

    loop {
        led1.set_high();
        delay.delay_ms(1_000_u16);
        led1.set_low();
        delay.delay_ms(1_000_u16);
    }
}

// As we are not using interrupts, we just register a dummy catch all
// handler
#[link_section = ".vector_table.interrupts"]
#[used]
static INTERRUPTS: [extern "C" fn(); 240] = [default_handler; 240];

extern "C" fn default_handler() {
    loop {}
}

Output of OpenOCD program command:

$ openocd -f interface/jlink.cfg -f target/stm32f3x.cfg -c "program target/thumbv7em-none-eabihf/debug/cortex-m-quickstart verify reset exit"

Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
none separate
cortex_m reset_config sysresetreq
Info : No device selected, using first device.
Info : J-Link EDU Mini V1 compiled Mar 16 2017 12:04:38
Info : Hardware version: 1.00
Info : VTarget = 3.178 V
Info : clock speed 1000 kHz
Info : JTAG tap: stm32f3x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f3x.bs tap/device found: 0x06422041 (mfg: 0x020 (STMicroelectronics), part: 0x6422, ver: 0x0)
Info : stm32f3x.cpu: hardware has 6 breakpoints, 4 watchpoints
adapter speed: 1000 kHz
Info : JTAG tap: stm32f3x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f3x.bs tap/device found: 0x06422041 (mfg: 0x020 (STMicroelectronics), part: 0x6422, ver: 0x0)
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x1ffff1bc msp: 0x20001258
Info : Reduced speed from 8000 kHz to 4000 kHz (maximum).
adapter speed: 8000 kHz
** Programming Started **
auto erase enabled
Info : device id = 0x10036422
Info : flash size = 256kbytes
wrote 14336 bytes from file target/thumbv7em-none-eabihf/debug/cortex-m-quickstart in 0.688176s (20.344 KiB/s)
** Programming Finished **
** Verify Started **
verified 13028 bytes in 0.077558s (164.041 KiB/s)
** Verified OK **
** Resetting Target **
adapter speed: 1000 kHz
Info : JTAG tap: stm32f3x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f3x.bs tap/device found: 0x06422041 (mfg: 0x020 (STMicroelectronics), part: 0x6422, ver: 0x0)
shutdown command invoked

As can be seen, there aren't any issues when flashing the program, however it doesn't run. Once again, everything is completely fine when using GDB, and the code runs without any issues.

Any help, advice, or even general ideas of what to do would be greatly appreciated!

[Update]

It looks like the issue is with my boot0 pin, which is pulled high instead of low. This means that when GDB isn't connected and setting the PC, the MCU tries to boot from system memory instead of main memory. This explains why it works when debugging but not on its own.

Answer 1

For anyone who may be following the instructions in the Embedded Rust Book , if you have been using semihosting to print messages from your program while debugging (I used cortex_m_semihosting::hprintln ), be aware that it seems to cause the same symptoms as above. I spent hours trying to figure out why the program would not start when run 'by itself', but removing the semihosting crate and the hprintln call immediately fixed the problem.