Target voltage too low

[yuvadm]

Trying to flash a board that has one dead motor (even after replacement), I figured I have nothing to lose before I dump it.

Getting this on the unlock step:

$ openocd -f /usr/share/openocd/scripts/interface/stlink-v2.cfg -f /usr/share/openocd/scripts/target/stm32f0x.cfg -c init -c "reset halt" -c "stm32f0x unlock 0" -c "reset run" -c shutdown
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 "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
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
none separate
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v24 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 1.204813
Error: target voltage may be too low for reliable debugging
Error: init mode failed (unable to connect to the target)
in procedure 'init' 
in procedure 'ocd_bouncer'

The board boots and binds to the controller, just can't fly due to one dead motor, so I would assume I can at least flash it with this firmware. Am I doing anything wrong?

Getting the same error no matter what pin / power combination I try.

I'm using https://www.banggood.com/ST-LINKV2-ST-LINK-V2CN-STLINK-Debugger-Emulator-Download-Manager-STM8-STM32-p-1099119.html

[silver13]

I haven't seen one of the "proper" st-links used before, but they should work. Are you powering the board with a battery when flashing?

I think you could connect the vcc pin from the st-link to the vcc pad of the board, but make sure it's 3.3v because 5v will break the board.

Alternatively you could try the "stm32 st-link utility" on windows

[yuvadm]

Yes I tried powering both with the VCC/VDD pin, as well as with the battery, and even both together - no working combination. Also weird that the target voltage is jumping up and down between ~1.2 and ~0.4 not exactly sure why.

[silver13]

The st-link I use, I'm pretty sure does not have the voltage feature implemented

The ST documents show it uses a "VAPP" pin to detect voltage, I think that should be connected to a 3.3v source. The VDD pin provides power, so if this is connected, you don't need to connect board battery.

Also remember the pads are marked in reverse on the blue board

[yuvadm]

OK, some progress made. I powered the board from the battery, then connected GND-GND, DAT-CLK, CLK-DAT and then +3V-TVCC. After which I got this output:

$ openocd -f /usr/share/openocd/scripts/interface/stlink-v2.cfg -f /usr/share/openocd/scripts/target/stm32f0x.cfg -c init -c "reset halt" -c "stm32f0x unlock 0" -c "reset run" -c shutdown
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 "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
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
none separate
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v24 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 2.781054
Info : stm32f0x.cpu: hardware has 4 breakpoints, 2 watchpoints
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
adapter speed: 950 kHz
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0xc1000003 pc: 0xfffffffe msp: 0xfffffffc
Info : device id = 0x10006444
Info : flash size = 16kbytes
Info : Device Security Bit Set
target halted due to breakpoint, current mode: Handler HardFault
xPSR: 0x61000003 pc: 0x2000003a msp: 0xfffffffc
stm32x unlocked.
INFO: a reset or power cycle is required for the new settings to take effect.
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
adapter speed: 950 kHz
shutdown command invoked

After a power cycle the board won't boot at all. Hmm..

[yuvadm]

So it looks like it's actually unlocked. Now trying to flash the actual firmware, getting this:

$ openocd -f /usr/share/openocd/scripts/interface/stlink-v2.cfg -f /usr/share/openocd/scripts/target/stm32f0x.cfg -c init -c "reset halt" -c "flash write_image erase h8blue 0x08000000" -c "verify_image h8blue 0x08000000" -c "reset run" -c shutdown
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 "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
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
none separate
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v24 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 2.785857
Info : stm32f0x.cpu: hardware has 4 breakpoints, 2 watchpoints
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
adapter speed: 950 kHz
target halted due to debug-request, current mode: Thread 
xPSR: 0xc1000000 pc: 0xfffffffe msp: 0xfffffffc
auto erase enabled
Info : device id = 0x10006444
Info : flash size = 16kbytes
Warn : no flash bank found for address 10000000
wrote 0 bytes from file h8blue in 0.005447s (0.000 KiB/s)
Error: timed out while waiting for target halted
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0x81000003 pc: 0xfffffffe msp: 0xffffffd8
Error: error executing cortex_m crc algorithm

[silver13]

I'm not sure about this, it's clearly supposed to use address 0x08000000 for flashing, but it tries address 10000000 for some reason.

I'm afraid this is probably above my pay grade to fix, you could try the st-link utility, I heard it might work under wine, too

[yuvadm]

@silver13 no problem, thanks for trying to help out. I'll just keep this updated for posterity's sake.

[paulfertser]

@yuvadm , just use h8blue.elf directly:
openocd -f interface/stlink.cfg -c "set FLASH_SIZE 32768" -f target/stm32f0x.cfg -c "program h8blue.elf verify reset exit"

[yuvadm]

@paulfertser thanks! It's been a while, will attempt this once I retrieve all the tools from cold storage 😆

[paulfertser]

@yuvadm , feel free to ping me on #openocd IRC freenode channel for more interactive support :) I also wonder where that odd 0x10000000 address came from, it'd be interesting to see -d3 output for that case. And btw, I've added 3 "pull requests" to this blue board fork, you might want to take a look at it later. I recommend changing the ld script to use full 32KB of flash (device claims just 16 but the firmware already assumes it's 32 when storing PIDs and calibration data).