pyocd / pyocd Goto Github PK

View Code? Open in Web Editor NEW

1.1K 66.0 471.0 28.94 MB

Open source Python library for programming and debugging Arm Cortex-M microcontrollers

Home Page: https://pyocd.io

License: Apache License 2.0

Python 99.74% C 0.09% Batchfile 0.02% Makefile 0.11% Assembly 0.03% Shell 0.01%

embedded python cortex-m arm debug cmsis-dap mcu microcontroller stlink pyocd

pyocd's Introduction

pyOCD

[pyocd.io] [Docs] [Slack] [Mailing list] [CI results]

News

The v0.35 release adds Open-CMSIS-Pack debug sequence support.

See the wiki news page for all recent news.

pyOCD is an open source Python based tool and package for programming and debugging Arm Cortex-M microcontrollers with a wide range of debug probes. It is fully cross-platform, with support for Linux, macOS, Windows, and FreeBSD.

A command line tool is provided that covers most use cases, or you can make use of the Python API to facilitate custom target control. A common use for the Python API is to run and control CI tests.

Support for more than 70 popular MCUs is built-in. In addition, through the use of CMSIS Device Family Packs, nearly every Cortex-M device on the market is supported.

The pyocd command line tool gives you total control over your device with these subcommands:

gdbserver: GDB remote server allows you to debug using gdb via either the console or several GUI debugger options.
load: Program files of various formats into flash or RAM.
erase: Erase part or all of an MCU's flash memory.
pack: Manage CMSIS Device Family Packs that provide additional target device support.
commander: Interactive REPL control and inspection of the MCU.
server: Share a debug probe with a TCP/IP server.
reset: Hardware or software reset of a device.
rtt: Stream Segger RTT IO with any debug probe.
list: Show connected devices.

The API and tools provide these features:

halt, step, resume control
read/write memory
read/write core registers
set/remove hardware and software breakpoints
set/remove watchpoints
write to flash memory
load binary, hex, or ELF files into flash
reset control
access CoreSight DP and APs
SWO and SWV
and more!

Configuration and customization is supported through config files, user scripts, and the Python API.

Requirements

Python 3.7.0 or later.†
macOS, Linux, Windows 7 or newer, or FreeBSD
A recent version of libusb. See libusb installation for details.
Microcontroller with an Arm Cortex-M CPU
Supported debug probe
- CMSIS-DAP v1 (HID) or v2 (WinUSB), including:
  - Atmel EDBG/nEDBG
  - Atmel-ICE
  - Cypress KitProg3 or MiniProg4
  - DAPLink based debug probe, either on-board or standalone
  - Keil ULINKplus
  - NXP LPC-LinkII
  - NXP MCU-Link
  - WCH-Link (1a86:8011, 2a86:8011 and others)
- PE Micro Cyclone and Multilink
- Raspberry Pi Picoprobe
- SEGGER J-Link
- STLinkV2 or STLinkV3, either on-board or the standalone versions

† Version 0.29 is the last version to support Python 2.

Status

PyOCD is beta quality.

The Python API is considered stable for version 0.x, but will be changed in version 1.0.

Documentation

The pyOCD documentation is available on the pyocd.io website.

In addition to user guides, you can generate reference documentation using Doxygen with the supplied config file.

Installing

The full installation guide is available in the documentation.

For notes about installing and using on non-x86 systems such as Raspberry Pi, see the relevant documentation.

The latest stable version of pyOCD may be installed via pip as follows:

$ python3 -mpip install -U pyocd

Note: depending on your system, you may need to use python instead of python3.

The latest pyOCD package is available on PyPI as well as on GitHub.

To install the latest prerelease version from the HEAD of the develop branch, you can do the following:

$ python3 -mpip install --pre -U git+https://github.com/pyocd/pyOCD.git@develop

You can also install directly from the source by cloning the git repository and running:

$ python3 pip install .

Note that, depending on your operating system, you may run into permissions issues running these commands. You have a few options here:

Under Linux, run with sudo -H to install pyOCD and dependencies globally. On macOS, installing with sudo should never be required, although sometimes permissions can become modified such that installing without using sudo fails.
Specify the --user option to install local to your user account.
Run the command in a virtualenv local to a specific project working set.

udev rules on Linux

On Linux, particularly Ubuntu 16.04+, you must configure udev rules to allow pyOCD to access debug probes from user space. Otherwise you will need to run pyOCD as root, using sudo, which is very highly discouraged. (You should never run pyOCD as root on any OS.)

To help with this, example udev rules files are included with pyOCD in the udev folder. The readme in this folder has detailed instructions.

Target support

See the target support documentation for information on how to check if the MCU(s) you are using have built-in support, and how to install support for additional MCUs via CMSIS-Packs.

Using GDB

See the GDB setup documentation for a guide for setting up and using pyocd with gdb and IDEs.

Community resources

Join the pyOCD community!

pyocd.io website
Documentation
Issues
Discussions
Wiki
Mailing list for announcements

In order to foster a healthy and safe environment, we expect contributors and all members of the community to follow our Code of Conduct.

Contributions

We welcome contributions in any area, even if you just create an issue. If you would like to get involved but aren't sure what to start with, just ask on Slack or GitHub discussions and we'll be happy to help you. Or you can look for an open issue. Any work on major changes should be discussed with the maintainers to make everyone is aligned.

Please see the contribution guidelines for detailed requirements. The developers' Guide has instructions on how to set up a development environment for pyOCD.

New pull requests should be created against the develop branch. (You have to change the "base" to develop.)

License

PyOCD is licensed with the permissive Apache 2.0 license. See the LICENSE file for the full text of the license. All documentation and the website are licensed with CC BY 4.0.

pyocd's People

Contributors

Stargazers

Watchers

Forkers

shengliang lluar 0xc0170 karlp flit sibghatullahsheikh joey-ye terryguo xiongyihui genba c1728p9 henryeherman oliviermartin donmorr ecnu3d sg- kazu-zamasu ynsta nordicplayground ytsuboi janekm xinyun anpilog yzdel7 ahnniu notcharan ervandarnell nick-m-martin greatgrz darketik icicle99 willhaines suparit jeremybrodt dbrobins molejar silpol kevinmehall pithikos hapi-tech-solution ohagendorf posborne mindw linjunmin kaizen8501 geky jaej-dev devanlai bridadan tgarc xushoucai autopulated ttyant maclobdell sw17ch cancore gd-hbx sukidog guailong618 flyleaf91 gamnes mjdietzx ming-hai cerevo brianbezanson aurabindo rsalveti mikehaben willee yottastone galak ntoll zk1132 janjongboom asalarian sklli vincentwilliam utzig pengshulin urutva jiangwnd hsiangkai bolorkhuu korjaa schautsang studavekar v2422 bakerstu iotmember cederom lyplcr maureenhelm kevinxusz matthewelse f-tf wanming2008 kegilbert hissokas javakys jaehong

pyocd's Issues

The example in README need some modification to make it work

from pyOCD.gdbserver import GDBServer
from pyOCD.board import MbedBoard

import logging
logging.basicConfig(level=logging.INFO)

board = MbedBoard.chooseBoard()

# start gdbserver
gdb = GDBServer(board, 3333)

# ADD lines
# ====================================
while gdb.isAlive():
    gdb.join(timeout = 0.5)
# ====================================

Ignoring gaps betweens sections

As it was alleged on the mbed site, the pyOCD gdb server ignores the gaps between sections. This lead to locking KL25Z chip for example.

Can not use EP0 for HID OUT on linux

The current implementation of pyOCD using pyUSB does not allow the HID OUT to use EP0 and expects a dedicated endpoint. This is causing problems such as the one described in issue #36.

This issue is not seen under Windows.

Add additional cortex-m registers to GDB server

The GDB server is missing some register when compared with other cortex-m debuggers, such as a j-link. Some additional registers that would probably be good to add:
MSP
PSP
PRIMASK
BASEPRI
FAULTMASK
CONTROL
FPSCR

pyOCD basic_test.py fails on 2nd dev.open call on device with non-matching target id

Synopsis: Running basic_test.py on a new installation of pyOCD on a Mac, with an nRF51-DK connected, yields a "IOError: open failed" error.

