reset run command in openocd is not working as expected
fanghuaqi opened this issue · 2 comments
When I am trying zephyr on EMSK, and found that the reset run command is not working as expected, the target is only being reset but not running. But you can manually add a resume command to let the application run.
As documented in openocd manual, reset run will let the target run.
Here is log info from command line:
hqfang@debian:~/workspace/zephyr/samples/synchronization$ sh -c '/opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/openocd -s /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/share/openocd/scripts -f '\''/home/hqfang/workspace/zephyr/boards/arc/em_starterkit/support/openocd.cfg'\'' -c '\''init'\'' -c '\''targets'\'' -c '\''reset halt'\'' -c "load_image /home/hqfang/workspace/zephyr/samples/synchronization/outdir/em_starterkit/zephyr.elf" -c '\''reset halt'\'' -c "verify_image /home/hqfang/workspace/zephyr/samples/synchronization/outdir/em_starterkit/zephyr.elf" -c '\''reset run'\'''
Open On-Chip Debugger 0.9.0-dirty (2017-01-08-19:49)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
adapter speed: 5000 kHz
Info : clock speed 5000 kHz
Info : JTAG tap: arc-em.cpu tap/device found: 0x200044b1 (mfg: 0x258, part: 0x0004, ver: 0x2)
TargetName Type Endian TapName State
-- ------------------ ---------- ------ ------------------ ------------
0* arc-em.cpu arcv2 little arc-em.cpu halted
Info : JTAG tap: arc-em.cpu tap/device found: 0x200044b1 (mfg: 0x258, part: 0x0004, ver: 0x2)
target state: halted
11392 bytes written at address 0x10000000
downloaded 11392 bytes in 0.034297s (324.372 KiB/s)
Info : JTAG tap: arc-em.cpu tap/device found: 0x200044b1 (mfg: 0x258, part: 0x0004, ver: 0x2)
target state: halted
verified 11392 bytes in 0.101260s (109.866 KiB/s)
Info : JTAG tap: arc-em.cpu tap/device found: 0x200044b1 (mfg: 0x258, part: 0x0004, ver: 0x2)
target state: halted
There is not output in terminal.
But if I add an extra resume command, it will run normally.
hqfang@debian:~/workspace/zephyr/samples/synchronization$ sh -c '/opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/openocd -s /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/share/openocd/scripts -f '\''/home/hqfang/workspace/zephyr/boards/arc/em_starterkit/support/openocd.cfg'\'' -c '\''init'\'' -c '\''targets'\'' -c '\''reset halt'\'' -c "load_image /home/hqfang/workspace/zephyr/samples/synchronization/outdir/em_starterkit/zephyr.elf" -c '\''reset halt'\'' -c "verify_image /home/hqfang/workspace/zephyr/samples/synchronization/outdir/em_starterkit/zephyr.elf" -c '\''reset run'\'' -c '\''resume'\'''
Open On-Chip Debugger 0.9.0-dirty (2017-01-08-19:49)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
adapter speed: 5000 kHz
Info : clock speed 5000 kHz
Info : JTAG tap: arc-em.cpu tap/device found: 0x200044b1 (mfg: 0x258, part: 0x0004, ver: 0x2)
TargetName Type Endian TapName State
-- ------------------ ---------- ------ ------------------ ------------
0* arc-em.cpu arcv2 little arc-em.cpu running
Info : JTAG tap: arc-em.cpu tap/device found: 0x200044b1 (mfg: 0x258, part: 0x0004, ver: 0x2)
target state: halted
target state: halted
11392 bytes written at address 0x10000000
downloaded 11392 bytes in 0.034270s (324.628 KiB/s)
Info : JTAG tap: arc-em.cpu tap/device found: 0x200044b1 (mfg: 0x258, part: 0x0004, ver: 0x2)
target state: halted
verified 11392 bytes in 0.099547s (111.756 KiB/s)
Info : JTAG tap: arc-em.cpu tap/device found: 0x200044b1 (mfg: 0x258, part: 0x0004, ver: 0x2)
target state: halted
Uart terminal output
***** BOOTING ZEPHYR OS v1.7.99 - BUILD: May 2 2017 07:17:40 *****
threadA: Hello World from arc!
threadB: Hello World from arc!
threadA: Hello World from arc!
It seems like whether target will be resumed depends on architecture-specific code (not sure why upstream designed it this way), and ARC code doesn't resume the target. I'm not yet sure how exactly to fix this yet, since there could be more fundamental issues in how ARC code handles reset procedure, and might need fixing as well.
This should be fixed by #25, which will be in the next release.