Fixes #2470 alternatively to #2471.

does this actually execute the reset run command on the line after program?

Not sure, the openocd documentation is a bit blurry here - but with OlegHahm@aedaa10 it should do so. From openocd documentation

5. reset run is called if reset parameter is given.
6. OpenOCD is shutdown if exit parameter is given. 

I have some problem with the exit parameter and OpenOCD 0.8.0. I am investigating now.

/home/kim/eistec/src/riot/dist/tools/openocd/openocd.sh flash
### Flashing Target ###
Open On-Chip Debugger 0.8.0 (2014-05-11-21:34)
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.sourceforge.net/doc/doxygen/bugs.html
adapter speed: 1000 kHz
Info : only one transport option; autoselect 'jtag'
srst_only separate srst_gates_jtag srst_push_pull connect_deassert_srst
cortex_m reset_config sysresetreq
Info : add flash_bank kinetis k60.pflash.0
Info : add flash_bank kinetis k60.pflash.1
Info : clock speed 1000 kHz
Info : JTAG tap: k60.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
START...
Info : k60.cpu: hardware has 6 breakpoints, 4 watchpoints
END...
    TargetName         Type       Endian TapName            State       
--  ------------------ ---------- ------ ------------------ ------------
 0* k60.cpu            cortex_m   little k60.cpu            running
Info : JTAG tap: k60.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
START...
END...
target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x000018e0 msp: 0x20010000
Info : JTAG tap: k60.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
START...
END...
target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x000018e0 msp: 0x20010000
** Programming Started **
auto erase enabled
Error: Invalid command argument
image.base_address option value ('exit') is not valid
** Programming Failed **
shutdown command invoked

in OpenOCD 0.8.0 the program command is different:

-- Command: program filename [verify] [reset] [offset]
This is a helper script that simplifies using OpenOCD as a
standalone programmer. The only required parameter is `filename',
the others are optional. *Note Flash Programming::.

The behaviour according to the 0.8.0 manual is to shut down OpenOCD after the program command has been executed, which is why we were seeing this difference between 0.9.0 and 0.8.0

Since the program command is a convenience macro for the real flash commands and it has different semantics for different versions it may be better to use the real commands instead?

    -c 'flash write_image erase $(ELFFILE) 0x00000000 elf' \
    -c 'verify_image $(ELFFILE)' \
    -c 'reset run' \
    -c 'shutdown'

or if you prefer ihex:

    -c 'flash write_image erase $(HEXFILE) 0x00000000 ihex' \
    -c 'verify_image $(HEXFILE)' \
    -c 'reset run' \
    -c 'shutdown'

shutdown is a bad option since it results in an error return value.

(EDIT: At least in post January openocd revisions.)

If I see it correctly, we have three choices:

1. Force users to use latest openocd version from Git or provide our own fork.
2. Add a check to the openocd script to set the commands according to the used revision.
3. Use the proposed solution from @gebart with the shutdown command and ignore the return value (similar to dist/openocd.sh: added shutdown to flash commands #2471) for now and use the "proper" version as soon as openocd 0.90 is widespread.

Personally, I think I prefer 3.

In my opinion 1. is quite ok. How do we go on here?

@PeterKietzmann I would like to wait with 1. until at least a supported version is in the upstream repos of Ubuntu (possibly even LTS) before forcing people to upgrade when there is no functional reason to upgrade to the prerelease version.

So I vote no. 3

Well, I do agree with waiting for a supported version. Also I believe that your solution is fine :-) . Just wanted to trigger the conversation/progress of this PR

+1 for 3

Will be rebased as soon as OpenOCD 0.9.0 is part of most common distributions.

Will be rebased as soon as OpenOCD 0.9.0 is part of most common distributions.

@OlegHahm openocd-0.9.0 seems to be part of ubuntu since the 2015-09 version. Is ubuntu common enough?

I think the agreement was to wait for the version in Ubuntu LTS, i.e. waiting for Ubuntu 04.2016

I think the agreement was to wait for the version in Ubuntu LTS, i.e. waiting for Ubuntu 04.2016

That's what I just wanted to say. Also keep in mind that 14.04 will be supported until April 2019.
Also: The most current Debian stable (Jessie) also only has support for 0.8.0 (EOL not provided yet).

(though I use a hand-build version of openocd I run 14.04 on one of my main working machines)

That's what I just wanted to say. Also keep in mind that 14.04 will be supported until April 2019.
Also: The most current Debian stable (Jessie) also only has support for 0.8.0 (EOL not provided yet).

Not having system support doesn't mean that people can't install a newer version by hand ..

EDIT: basically, what you said above (:

What's the status on this? the new Ubuntu release is already there with the new OpenOCD version AFAIK, so can this be merged for the release?

Can anybody try?

Please rebase and I can give it a try ;)

good point

Unfortunately, openocd.org seems to be down.

But rebase should be up it isn't? :P

Actually it is.

All is up now, rebase? :D

If I see this correctly, the openocd maintainers have changed to not let shutdown return an error value any more unless you give it a parameter. Hence, we can go with #2897.

Great, thanks!