Scenario:
MacBook Pro, Core 2 Duo
Mac OS X "Yosemite" 10.3.3 (pre-release seed 3)
Python 2.7.6
Nordic nRF51-DK platform
mbed IF: nrf51822aa_atsam3u2c_if_mbed_V0218_19022015.bin
Enumerates as:
Product ID: 0x0204
Vendor ID: 0x0d28
Version: 1.00
Manufacturer: MBED
Backtrace on failure

  File "basic_test.py", line 46, in <module>
    with MbedBoard.chooseBoard() as board:
  File "/Users/mwirth/Desktop/MacGitRepos/pyOCD/pyOCD/board/mbed_board.py", line 169, in chooseBoard
    all_mbeds = MbedBoard.getAllConnectedBoards(transport, False, blocking, target_override, frequency)
  File "/Users/mwirth/Desktop/MacGitRepos/pyOCD/pyOCD/board/mbed_board.py", line 122, in getAllConnectedBoards
    all_mbeds = INTERFACE[usb_backend].getAllConnectedInterface(mbed_vid, mbed_pid)
  File "/Users/mwirth/Desktop/MacGitRepos/pyOCD/pyOCD/interface/hidapi_backend.py", line 78, in getAllConnectedInterface
    dev.open(vid, pid)
  File "hid.pyx", line 48, in hid.device.open (hid.c:1263)
IOError: open failed

Diagnostics:
Original code snippet around dev.open call:

            try:
                dev.open(vid, pid)
            except AttributeError:
                pass

Added diagnostics:

            try:
                print "Getting ready to try dev.open"
                dev.open(vid, pid)
            except Exception, ex1:
                print "dev.open failed with exception: ", ex1

pyCharm debugger output:

pydev debugger: process 24017 is connecting

Connected to pydev debugger (build 139.1547)
Getting ready to try dev.open
INFO:root:Unsupported target found: 1100
INFO:root:Waiting for a USB device connected
Getting ready to try dev.open
dev.open failed with exception:  open failed

Process finished with exit code 139

Analysis:
So it looks like the dev.open is failing on the second pass, not the first (because the device is already open). On the first pass, it opens, but the code rejects the device later because the target id (1100) doesn't match.

I would suggest the following changes in the pyOCD code:

Add 1100 to the set of matching target ids (Or fix how the id gets extracted from the nRF51-DK.)
If the target id match fails (or the device is rejected for any other reason), make sure to close it.

nrf51822 SWD Fault exception

While debugging tonight, pyOCD started throwing a 'SWD Fault'

DEBUG:root:gdb client has ack!
DEBUG:root:gdb client has ack!
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/threading.py", line 811, in __bootstrap_inner
    self.run()
  File "/home/ctaylor/Stuff/nordic/pyOCD.nordic.git/pyOCD/gdbserver/gdbserver.py", line 164, in run
    [resp, ack, detach] = self.handleMsg(data)
  File "/home/ctaylor/Stuff/nordic/pyOCD.nordic.git/pyOCD/gdbserver/gdbserver.py", line 230, in handleMsg
    return self.resume()
  File "/home/ctaylor/Stuff/nordic/pyOCD.nordic.git/pyOCD/gdbserver/gdbserver.py", line 302, in resume
    if self.target.getState() == TARGET_HALTED:
  File "/home/ctaylor/Stuff/nordic/pyOCD.nordic.git/pyOCD/target/cortex_m.py", line 599, in getState
    dhcsr = self.readMemory(DHCSR)
  File "/home/ctaylor/Stuff/nordic/pyOCD.nordic.git/pyOCD/target/cortex_m.py", line 388, in readMemory
    return self.transport.readMem(addr, transfer_size)
  File "/home/ctaylor/Stuff/nordic/pyOCD.nordic.git/pyOCD/transport/cmsis_dap.py", line 139, in readMem
    [addr])
  File "/home/ctaylor/Stuff/nordic/pyOCD.nordic.git/pyOCD/transport/cmsis_dap_core.py", line 207, in dapTransfer
    raise ValueError('SWD Fault')
ValueError: SWD Fault

NRF51822 Could Not Claim Interface (Raspberry Pi)

I have a Raspberry Pi running Raspbian (Debian).

I install libusb-1.0-0-dev, clone and install the pyUSB repo, and then clone and install the pyOCD. I plug in my NRF51822-mkit and it enumerates under lsusb. If I go into the test directory and run "sudo python basic_test.py" this is the output:

is_kernel_driver_active
Traceback (most recent call last):
  File "basic_test.py", line 48, in <module>
    board = MbedBoard.chooseBoard()
  File "/home/pi/pyOCD/pyOCD/board/mbed_board.py", line 161, in chooseBoard
    all_mbeds = MbedBoard.getAllConnectedBoards(transport, False, blocking, target_override)
  File "/home/pi/pyOCD/pyOCD/board/mbed_board.py", line 125, in getAllConnectedBoards
    mbed.write([0x80])
  File "/home/pi/pyOCD/pyOCD/interface/pyusb_backend.py", line 135, in write
    self.dev.ctrl_transfer(bmRequestType,bmRequest,wValue,wIndex,data)
  File "/usr/local/lib/python2.7/dist-packages/usb/core.py", line 962, in ctrl_transfer
    self._ctx.managed_claim_interface(self, interface_number)
  File "/usr/local/lib/python2.7/dist-packages/usb/core.py", line 146, in managed_claim_interface
    self.backend.claim_interface(self.handle, i)
  File "/usr/local/lib/python2.7/dist-packages/usb/backend/libusb0.py", line 468, in claim_interface
    _check(_lib.usb_claim_interface(dev_handle, intf))
  File "/usr/local/lib/python2.7/dist-packages/usb/backend/libusb0.py", line 380, in _check
    raise USBError(errmsg, ret)
usb.core.USBError: [Errno None] could not claim interface 3: Device or resource busy

This happens every time, though it doesn't seem that the board is claimed by anything else. The odd thing is that interface 3 isn't the board, it's something else. Here's the output to lsusb:

Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. 
Bus 001 Device 021: ID 0d28:0204 NXP LPC1768

I do have a way to get it to work properly. If I unplug the device, then run the basic_test.py program, it outputs "INFO:root:Waiting for a USB device connected". When I connect the device, the program runs as expected. If I try to run the program subsequently after this, it outputs errors such as these:

is_kernel_driver_active
INFO:root:new board id detected: 107002161FE6E019E20F0F91
id => usbinfo | boardname
0 =>   (0xd28, 0x204) [nrf51822]
INFO:root:DAP SWD MODE initialised
[Errno None] Connection timed out
Traceback (most recent call last):
  File "basic_test.py", line 48, in <module>
    board = MbedBoard.chooseBoard()
  File "/home/pi/pyOCD/pyOCD/board/mbed_board.py", line 190, in chooseBoard
    raise e
usb.core.USBError: [Errno None] Connection timed out

is_kernel_driver_active
INFO:root:Unsupported target found: 
INFO:root:Waiting for a USB device connected
INFO:root:new board id detected: 107002161FE6E019E20F0F91
id => usbinfo | boardname
0 =>   (0xd28, 0x204) [nrf51822]
DAP_CONNECT response error
Traceback (most recent call last):
  File "basic_test.py", line 48, in <module>
    board = MbedBoard.chooseBoard()
  File "/home/pi/pyOCD/pyOCD/board/mbed_board.py", line 190, in chooseBoard
    raise e
ValueError: DAP_CONNECT response error

is_kernel_driver_active
Traceback (most recent call last):
  File "basic_test.py", line 48, in <module>
    board = MbedBoard.chooseBoard()
  File "/home/pi/pyOCD/pyOCD/board/mbed_board.py", line 161, in chooseBoard
    all_mbeds = MbedBoard.getAllConnectedBoards(transport, False, blocking, target_override)
  File "/home/pi/pyOCD/pyOCD/board/mbed_board.py", line 126, in getAllConnectedBoards
    u_id_ = mbed.read()
  File "/home/pi/pyOCD/pyOCD/interface/pyusb_backend.py", line 151, in read
    data = self.ep_in.read(self.ep_in.wMaxPacketSize, timeout)
  File "/usr/local/lib/python2.7/dist-packages/usb/core.py", line 364, in read
    return self.device.read(self, size_or_buffer, timeout)
  File "/usr/local/lib/python2.7/dist-packages/usb/core.py", line 918, in read
    self.__get_timeout(timeout))
  File "/usr/local/lib/python2.7/dist-packages/usb/backend/libusb0.py", line 507, in intr_read
    timeout)
  File "/usr/local/lib/python2.7/dist-packages/usb/backend/libusb0.py", line 562, in __read
    timeout
  File "/usr/local/lib/python2.7/dist-packages/usb/backend/libusb0.py", line 380, in _check
    raise USBError(errmsg, ret)
usb.core.USBError: [Errno None] Connection timed out

Unplugging and replugging it results in the could not claim device error.

Does anyone know why this is happening?

[Regression]Memory read and write failure on target kl46z

Hi there,

I've seen some regression on the basic test on target kl46z, so maybe it's raised by some former commit? I'm not familiar with freescale target, need some help.

------ TEST READ / WRITE MEMORY ------
READ32/WRITE32
write32 0x8886B7E4 at 0x0
Traceback (most recent call last):
  File "basic_test.py", line 200, in <module>
    board.uninit()
  File "/home/build/tonwan01/pyocd_workdir/pyOCD/pyOCD/board/board.py", line 56, in uninit
    self.target.resume()
  File "/home/build/tonwan01/pyocd_workdir/pyOCD/pyOCD/target/cortex_m.py", line 609, in resume
    if self.getState() != TARGET_HALTED:
  File "/home/build/tonwan01/pyocd_workdir/pyOCD/pyOCD/target/cortex_m.py", line 600, in getState
    dhcsr = self.readMemory(DHCSR)
  File "/home/build/tonwan01/pyocd_workdir/pyOCD/pyOCD/target/cortex_m.py", line 388, in readMemory
    return self.transport.readMem(addr, transfer_size)
  File "/home/build/tonwan01/pyocd_workdir/pyOCD/pyOCD/transport/cmsis_dap.py", line 139, in readMem
    [addr])
  File "/home/build/tonwan01/pyocd_workdir/pyOCD/pyOCD/transport/cmsis_dap_core.py", line 204, in dapTransfer
    raise ValueError('Transfer not completed')
ValueError: Transfer not completed

Occur many exception using FRDM-KL46Z.

$ pwd
/home/kiwamu/src/pyOCD/test
$ sudo python gdb_test.py
received exception: '0220'
INFO:root:Waiting for a USB device connected
received exception: '0220'
received exception: '0220'
received exception: '0220'
-- snip --

Flash_lpc1768.flash_algo has no key 'pc_erase_sector'

When running basic_test.py, flash.erasePage is called, which attempts to access the pc_erase_sector key of Flash_lpc1768.flash_algo (line 88 of flash.py), which does not exist and a KeyError exception is raised.

pyOCD failures on Mac OS X

pyOCD fails to connect on Mac OS X if a USB keyboard or mouse is connected. The root cause of this is an error in Apple's IOKit, which is worked around in hidapi, but gbishop/cython-hidapi does not use this workaround and is not under active development. This error has been fixed in a fork of the original cython-hidapi: trezor/cython-hidapi.

Please update pyOCD's readme to point to http://github.com/trezor/cython-hidapi instead of https://github.com/gbishop/cython-hidapi

Resource busy

When running pyOCD using the pyUSB backend (as root) on Arch Linux I get the a usb.core.USBError: [Errno 16] Resource busy error during startup.

... which seems to indicate that the HID device is already claimed by something else. However, the is_kernel_driver_active() carried out in pyusb backend in getAllConnectedInterface() reports that no kernel driver is active.

Manually trying to claim the interface immediately after it has been found results in the same error.

I am pretty sure there are no other applications trying to access the device. Running OpenOCD v0.8 against the same CMSIS-DAP interface works correctly.

If pyOCD is run once (failing with Resource busy error), subsequent invokations of opencd will fail until I power-cycle my mbed-device.

Traceback (most recent call last):
File "gdbserver.py", line 26, in
board_selected = MbedBoard.chooseBoard()
File "/usr/lib/python2.7/site-packages/pyOCD/board/mbed_board.py", line 113, in chooseBoard
all_mbeds = MbedBoard.getAllConnectedBoards(transport, False, blocking)
File "/usr/lib/python2.7/site-packages/pyOCD/board/mbed_board.py", line 85, in getAllConnectedBoards
mbed.write([0x80])
File "/usr/lib/python2.7/site-packages/pyOCD/interface/pyusb_backend.py", line 129, in write
self.ep_out.write(data)
File "/usr/lib/python2.7/site-packages/usb/core.py", line 283, in write
return self.device.write(self, data, timeout)
File "/usr/lib/python2.7/site-packages/usb/core.py", line 650, in write
intf, ep = self._ctx.setup_request(self, endpoint)
File "/usr/lib/python2.7/site-packages/usb/core.py", line 154, in setup_request
self.managed_claim_interface(device, intf)
File "/usr/lib/python2.7/site-packages/usb/core.py", line 110, in managed_claim_interface
self.backend.claim_interface(self.handle, i)
File "/usr/lib/python2.7/site-packages/usb/backend/libusb1.py", line 741, in claim_interface
_check(self.lib.libusb_claim_interface(dev_handle.handle, intf))
File "/usr/lib/python2.7/site-packages/usb/backend/libusb1.py", line 554, in _check
raise USBError(_str_error[ret], ret, _libusb_errno[ret])
usb.core.USBError: [Errno 16] Resource busy

How about including a binary gdb_server in current trunk for Linux and Windows?

Hi all,

Recently, I've tried to build a binary gdb_server based on my new test case gdb_server.py with pyinstaller. Pyinstaller can bundle the pyocd library along with gdb_server.py and all the related driver like pyusb and pywinusb into one exe file. It will be very convenient for users to get an on hand gdb server to use. Another reason for do so is that I've noticed the pyocd trunk is quite stable recent days.

If it's accepted, I can help on regularly update the binary gdb_server based on the trunk commit.

"IndexError: list index out of range" while loading executable from GDB to FRDM-K64F

I can't reproduce this, but thought it might be useful to report anyway:

  File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 810, in __bootstrap_inner
    self.run()
  File "/usr/local/lib/python2.7/site-packages/pyOCD/gdbserver/gdbserver.py", line 153, in run
    [resp, ack, detach] = self.handleMsg(data)
  File "/usr/local/lib/python2.7/site-packages/pyOCD/gdbserver/gdbserver.py", line 220, in handleMsg
    return self.flashOp(msg[2:]), 1, 0
  File "/usr/local/lib/python2.7/site-packages/pyOCD/gdbserver/gdbserver.py", line 369, in flashOp
    self.flashData += self.unescape(data[idx_begin:len(data) - 3])
  File "/usr/local/lib/python2.7/site-packages/pyOCD/gdbserver/gdbserver.py", line 437, in unescape
    data[data_idx] = data[data_idx] ^ 0x20
IndexError: list index out of range

Version: pyOCD 0.3.2

usb backend does not discover nrf51822 mbed board

I'm trying to use pyOCD with the nrf51822 mbed board. pyOCD detects the board when I plug it in, but it does not discover the endpoints ("ERROR:root:Endpoints not found"). I am using the default libusb backend and the issue seems to be that getAllConnectedInterface() is looking for both an ep_out and ep_in. However, lsusb shows that the nrf51822 mbed board only has an in endpoint for the MBED CMSIS-DAP HID Interface.

If I use the test case in the hidapi library it seems to discover the board just fine.
By default interface/init.py uses pyusb for non-Darwin posix os. So I built the cython-hidapi (from https://github.com/trezor/cython-hidapi.git) and ran the try.py with the vid/pid for the mbed board and it opens the device and reads back some data. But when I force the backend to 'hidapiusb' via PYOCD_USB_BACKEND, basic_test.py segfaults doing a hid_write() someplace in inside of chooseBoard().

Should the pyusb backend work with the nrf51822 mbed board? I'm using a new install of fedora 20 on a x86_64 box.

I was using the nordic branch of pyOCD, but pyOCD never gets far enough in the startup for the nordic changes to have any effect.

dapTransfer fails on an erased chip

After doing a full chip erase (either by calling board.flash.eraseAll() or by other means), pyocd is unable to communicate with the boards. An operation such as board.flash.init() will either hang or casue a "SWD fault" in the function dapTransfer of cmsis_dap_core.pyc

Tested on nrf mkit and freescale kl25z boards.

Please tag and publish a new version

0.2 is quite old now, there've been lots of fixes and improvements since then. It'd be really useful if a newer version was published to PyPI

pyOCD does not support compare-sections

When new microcontrollers are added to pyOCD, particularly those with new flash algorithms, it's helpful to be able to verify the contents of the flash to be sure that the elf which was written actually appears, as intended, on the MCU. Without this, issues such as #88 will continue to pop up every so often.

The standard workflow is Erase->Program->Verify->Run. Without the verify step, there's no way to know what the MCU is actually running.

Support for the gdb compare-sections command is vital.

spurious nrf51822 program starts

I have been doing a bunch of work with a logic analyzer and pyOCD on the nrf51822 mbed board.

When loading code and issuing commands like 'mon reset' I see spurious code execution.

resetting program:
- process is in Reset_Handler() according to 'where'.
- issue 'mon reset'
- program runs for a short time (enough to produce uart output)
- program halts
- 'where' reports PC is at Reset_Handler()
loading code with 'load' in gdb:
- 'where' reports PC is at Reset_Handler()
- issue 'load'
- code is flashed
- program runs for a short time (enough to produce uart output)
- program halts
- 'where' reports PC is at Reset_Handler()

I'm not sure if this is an order of operations issue in pyOCD or an issue with mbed firmware, but it does it has caused some weird false triggers on the logic analyzer that can be somewhat confusing.

I do not remember seeing this behavior with openocd and STM32s.

SVD support

To support loading svd file, to get chip peripherals and be able to read/write.

I usually have a header file open or a reference manual to get addresses of registers.

Most popular pyOCD interface/IDE & readme.md instructions

I was wondering what most people have been using as an interface to pyOCD? Standalone GDB, Eclipse CDT + GDB, something else? If you use eclipse, are there any plugins that you find useful? I was thinking it would be good to add one or more recommended debugging configurations to readme.md.

I use pyOCD along with eclipse and GDB. I use it through GNU ARM Eclipse's OpenOCD plugin. This plugin can be configured to start a program when debugging begins (for me this is a .bat file which runs gdb_server.py with parameters). It also has a reset button, which regular CDT doesn't (though the reset command can be issued through the gdb console of regular eclipse). I consider this configuration a little unorthodox, but it works well. I also use the Embedded Systems Register View eclipse plugin to view peripheral registers.

Anyone have any configurations they would recommend? Think it would be good to add my (or another) configuration to readme.md, so people who are unfamiliar with pyOCD can get debugging without having to go searching everywhere on how to set things up?

How to improve the pyocd flash download speed?

Hi all, I'm work on the pyocd flash download issue. I compare the download speed of CMSIS DAP with keil and pyocd:

When you download a 500KB bin file to the mbed lpc1768 =>
keil -> cmsis_dap debugger -> target lpc1768 spends about 50s
pyocd(window&linux) -> cmsis_dap debugger -> target lpc1768 spends about 110s
With the help of some python performance analysis tool, we can find that pyocd spend most of its time on usb write&read function
Whole time: 109.656s
Usb read&write: 45.946+14.38+23.016+20.969 = 104.311, so pyocd spends more than 95% of its run time on USB read/write function.
```
  After use time cmd to briefly analysis the pyocd run time:
```
User 2.14
System 0.72
Real 102.44
From the analysis above we can see that most of time wasn’t spent in user mode or kernel mode, so most time consumption should lie in IO wait time.

According to the analysis, I’ve changed the behavior of dapTransferBlock, and divided the write and read usb endpoint into two thread to avoid some IO wait time. However, only 10% speed enhancement is gained from this new feature. So do you have any clue about the low download speed of PyOCD?

LPC4088 Quick Start Board

Below are very minimally tested changes needed for the EA LPC4088 QSB. Only change from lpc1768 is RAM size, so be carefull!

diff --git a/pyOCD/board/mbed_board.py b/pyOCD/board/mbed_board.py
index 0860a28..a83f3ce 100644
--- a/pyOCD/board/mbed_board.py
+++ b/pyOCD/board/mbed_board.py
@@ -35,6 +35,7 @@ BOARD_ID_TO_TARGET = {
                 "9004": "lpc1768",
                 "1040": "lpc11u24",
                 "1050": "lpc800",
+                "1060": "lpc4088",
                 "1070": "nrf51822",
                 "9009": "nrf51822",
                 "9012": "nrf51822",
diff --git a/pyOCD/flash/__init__.py b/pyOCD/flash/__init__.py
index 4a8c32c..717e19b 100644
--- a/pyOCD/flash/__init__.py
+++ b/pyOCD/flash/__init__.py
@@ -43,6 +43,7 @@ FLASH = {
          'lpc800': Flash_lpc800,
          'lpc11u24': Flash_lpc11u24,
          'lpc1768':  Flash_lpc1768,
+         'lpc4088':  Flash_cortex_m,
          'lpc4330':  Flash_lpc4330,
          'nrf51822': Flash_nrf51822,
          'stm32f103rc': Flash_stm32f103rc,
diff --git a/pyOCD/target/__init__.py b/pyOCD/target/__init__.py
index 37cf61f..1d0a174 100644
--- a/pyOCD/target/__init__.py
+++ b/pyOCD/target/__init__.py
@@ -28,6 +28,7 @@ import target_k20d50m
 import target_lpc800
 import target_lpc11u24
 import target_lpc1768
+import target_lpc4088
 import target_lpc4330
 import target_nrf51822
 import target_stm32f103rc
@@ -49,6 +50,7 @@ TARGET = {
           'lpc800': target_lpc800.LPC800,
           'lpc11u24': target_lpc11u24.LPC11U24,
           'lpc1768': target_lpc1768.LPC1768,
+          'lpc4088': target_lpc4088.LPC4088,
           'lpc4330': target_lpc4330.LPC4330,
           'nrf51822': target_nrf51822.NRF51822,
           'stm32f103rc': target_stm32f103rc.STM32F103RC,
diff --git a/pyOCD/target/target_lpc4088.py b/pyOCD/target/target_lpc4088.py
new file mode 100644
index 0000000..be24bd6
--- /dev/null
+++ b/pyOCD/target/target_lpc4088.py
@@ -0,0 +1,48 @@
+"""
+ mbed CMSIS-DAP debugger
+ Copyright (c) 2006-2015 ARM Limited
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+     http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+"""
+
+from cortex_m import CortexM
+
+class LPC4088(CortexM):
+
+    memoryMapXML =  """<?xml version="1.0"?>
+<!DOCTYPE memory-map PUBLIC "+//IDN gnu.org//DTD GDB Memory Map V1.0//EN" "http://sourceware.org/gdb/gdb-memory-map.dtd">
+<memory-map>
+    <memory type="flash" start="0x0" length="0x10000"> <property name="blocksize">0x1000</property></memory>
+    <memory type="flash" start="0x10000" length="0x70000"> <property name="blocksize">0x8000</property></memory>
+    <memory type="ram" start="0x10000000" length="0x10000"> </memory>
+    <memory type="ram" start="0x20000000" length="0x8000"> </memory>
+</memory-map>
+"""
+
+    def __init__(self, transport):
+        super(LPC4088, self).__init__(transport)
+        self.auto_increment_page_size = 0x1000
+
+    def reset(self, software_reset = False):
+        CortexM.reset(self, False)
+
+    def resetStopOnReset(self, software_reset = False, map_to_user = True):
+        CortexM.resetStopOnReset(self)
+
+        # Remap to use flash and set SP and SP accordingly
+        if map_to_user:
+            self.writeMemory(0x400FC040, 1)
+            sp = self.readMemory(0x0)
+            pc = self.readMemory(0x4)
+            self.writeCoreRegisterRaw('sp', sp)
+            self.writeCoreRegisterRaw('pc', pc)

Crash when running blank_test.py on windows

The script blank_test.py causes python.exe to crash on windows. This only happens on python 2.7.8 and does not happen on 2.7.6. It also happens on a random iteration, which seems to indicate that there is a race condition causing this. Does anyone know how to debug a python executable crash? I'm having trouble narrowing down the source of the crash because there is no call stack shown, just a new window that says "python.exe has stopped working." If I turn the logging level to debug, the crashes go away. Let me know if you have any ideas. Thanks.

Writing to floating point registers with GDB does not work properly

Writes to s0-s31 do not work as expected. Writes to even numbered 's' registers modify the wrong register. The value from modifying s[n] is s[n/2]. For example setting the register s6 will modify the value of s3. Writes to registers d0-d15 do not work as well.

GDBServer error "No module named utility.conversion" in 0.4.0

  File "/usr/local/lib/python2.7/site-packages/valinor-0.0.6-py2.7.egg/valinor/gdb.py", line 26, in _launchPyOCDGDBServer
    from pyOCD.gdbserver import GDBServer
  File "/usr/local/lib/python2.7/site-packages/pyOCD/__init__.py", line 18, in <module>
    import board
  File "/usr/local/lib/python2.7/site-packages/pyOCD/board/__init__.py", line 18, in <module>
    import mbed_board
  File "/usr/local/lib/python2.7/site-packages/pyOCD/board/mbed_board.py", line 22, in <module>
    from board import Board
  File "/usr/local/lib/python2.7/site-packages/pyOCD/board/board.py", line 18, in <module>
    from pyOCD.target import TARGET
  File "/usr/local/lib/python2.7/site-packages/pyOCD/target/__init__.py", line 18, in <module>
    import cortex_m
  File "/usr/local/lib/python2.7/site-packages/pyOCD/target/cortex_m.py", line 23, in <module>
    from ..gdbserver import signals
  File "/usr/local/lib/python2.7/site-packages/pyOCD/gdbserver/__init__.py", line 18, in <module>
    from gdbserver import GDBServer
  File "/usr/local/lib/python2.7/site-packages/pyOCD/gdbserver/gdbserver.py", line 21, in <module>
    from ..utility.conversion import hexStringToIntList, hexEncode, hexDecode
ImportError: No module named utility.conversion

pip list | grep pyOCD
pyOCD (0.4)

(Attempting to debug a STM32F401RE)

Problem in function to response gdb g packet

I am using pyOCD at commit 4c05d67 and ran into a problem of function getRegister in file gdbserver.py. The offending code are the way to use CORE_REGISTER:

def getRegister(self):
resp = ''
for i in range(len(CORE_REGISTER)):
reg = self.target.readCoreRegister(i)

Actually the value part in CORE_REGISTER defined in file cortex_m.py isn't continuous. There isn't number 19 for any registers. So here when i becomes 19, there will be error to access register 19.

My target is KL46Z. With this flaw, the first gdb command "target remote :3333" will fail.

Reset time delay discussion

Recently, I've noticed the monitor reset, halt, help is added to the pyocd. It's quite great, but I've noticed that the implementation of final reset is done by cmsis_dap.py

    def reset(self):
        dapSWJPins(self.interface, 0, 'nRESET')
        sleep(0.1)
        dapSWJPins(self.interface, 0x80, 'nRESET')
        sleep(0.1)

So the question is sleep time may vary from target to target, and for mbed lpc1768 I found that 0.1 second is too short for lpc1768 to finish a reset procedure. So should we just enlarge the sleep time or add a variable to each target mcu to manifest their reset time?

K64F flash algorithm is unstable

I'm not sure "unstable" is the right word. Maybe "unusable" would be more appropriate. I've now spent days attempting to debug my project, chasing a Heisenbug, only to discover that it has absolutely nothing to do with my code. Oh, goody.

Here's an example of the problem.
A good flash:

(gdb) x/16hx 0x5950
0x5950 <udp_sendto_chksum+80>:  0xb25b  0x4618  0x3718  0x46bd  0xbd80  0xbf00  0xb580  0xb088
0x5960 <udp_sendto_if+4>:   0xaf04  0x60f8  0x60b9  0x607a  0x807b  0x887b  0x69ba  0x9200

A bad flash:

(gdb) x/16hx 0x5950
0x5950 <udp_sendto_chksum+80>:  0xb25b  0x4618  0x3718  0x46bd  0xbd80  0xbf00  0xb580  0xff88
0x5960 <udp_sendto_if+4>:   0xaf04  0x60f8  0x60b9  0x607a  0x807b  0x887b  0x69ba  0x9200

The relevant part is 0x595e:

(gdb) disassemble 0x595e,+4
Dump of assembler code from 0x595e to 0x5962:
=> 0x0000595e <udp_sendto_if+2>:            ; <UNDEFINED> instruction: 0xff88af04

This is... problematic. It's not even entire sections which are broken, just individual bytes which are erased, but not programmed.

I haven't been able to work out a pattern in which bytes fail to be written correctly.

Ctrl + C won't stop gdb server

Hi,

I found that when user use gdb load, then continue cmd(the user code begins to run), the gdb server can't be stopped by ctrl + c from that moment.

And I add following modification to the code, it works fine now.
diff --git a/pyOCD/gdbserver/gdbserver.py b/pyOCD/gdbserver/gdbserver.py
index d9946fc..c54891e 100644 (file)
--- a/pyOCD/gdbserver/gdbserver.py
+++ b/pyOCD/gdbserver/gdbserver.py
@@ -77,6 +77,7 @@ class GDBServer(threading.Thread):
self.abstract_socket = GDBSocket(self.port, self.packet_size)
else:
self.abstract_socket = GDBWebSocket(self.wss_server)

```
   self.setDaemon(True)
 self.start()
```
def restart(self):
diff --git a/test/gdb_test.py b/test/gdb_test.py
index cdf4386..a13ef66 100644 (file)
--- a/test/gdb_test.py
+++ b/test/gdb_test.py
@@ -58,7 +58,8 @@ else:
logging.error("Port number error!")
except KeyboardInterrupt:
if gdb != None:
```
       gdb.stop()  
```
```
       gdb.shutdown_event.set()
```
```
       #gdb.stop()  
```
except Exception as e:
print "uncaught exception: %s" % e
traceback.print_exc()

Flash: LPC targets - flash blob - erase sector

#63 - a new feature requires to have erase sector available in flash blob. Kinetis devices already provide it, LPC should as well.

Hangs on waiting for USB device for mbed LPC1768

Looks like, on line 76 of pyusb_backend.py, none of my "interfaces" have interface class of 0x03, which causes basic_test.py to hang (stuck in the while loop at line 115 of mbed_board.py). With the LPC1768 connected, the interface.bInterfaceClass values are 0x8, 0x2, and 0xA.

This is on Arch Linux x86_64 with python 2.7.9

Data breakpoints

A nice feature to have would be data breakpoints. Has anyone looked into what it would take to add this? If I can find time I might try and implement it.

Execute original code when programing flash

I noticed that there are several times of cmsis_dap reset during the flash operation conducted in pyOCD. They were initiated by calling to self.transport.reset()

The negative impact of these cmsis_dap reset is that they doesn't stop at reset handler. Instead they a few mini-seconds before other resets happens (for example NVIC_AIRCR_SYSRESETREQ), and resulted some output to serial line that I don't expect on lpc1768. The behavior is:

connect via pyOCD and gdb
gdb initiate load command
pyOCD reset target by flash.init->setTargetState->self.reset()->self.transport.reset()
target runs for a while, producing unexpected output (people don't expect original program still runs when flashing it)
execution stop when
self.writeMemory(DHCSR, DBGKEY | C_DEBUGEN)
self.writeMemory(DEMCR, VC_CORERESET)
self.writeMemory(NVIC_AIRCR, NVIC_AIRCR_VECTKEY | NVIC_AIRCR_SYSRESETREQ)

Here are my questions:
a. Why it is need to reset cmsis_dap in a flash operation?
b. If A is necessary, is there any way to halt the execution once cmsis_dap resets?
c. What's difference between NVIC_AIRCR_SYSRESETREQ (local reset) and SWJ nRESET (cmsis_dap reset)?

Error shutting down PyOCD after disconnecting device

Not sure if you care about fixing this, but I thought I'd report it just in case:

Interrupted while waiting for the program.
Give up (and stop debugging it)? (y or n) y
> Quit
> quit
info: GDB server thread killed
error: exception during uninit
Process Process-1:
Traceback (most recent call last):
  File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/multiprocessing/process.py", line 258, in _bootstrap
    self.run()
  File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/multiprocessing/process.py", line 114, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/local/lib/python2.7/site-packages/valinor-0.0.6-py2.7.egg/valinor/gdb.py", line 47, in _launchPyOCDGDBServer
    gdb.stop()
  File "/usr/local/lib/python2.7/site-packages/pyOCD/gdbserver/gdbserver.py", line 75, in stop
    self.board.uninit()
  File "/usr/local/lib/python2.7/site-packages/pyOCD/board/board.py", line 82, in uninit
    self.transport.uninit()
  File "/usr/local/lib/python2.7/site-packages/pyOCD/transport/cmsis_dap.py", line 129, in uninit
    dapDisconnect(self.interface)
  File "/usr/local/lib/python2.7/site-packages/pyOCD/transport/cmsis_dap_core.py", line 134, in dapDisconnect
    if resp[0] != COMMAND_ID['DAP_DISCONNECT']:
IndexError: list index out of range

nrf51822 support is broken

Hi,

It looks like there is not way to use pyOCD with nrf51822…
I’m confused. Does majority use Keil for offline development? o_0
Issue 1 is relatively easy to fix but 2 is ultimate showstopper 8(
I’ve also tested it with FTDI based debugger and openocd.
It requires extra "monitor halt” after loading firmware but it works perfectly after that.

There are few issues regarding to using it with gdb:

1) pyOCD hangs during "load" command:
How to reproduce:

➜ python gdb_server.py -t nrf51822 -d debug
Welcome to the PyOCD GDB Server Beta Version
INFO:root:new board id detected: 107002161FE6E019E20F0F91
id => usbinfo | boardname
0 => MB MBED CM (0xd28, 0x204) [nrf51822]
DEBUG:root:init board <pyOCD.board.mbed_board.MbedBoard object at 0x10ebfb210>
INFO:root:DAP SWD MODE initialised
INFO:root:IDCODE: 0xBB11477
INFO:root:4 hardware breakpoints, 0 literal comparators
DEBUG:root:fpb has been disabled
INFO:root:CPU core is Cortex-M0
INFO:root:GDB server started at port:3333
INFO:root:One client connected!
DEBUG:root:GDB received query: ['Supported', 'multiprocess+;qRelocInsn+#2a']
DEBUG:root:gdb client has ack!
DEBUG:root:gdb client has ack!
DEBUG:root:GDB received query: ['Xfer', 'features', 'read', 'target.xml', '0,7fb#4a']
DEBUG:root:GDB query read_feature: offset: 0, size: 2043
DEBUG:root:gdb client has ack!
DEBUG:root:GDB lastSignal: 11
DEBUG:root:gdb client has ack!
....
DEBUG:root:gdb client has ack!
DEBUG:root:flash op: FlashErase
DEBUG:root:fpb has been enabled

Connect gdb:

(gdb) target remote :3333
Remote debugging using :3333
0xfffffffe in ?? ()
(gdb) load

pyOCD hangs in target_nrf51822.py resetStopOnReset():

        # set a breakpoint to the reset handler and reset the target
        self.setBreakpoint(reset_handler)
        self.reset()

        # wait until the bp is reached
        while (self.getState() == TARGET_RUNNING):
            pass

How to fix:
Halt CPU instead of reset once set breakpoint.

diff --git a/pyOCD/target/target_nrf51822.py b/pyOCD/target/target_nrf51822.py
index b9a815f..a7c6b19 100644
--- a/pyOCD/target/target_nrf51822.py
+++ b/pyOCD/target/target_nrf51822.py
@@ -48,13 +48,12 @@ class NRF51822(CortexM):
         # read address of reset handler
         reset_handler = self.readMemory(4)

-        # reset and halt the target
-        self.reset()
+        # halt the target
         self.halt()

         # set a breakpoint to the reset handler and reset the target
         self.setBreakpoint(reset_handler)
-        self.reset()
+        self.halt()

         # wait until the bp is reached
         while (self.getState() == TARGET_RUNNING):

2) pyOCD crashes while debugging BLE application with softdevice:
I embed sofdevice into elf file as proposed here: https://devzone.nordicsemi.com/question/14167/update-softdevice-in-mbed-kit/

Here is an example of connecting to running target:

(gdb) target remote :3333
Remote debugging using :3333
0x00002da2 in ?? ()
(gdb) break main
Breakpoint 2 at 0x1635c: file ../main.c, line 730.
(gdb) c
Continuing.
Remote connection closed
(gdb)

There wis hidden issue.
If load app and then immediately run “continue” app falls to “hard fault_handler” or some other place.
It happens because gdb set PC to 0x19ccc - Reset_Handler (in my case). So if execute app from this address soft device fails to init.
If set PC to “0” then app works fine but pyOCD gets “SWD Fault”.

pyOCD debug output:

➜ python gdb_server.py -t nrf51822 -d debug
Welcome to the PyOCD GDB Server Beta Version
INFO:root:new board id detected: 107002161FE6E019E20F0F91
id => usbinfo | boardname
0 => MB MBED CM (0xd28, 0x204) [nrf51822]
DEBUG:root:init board <pyOCD.board.mbed_board.MbedBoard object at 0x10ab5a210>
INFO:root:DAP SWD MODE initialised
INFO:root:IDCODE: 0xBB11477
INFO:root:4 hardware breakpoints, 0 literal comparators
DEBUG:root:fpb has been disabled
INFO:root:CPU core is Cortex-M0
INFO:root:GDB server started at port:3333
INFO:root:One client connected!
DEBUG:root:GDB received query: ['Supported', 'multiprocess+;qRelocInsn+#2a']
DEBUG:root:gdb client has ack!
DEBUG:root:gdb client has ack!
DEBUG:root:GDB received query: ['Xfer', 'features', 'read', 'target.xml', '0,7fb#4a']
DEBUG:root:GDB query read_feature: offset: 0, size: 2043
DEBUG:root:gdb client has ack!
DEBUG:root:GDB lastSignal: 17
DEBUG:root:gdb client has ack!
DEBUG:root:gdb client has ack!
DEBUG:root:GDB received query: ['C#b4']
DEBUG:root:gdb client has ack!
DEBUG:root:GDB received query: ['Attached#8f']
DEBUG:root:gdb client has ack!
DEBUG:root:GDB received query: ['Offsets#4b']
DEBUG:root:gdb client has ack!
DEBUG:root:GDB reg: r0 = 0xE000ED00
DEBUG:root:GDB reg: r1 = 0x0
DEBUG:root:GDB reg: r2 = 0x2
DEBUG:root:GDB reg: r3 = 0x0
DEBUG:root:GDB reg: r4 = 0x20000040
DEBUG:root:GDB reg: r5 = 0x40000100
DEBUG:root:GDB reg: r6 = 0x1
DEBUG:root:GDB reg: r7 = 0x0
DEBUG:root:GDB reg: r8 = 0xFFFFFFFF
DEBUG:root:GDB reg: r9 = 0xFFFFFFFF
DEBUG:root:GDB reg: r10 = 0x1FFF4000
DEBUG:root:GDB reg: r11 = 0x0
DEBUG:root:GDB reg: r12 = 0x1
DEBUG:root:GDB reg: sp = 0x20003E70
DEBUG:root:GDB reg: lr = 0x2D59
DEBUG:root:GDB reg: pc = 0x2DA2
DEBUG:root:gdb client has ack!
DEBUG:root:GDB received query: ['Xfer', 'memory-map', 'read', '', '0,7fb#e9']
DEBUG:root:GDB query memory_map: offset: 0, size: 2043
DEBUG:root:gdb client has ack!
DEBUG:root:get 2 bytes at 0x2da2: 0x686F
DEBUG:root:get 2 bytes at 0x2da4: 0x2F00
DEBUG:root:gdb client has ack!
DEBUG:root:GDB received query: ['Symbol', '', '#5b']
DEBUG:root:gdb client has ack!
DEBUG:root:GDB received query: ['TStatus#49']
DEBUG:root:gdb client has ack!
DEBUG:root:GDB: read reg 16: 0x6100000B
DEBUG:root:gdb client has ack!
DEBUG:root:get 2 bytes at 0x1635e: 0x4CA0
DEBUG:root:gdb client has ack!
DEBUG:root:get 2 bytes at 0x16360: 0xB0BD
DEBUG:root:gdb client has ack!
DEBUG:root:get 2 bytes at 0x1635e: 0x4CA0
DEBUG:root:gdb client has ack!
DEBUG:root:get 2 bytes at 0x16360: 0xB0BD
DEBUG:root:gdb client has ack!
DEBUG:root:get 2 bytes at 0x1635c: 0xB5F0
DEBUG:root:gdb client has ack!
DEBUG:root:GDB received query: ['TStatus#49']
DEBUG:root:gdb client has ack!
DEBUG:root:GDB received query: ['TStatus#49']
DEBUG:root:gdb client has ack!
DEBUG:root:fpb has been enabled
DEBUG:root:gdb client has ack!
DEBUG:root:flash op: Cont?#49
DEBUG:root:gdb client has ack!
DEBUG:root:gdb client has ack!
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 808, in __bootstrap_inner
    self.run()
  File "/Library/Python/2.7/site-packages/pyOCD/gdbserver/gdbserver.py", line 164, in run
    [resp, ack, detach] = self.handleMsg(data)
  File "/Library/Python/2.7/site-packages/pyOCD/gdbserver/gdbserver.py", line 230, in handleMsg
    return self.resume()
  File "/Library/Python/2.7/site-packages/pyOCD/gdbserver/gdbserver.py", line 279, in resume
    hardfault_handler = self.target.readMemory(4*3)
  File "/Library/Python/2.7/site-packages/pyOCD/target/cortex_m.py", line 388, in readMemory
    return self.transport.readMem(addr, transfer_size)
  File "/Library/Python/2.7/site-packages/pyOCD/transport/cmsis_dap.py", line 139, in readMem
    [addr])
  File "/Library/Python/2.7/site-packages/pyOCD/transport/cmsis_dap_core.py", line 207, in dapTransfer
    raise ValueError('SWD Fault')
ValueError: SWD Fault

3) I use HIDAPI so this backend doesn't have .open() method.
So I commented it out to run on Mac. All this issues were tested on Windows as well.

Regards

Failed "load" command on gdb_test.py

Hi
I added new target for W7500 of WIZnet MCU. And then I success automated_test.py on pyOCD.

Get fail message when I enter load command on GNU gdb

After automated_test , I tried to test "gdb_test.py". connection is success to gdb server of pyOCD. But I got a fail message when issue "load" command. This picture is log message when I tested.
Left terminal in this picture is log message when I run gdb_test.py and right terminal is log message of GNU gdb.

I want to know Why can't success after load command. If analyzer_supported is false in flash_w7500.py, Can't it use gdb for debugging W7500?

And How to solve this problem?

Can't load a binary on OS X 10.10.3

Trying to use gdb 'load', with a pyocdgdbserver (the target is a K64F board):

> load
Loading section .isr_vector, size 0x198 lma 0x0
Loading section .flash_protect, size 0x10 lma 0x400
Loading section .text, size 0x2b8e8 lma 0x420
Loading section .ARM.extab, size 0xdc lma 0x2bd08
Loading section .ARM.exidx, size 0x1b0 lma 0x2bde4
Loading section .data, size 0xa60 lma 0x2bf94
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 810, in __bootstrap_inner
    self.run()
  File "/usr/local/lib/python2.7/site-packages/pyOCD/gdbserver/gdbserver.py", line 153, in run
    [resp, ack, detach] = self.handleMsg(data)
  File "/usr/local/lib/python2.7/site-packages/pyOCD/gdbserver/gdbserver.py", line 220, in handleMsg
    return self.flashOp(msg[2:]), 1, 0
  File "/usr/local/lib/python2.7/site-packages/pyOCD/gdbserver/gdbserver.py", line 380, in flashOp
    self.flash.init()
  File "/usr/local/lib/python2.7/site-packages/pyOCD/flash/flash.py", line 45, in init
    self.target.writeBlockMemoryAligned32(self.flash_algo['load_address'], self.flash_algo['instructions'])
  File "/usr/local/lib/python2.7/site-packages/pyOCD/target/cortex_m.py", line 646, in writeBlockMemoryAligned32
    self.transport.writeBlock32(addr, data[:n/4])
  File "/usr/local/lib/python2.7/site-packages/pyOCD/transport/cmsis_dap.py", line 191, in writeBlock32
    dapTransferBlock(self.interface, len(data), WRITE | AP_ACC | AP_REG['DRW'], data)
  File "/usr/local/lib/python2.7/site-packages/pyOCD/transport/cmsis_dap_core.py", line 227, in dapTransferBlock
    max_pending_reads = interface.getPacketCount()
  File "/usr/local/lib/python2.7/site-packages/pyOCD/interface/interface.py", line 48, in getPacketCount
    return self.packet_count
AttributeError: 'HidApiUSB' object has no attribute 'packet_count'

Lack of flash_algo['instructions'] source code and related documents

pyOCD\flash\flash_*.py has flash_algo['instructions'] code which is device dependent. There is no source code avaiable, which limits its coverage in new microcontrollers.

It is better to include source code and necessary documents in an open source project.

Flash: Kinetis flash blobs require to be updated

As pinpointed in #63, the current flash blobs for kinetis devices are not correct.

We should rebuild all of them from the latest master of mbed cmsis dap repository.

New target: LPC 824

As there's a new pull request for LPC 824 MAX board, https://github.com/mbedmicro/CMSIS-DAP/pull/72

pyOCD should contain this target to be able to test mbed CMSIS-DAP implementation.

Readme: Update up to the commit 65dd5a0189

I noticed scripts were updated and readme still contains older information.

Review what has changed and update the readme.

pyOCD crashes when GDB issues the load command.

When I issue load from the gdb console, pyOCD emits the following block and crashes.

Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/local/Cellar/python/2.7.8_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 810, in __bootstrap_inner
    self.run()
  File "/usr/local/lib/python2.7/site-packages/pyOCD/gdbserver/gdbserver.py", line 152, in run
    [resp, ack, detach] = self.handleMsg(data)
  File "/usr/local/lib/python2.7/site-packages/pyOCD/gdbserver/gdbserver.py", line 219, in handleMsg
    return self.flashOp(msg[2:]), 1, 0
  File "/usr/local/lib/python2.7/site-packages/pyOCD/gdbserver/gdbserver.py", line 360, in flashOp
    self.flashBuilder.addData(write_addr, self.unescape(data[idx_begin:len(data) - 3]))
  File "/usr/local/lib/python2.7/site-packages/pyOCD/flash/flash_builder.py", line 115, in addData
    operation.addr, operation.addr + len(operation.data)))
ValueError: Error adding data - Data at 0x0..0x198 overlaps with 0x0..0x198

The context may be relevant. On gdb, the command sequence is:

target remote :3333
(gdb) load
(gdb) c
^C
Program received signal SIGINT, Interrupt.
(gdb) load

Test binary for each development board rather than each processor

Currently when pyOCD finishes basic_test.py it will program a new image to flash. Right now this image is determined by the processor type. The problem I'm concerned with is that several development kits can have the same processor, but have pins routed to different hardware. Because of this, an image that caused an led to blink on one device could sink current into a button an another. Would it be a change for the better to modify pyOCD to use a test binary for each development board rather than each processor?

Board ID

Where can I get board IDs?

I can see the list in pyOCD and know that they are compiled into the CMSIS DAP firmware. But I didn't find the information how to get a new one.

Regards
Olaf

nrf51822 mkit flash/erase/load freezing

I grabbed the newest source last night and had success for the first time with my nrf51822 board! However I went back to work this morning (havent changed any of your code, and pulled again just to see and there arent any changes) and I cant actually flash/erase/load etc anymore. Its freezing a lot like the source did before the recent fixes... But like I said I was completely successful yesterday!? I also noticed you put out a binary this morning and grabbed that and its the same. It definately seems to be my hardware. Its like I bricked or locked my chip or something.

jacob-2:pyOCD jacobrosenthal$ python test/gdb_server.py -d debug
Welcome to the PyOCD GDB Server Beta Version 
INFO:root:new board id detected: 107002161FE6E019E20F0F91
id => usbinfo | boardname
0 => MB MBED CM (0xd28, 0x204) [nrf51822]
DEBUG:root:init board <pyOCD.board.mbed_board.MbedBoard object at 0x10b57a450>
INFO:root:DAP SWD MODE initialised
INFO:root:IDCODE: 0xBB11477
INFO:root:4 hardware breakpoints, 0 literal comparators
DEBUG:root:fpb has been disabled
INFO:root:CPU core is Cortex-M0
INFO:root:GDB server started at port:3333
INFO:root:One client connected!
DEBUG:root:GDB received query: ['Supported', 'qRelocInsn+#9a']
DEBUG:root:gdb client has ack!
DEBUG:root:gdb client has ack!
DEBUG:root:GDB received query: ['Xfer', 'features', 'read', 'target.xml', '0,7fb#4a']
DEBUG:root:GDB query read_feature: offset: 0, size: 2043
DEBUG:root:gdb client has ack!
DEBUG:root:GDB lastSignal: 11
DEBUG:root:gdb client has ack!
DEBUG:root:gdb client has ack!
DEBUG:root:GDB received query: ['C#b4']
DEBUG:root:gdb client has ack!
DEBUG:root:GDB received query: ['Attached#8f']
DEBUG:root:gdb client has ack!
DEBUG:root:GDB received query: ['Offsets#4b']
DEBUG:root:gdb client has ack!
DEBUG:root:GDB reg: r0 = 0xFFFFFFFF
DEBUG:root:GDB reg: r1 = 0xFFFFFFFF
DEBUG:root:GDB reg: r2 = 0xFFFFFFFF
DEBUG:root:GDB reg: r3 = 0xFFFFFFFF
DEBUG:root:GDB reg: r4 = 0xFFFFFFFF
DEBUG:root:GDB reg: r5 = 0xFFFFFFFF
DEBUG:root:GDB reg: r6 = 0xFFFFFFFF
DEBUG:root:GDB reg: r7 = 0xFFFFFFFF
DEBUG:root:GDB reg: r8 = 0xFFFFFFFF
DEBUG:root:GDB reg: r9 = 0xFFFFFFFF
DEBUG:root:GDB reg: r10 = 0xFFFFFFFF
DEBUG:root:GDB reg: r11 = 0xFFFFFFFF
DEBUG:root:GDB reg: r12 = 0xFFFFFFFF
DEBUG:root:GDB reg: sp = 0x30323018
DEBUG:root:GDB reg: lr = 0xFFFFFFF9
DEBUG:root:GDB reg: pc = 0xFFFFFFFE
DEBUG:root:gdb client has ack!
DEBUG:root:GDB received query: ['Xfer', 'memory-map', 'read', '', '0,7fb#e9']
DEBUG:root:GDB query memory_map: offset: 0, size: 2043
DEBUG:root:gdb client has ack!
DEBUG:root:GDB received query: ['Symbol', '', '#5b']
DEBUG:root:gdb client has ack!
DEBUG:root:GDB received query: ['TStatus#49']
DEBUG:root:gdb client has ack!
DEBUG:root:flash op: FlashErase
DEBUG:root:fpb has been enabled




jacob-2:pyOCD jacobrosenthal$ arm-none-eabi-gdb /Users/jacobrosenthal/Desktop/untitled\ folder\ 2/untitled\ folder/nrf51/SDK/nrf51_sdk_v6_1_0_b2ec2e6/nrf51822/Board/nrf6310/s110/ble_app_hids_keyboard/_build/ble_app_hids_keyboard_s110_xxaa.elf
GNU gdb (GNU Tools for ARM Embedded Processors) 7.4.1.20121207-cvs
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-apple-darwin10 --target=arm-none-eabi".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /Users/jacobrosenthal/Desktop/untitled folder 2/untitled folder/nrf51/SDK/nrf51_sdk_v6_1_0_b2ec2e6/nrf51822/Board/nrf6310/s110/ble_app_hids_keyboard/_build/ble_app_hids_keyboard_s110_xxaa.elf...done.
(gdb) target remote localhost:3333
Remote debugging using localhost:3333
0xfffffffe in ?? ()
(gdb) load

and heres a flash with debug on, but freezes forever after GET Unique ID

jacob-2:pyOCD jacobrosenthal$ python test/flash_tool.py -e
INFO:root:new board id detected: 107002161FE6E019E20F0F91
id => usbinfo | boardname
0 => MB MBED CM (0xd28, 0x204) [nrf51822]
DEBUG:root:init board <pyOCD.board.mbed_board.MbedBoard object at 0x1009d5d90>
INFO:root:DAP SWD MODE initialised
INFO:root:IDCODE: 0xBB11477
INFO:root:4 hardware breakpoints, 0 literal comparators
DEBUG:root:fpb has been disabled
INFO:root:CPU core is Cortex-M0


------ GET Unique ID ------
Unique ID: 107002161FE6E019E20F0F91
DEBUG:root:fpb has been enabled

USB device busy for some reason

Hi,

I find that in pyusb_backend.py function. If there's no usb devices connected, all_devices = usb.core.find(find_all=True, idVendor=vid, idProduct=pid) will return [] to all_mbeds instead of None with Python2.7. This bug will leads to the mbed_board.py to call pyusb_backend continuously, which will block new mbed devices to be detect in sometimes.

So I advise that to modify like this:
--- a/pyOCD/interface/pyusb_backend.py
+++ b/pyOCD/interface/pyusb_backend.py
@@ -55,12 +55,12 @@ class PyUSB(Interface):
# find all devices matching the vid/pid specified
all_devices = usb.core.find(find_all=True, idVendor=vid, idProduct=pid)

```
   if all_devices is None:
```

   if (all_devices == []) | (all_devices is None):
     logging.debug("No device connected")
     return None

gdb_server - K64F - ValueError: The device does not support the specified langid

I cloned the pyusb and pyOCD, and installed those.

Connected K64F board.

sudo python test/gdb_server.py 
Welcome to the PyOCD GDB Server Beta Version 
INFO:root:Waiting for a USB device connected
uncaught exception: The device does not support the specified langid
Traceback (most recent call last):
  File "test/gdb_server.py", line 62, in <module>
    board_selected = MbedBoard.chooseBoard(board_id = option.board_id, target_override = option.target_override, frequency = option.debug_clock_frequency)
  File "/usr/local/lib/python2.7/dist-packages/pyOCD/board/mbed_board.py", line 201, in chooseBoard
    all_mbeds = MbedBoard.getAllConnectedBoards(transport, False, blocking, target_override, frequency)
  File "/usr/local/lib/python2.7/dist-packages/pyOCD/board/mbed_board.py", line 148, in getAllConnectedBoards
    all_mbeds = INTERFACE[usb_backend].getAllConnectedInterface(mbed_vid, mbed_pid)
  File "/usr/local/lib/python2.7/dist-packages/pyOCD/interface/pyusb_backend.py", line 111, in getAllConnectedInterface
    product_name = usb.util.get_string(board, 256, 2)
  File "/usr/local/lib/python2.7/dist-packages/usb/util.py", line 328, in get_string
    raise ValueError("The device does not support the specified langid")
ValueError: The device does not support the specified langid

Dump stack and objects on crash for post-mortem debugging

To aid in debugging crashes it would be very useful to have code which dumped the stack and state of the system to a file to allow for post-mortem debugging. This would allow complex crashes to be fixed, along with one-time crashes such as #134. Is anyone familiar with post-mortem debugging in python? @adamgreen , I heard you might have some knowledge in this area.

Error loading .ELF via gdb_server on FRDM-K64F

I built some examples from the Freescale KSDK 1.2 and I'm trying to load one in particular (httpsrv) but it crashes the GDB server when I do. Here's the output from gdbserver:

± python test/gdb_server.py
Welcome to the PyOCD GDB Server Beta Version 
INFO:root:new board id detected: 02400221C3163E593EC8C3E1
INFO:root:board allows 5 concurrent packets
INFO:root:DAP SWD MODE initialised
INFO:root:IDCODE: 0x2BA01477
INFO:root:K64F not in secure state
INFO:root:6 hardware breakpoints, 4 literal comparators
INFO:root:CPU core is Cortex-M4
INFO:root:FPU present
INFO:root:4 hardware watchpoints
INFO:root:GDB server started at port:3333
INFO:root:One client connected!
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 810, in __bootstrap_inner
    self.run()
  File "/Users/thom/dev/sandbox/kinetis/pyOCD/lib/python2.7/site-packages/pyOCD/gdbserver/gdbserver.py", line 152, in run
    [resp, ack, detach] = self.handleMsg(data)
  File "/Users/thom/dev/sandbox/kinetis/pyOCD/lib/python2.7/site-packages/pyOCD/gdbserver/gdbserver.py", line 219, in handleMsg
    return self.flashOp(msg[2:]), 1, 0
  File "/Users/thom/dev/sandbox/kinetis/pyOCD/lib/python2.7/site-packages/pyOCD/gdbserver/gdbserver.py", line 360, in flashOp
    self.flashBuilder.addData(write_addr, self.unescape(data[idx_begin:len(data) - 3]))
  File "/Users/thom/dev/sandbox/kinetis/pyOCD/lib/python2.7/site-packages/pyOCD/gdbserver/gdbserver.py", line 412, in unescape
    data[data_idx] = data[data_idx] ^ 0x20
IndexError: list index out of range

And on the gdb client side:

$ $ARMGCC_DIR/bin/arm-none-eabi-gdb httpsrv.elf         
GNU gdb (GNU Tools for ARM Embedded Processors) 7.6.0.20140731-cvs

(...... GDB header output ......)

(gdb) target remote localhost:3333
Remote debugging using localhost:3333
0x00003124 in CLOCK_HAL_GetPll0Clk (base=0x4006a000)
    at /Users/thom/dev/sandbox/kinetis/ksdk/KSDK_1.2.0/platform/hal/src/mcg/fsl_mcg_hal.c:525
525     if (!(MCG_BRD_S_PLLST(base) || MCG_BRD_C5_PLLCLKEN0(base)))
(gdb) load
Loading section .interrupts, size 0x400 lma 0x0
Loading section .flash_config, size 0x10 lma 0x400
Loading section .text, size 0x414c0 lma 0x410
Remote connection closed
(gdb)

Here's a link to the .elf file in question: http://s000.tinyupload.com/?file_id=28283428874542781329
I've had luck with other sample apps from the KSDK so not sure why this one in particular is causing an issue. It is a bit large.