pyOCD | Open source Python library | Code Inspection library
kandi X-RAY | pyOCD Summary
Support
Quality
Security
License
Reuse
Currently covering the most popular Java, JavaScript and Python libraries. See a Sample Here
pyOCD Key Features
pyOCD Examples and Code Snippets
Trending Discussions on pyOCD
Trending Discussions on pyOCD
QUESTION
I followed the adacore tutorial on displaying scrolling text (https://blog.adacore.com/ada-for-microbit-part-1-getting-started) but can't get it working on my microbit.
Maybe my microbit is a more recent version that is not yet supported? The reason I suspect this is that my board id (9904) was not supported the first time I tried to flash to the board. I used the fix described here: Unable to get the Ada scrolling text demo working on the microbit on GNAT 2019 community edition and added the following line in board_ids.py:
"9904": BoardInfo( "micro:bit", "nrf51", "l1_microbit.bin", ),
After doing this, I was able to flash the scrolling text example to the board, but I had the following warning:
0000601:WARNING:common:STLink and CMSIS-DAPv2 probes are not supported because no libusb library was found.
The problem now is that only one LED lights up. It seems as though that single LED lights up correctly according to the input text based on its blinking pattern. I'm not sure whether the libusb warning is what is causing the problem.
I'm using the GNAT 2020 version of x86_64 and the arm-elf. I've been stuck on this for a while and would appreciate any suggestions. Thanks!
Edits:
I'm on windows 10.
I don't think the problem is to do with pyocd/libusb because I no longer get any warnings when flashing to the board, after ensuring I have a libusb dll in the same directory as the python exe in GNAT. The scrolling text example is still not working (only one LED lighting up).
I also tried this on a different computer, with the same result.
From https://github.com/AdaCore/Ada_Drivers_Library/issues/379 it looks like the new versions of the board are not supported by the ada drivers library? But that issue concerns the accelerometer version, I'm not sure if it's the cause in my case.
ANSWER
Answered 2021-Jan-23 at 14:12libusb is missing or not found on your computer. It is used to communicate with the Microbit board to upload/debug.
QUESTION
I've successfully installed pyocd and libusb using powershell core and python 3.8 on windows 10, but when I use python -m pyocd list command, it throws this error:
PS C:\Users\mahya> python -m pyocd list
0003915:WARNING:common:STLink and CMSIS-DAPv2 probes are not supported because no libusb library was found.
No available debug probes are connected
ANSWER
Answered 2020-Sep-03 at 05:57You should copy the libusb.dll (libusb dynamic link library) to the path of python instalation. Note: if you've downloaded python from windows store, you should copy libusb.dll in C:/windows/system32 directory.
QUESTION
Note: Why this question is not off-topic
Some people seem to think this question is off-topic, and it would be better suited for Super User. Please give me a chance to explain why that's not the case.
The question is not about "general computing hardware" but about "embedded software". In the topic of "embedded software", there are tons of questions on StackOverflow related to OpenOCD, a popular open-source tool to connect your computer to embedded software development boards. All these questions are considered totally okay for StackOverflow. My question on this page is about PyOCD - an emerging OpenOCD alternative. So if you vote to close this question, then please also vote to close the 565 (!) other questions about OpenOCD too ;-)
I've got a NuMaker-M032SE V1.3 board from Nuvoton that I'm trying to flash/debug with PyOCD. It's my first time I'm experimenting with PyOCD and with Nuvoton chips. Unfortunately, PyOCD cannot find the device. I'll go step-by-step through the whole procedure. Please tell me what I did wrong.
1. My systemI'm running 64-bit Windows 10 on my desktop computer. I've got Python 3.8 and recently installed the latest PyOCD development version from a cloned GitHub repository (see https://github.com/mbedmicro/pyOCD).
2 Install Microcontroller boardNote: this paragraph is simply to show you the background situation, before I move on to explain the actual problem I got with PyOCD
I've got a Nuvoton NuMaker-M032SE V1.3 microcontroller board:
This board has a Nu-Link2-Me V1.0 probe on the right side. The first time I connect my board to my computer nothing really happened. So I figured out I had to install the Nuvoton ICP tool that comes with the Nu-Link USB Driver 1.6:
You can download the Nuvoton ICP tool here: https://www.nuvoton.com/hq/support/tool-and-software/development-tool-hardware/programmer/ When I first start the sofware, I see this:
And I get a request to update the firmware on the Nu-Link2-Me V1.0 probe:
I click OK and wait for the firmware update to complete. I plug out and back in the board. Windows clearly notices the device:
I can also see the device in my Control Panel > Device Manager. It's listed under Universal Serial Bus Controllers as Nuvoton Nu-Link2 USB:
3 Prepare PyOCDPyOCD has a few built-in targets. But not the Nuvoton chip I got. So I consulted the documentation at https://github.com/mbedmicro/pyOCD/blob/master/docs/target_support.md and learn that I need to download a pack from http://www.keil.com/dd2/pack/ . That's where I download the Nuvoton ARM Cortex-M NuMicro Family Device Support pack:
Because I downloaded the pack manually, I know that I'll have to add the parameter --pack="C:/path/to/pack/Nuvoton.NuMicro_DFP.1.3.5.pack" to every PyOCD command, to ensure that PyOCD can access this pack whenever it needs to.
I believe my microcontroller board is properly installed to go on to the final step: connect PyOCD to the Nuvoton microcontroller board.
First I want PyOCD to find the board. I issue the following command in a Windows console:
$ pyocd list --pack="C:/path/to/pack/Nuvoton.NuMicro_DFP.1.3.5.pack"
Unfortunately, I get the response:
No available debug probes are connected
I tried a few times, both with and without the --pack parameter. I always get the same error message.
Note:
I had expected to see something like:
# Probe Unique ID
---------------------------------------------------------------------------
0 ARM CMSIS-DAP v1 000000800a0c882800000000000000000000000097969902
That's the output I get when I issue the $ pyocd list command and I have my SWDAP probe connected to my computer. The SWDAP is the official probe from ARM (see https://os.mbed.com/components/SWDAP-LPC11U35/) that runs the DAPLink firmware (see https://github.com/ARMmbed/DAPLink).
ANSWER
Answered 2019-Dec-02 at 08:44I got a reply from Nuvoton. Apparently the NuMaker-M032SE V1.3 board is not yet supported in PyOCD at the time of writing (02 Dec 2019). At the moment, only NuMaker M252/M263 boards are supported.
Nuvoton will make efforts to support these boards in PyOCD too, in the future.
QUESTION
I'm trying to run the demo described here: https://blog.adacore.com/ada-on-the-microbit
I followed the tutorial's directions carefully. I did install the 2019 versions of the software instead of the 2018 versions. GPS seems to be installed and working on my windows 7 machine. The project builds but pyocd-flashtool can't seem to recognize my microbit. It reports it as a "generic cortex_m" and throws an exception.
Here's the output:
gprbuild --target=arm-eabi -d -PC:\Domains\ada\microbit_scrolling_text_demo\microbit_example.gpr
C:\Domains\ada\microbit_scrolling_text_demo\src\main.adb -largs -Wl,-Map=map.txt
Compile
[Ada] main.adb
Bind
[gprbind] main.bexch
[Ada] main.ali
Link
[link] main.adb
[2019-09-21 18:40:29] process terminated successfully, elapsed time: 02.57s
Retrieving the load address.
arm-eabi-objdump C:\Domains\ada\microbit_scrolling_text_demo\obj\main -h
Load address is: 0x00000000
Creating the binary (flashable) image.
arm-eabi-objcopy -O binary C:\Domains\ada\microbit_scrolling_text_demo\obj\main C:\Domains\ada\microbit_scrolling_text_demo\obj\main.bin
Flashing image to board...
pyocd-flashtool -a 0x00000000 C:\Domains\ada\microbit_scrolling_text_demo\obj\main.bin
WARNING:root:Unsupported board found 9901
INFO:root:DAP SWD MODE initialised
INFO:root:ROM table #0 @ 0xf0000000 cidr=b105100d pidr=2007c4001
INFO:root:[0]
INFO:root:ROM table #1 @ 0xe00ff000 cidr=b105100d pidr=4000bb471
INFO:root:[0]
INFO:root:[1]
INFO:root:[2]
INFO:root:[1]
INFO:root:CPU core is Cortex-M0
INFO:root:4 hardware breakpoints, 0 literal comparators
INFO:root:2 hardware watchpoints
Traceback (most recent call last):
File "C:\GNAT\2019\lib\runpy.py", line 162, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File "C:\GNAT\2019\lib\runpy.py", line 72, in _run_code
exec code in run_globals
File "C:\GNAT\2019\bin\pyocd-flashtool.exe\__main__.py", line 9, in
File "C:\GNAT\2019\lib\site-packages\pyOCD\tools\flash_tool.py", line 214, in main fast_verify=args.fast_program)
File "C:\GNAT\2019\lib\site-packages\pyOCD\flash\flash.py", line 286, in flashBlock flash_start = self.getFlashInfo().rom_start
File "C:\GNAT\2019\lib\site-packages\pyOCD\flash\flash_cortex_m.py", line 44, in getFlashInfo raise Exception("Unsupported flash operation on generic cortex_m")
Exception: Unsupported flash operation on generic cortex_m
Could not flash the executable.
[workflow stopped]
Anyone know what could be wrong?
ANSWER
Answered 2019-Sep-26 at 22:04In C:\GNAT\2019\lib\site-packages\pyOCD\board\mbed_board.py (or the equivalent location on your platform), add this line and it will work.
"9901": BoardInfo( "Microbit", "nrf51", "l1_microbit.bin", ),
QUESTION
I have encountered an error when installing yotta:
Command "python setup.py egg_info" failed with error code 1 in
/tmp/pip-install-t_jfni1z/pyOCD/
The complete error message goes on and on forever and eventually leads to this:
File "/tmp/pip-install-t_jfni1z/pyOCD/.eggs/setuptools_scm-3.1.0-py3.6.egg/setuptools_scm/__init__.py", line 72, in dump_version
with open(target, "w") as fp:
FileNotFoundError: [Errno 2] No such file or directory: 'pyocd/_version.py'
I have tried to reinstall pyocd, and pip, and python without any success. The error for pip install pyocd --user goes as follows:
FileNotFoundError: [Errno 2] No such file or directory: 'pyocd/_version.py'
Pretty much exactly the same error message, which led me to believe that I may have broke pip.
I am currently using Ubuntu 18.04 and python 2.7.
Is there a way for me to fix this without reinstalling the OS?
ANSWER
Answered 2018-Nov-13 at 00:10Seems like a bug in the package: https://github.com/mbedmicro/pyOCD/issues/442
QUESTION
Even though not every detail is relevant for this question, I will list my setup nonetheless:
- NUCLEO_F746ZG microcontroller board (https://os.mbed.com/platforms/ST-Nucleo-F746ZG/).
- I run mbed CLI (https://os.mbed.com/docs/v5.7/tools/arm-mbed-cli.html) to program the chip.
- My OS is Windows 10, 64-bit
To compile my code and flash the binary to the chip, I issue the following command in my cmd terminal:
> mbed compile -t GCC_ARM -m NUCLEO_F746ZG --flash
I get the following output:
...
+------------------+-------+-------+-------+
| Module | .text | .data | .bss |
+------------------+-------+-------+-------+
| [fill] | 130 | 4 | 10 |
| [lib]\c.a | 24965 | 2472 | 89 |
| [lib]\gcc.a | 3120 | 0 | 0 |
| [lib]\misc | 252 | 16 | 28 |
| mbed-os\drivers | 658 | 4 | 100 |
| mbed-os\features | 74 | 0 | 12556 |
| mbed-os\hal | 2634 | 4 | 66 |
| mbed-os\platform | 2977 | 4 | 270 |
| mbed-os\rtos | 15887 | 168 | 5989 |
| mbed-os\targets | 16013 | 4 | 1052 |
| source\main.o | 244 | 4 | 84 |
| Subtotals | 66954 | 2680 | 20244 |
+------------------+-------+-------+-------+
Total Static RAM memory (data + bss): 22924 bytes
Total Flash memory (text + data): 69634 bytes
Image: .\BUILD\NUCLEO_F746ZG\GCC_ARM\nucleo_f746zg_demo.bin
[mbed] Detected "NUCLEO_F746ZG" connected to "E:" and using com port "COM10"
1 file(s) copied.
I'm particularly interested in the last lines, where the actual flashing of the chip takes place:
Image: .\BUILD\NUCLEO_F746ZG\GCC_ARM\nucleo_f746zg_demo.bin
[mbed] Detected "NUCLEO_F746ZG" connected to "E:" and using com port "COM10"
1 file(s) copied.
I know from previous experience (before mbed CLI existed) that there is a lot going on to flash a binary to a chip. For example, I had to startup openocd, pass it a configuration file of the programmer (eg. stlink-v2-1.cfg) and a configuration file of the target board (eg. nucleo_f746zg.cfg). At last, I had to hand over the binary to openocd via a Telnet-session or a GDB-session. Everything is described extensively here: How to use the GDB (Gnu Debugger) and OpenOCD for microcontroller debugging - from the terminal?
Looking at mbed CLI flashing the chip, I get confused. What is happening on the background? Is mbed CLI secretly using openocd to connect to the chip? Or perhaps pyOCD? Or some other way?
ANSWER
Answered 2018-Feb-09 at 19:07I have not tried all of them but the first and certainly the mbed supported nucleo boards show up as a virtual thumb drive, and you simply copy the .bin file over, no real magic to it from the host side no other software required other than what the operating system already has with respect to mounting usb flash drives. There is a debug header on these boards, and even if not that there is for the ones I know an mcu that manages the debug part I call that the debug mcu, then there is the mcu under test or the demonstration one that you bought the board to play with. The mbed ones have generally been arm and there is an swd (jtag-ish) interface, the debug mcu very likely uses that interface.
openocd is just one tool that knows the swd protocol, that doesnt mean that they have to run openocd on the mcu. you can write your own software to bit bang or talk to an ftdi chip to use mpsse or other solution to generate the swd protocol transitions on that bus.
Simplest case the firmware for the specific nucleo board only has to know that one stm32 it is programming, doesnt have to know more than that, but one swd is somewhat generic and may make sense to have a more generic debug mcu firmware.
Now these NUCLEO and other STM32 debug mcus also speak stlink which is separate from the firmware looks like a thumb drive deal. Stlink a protocol that a host can use to ask the debug mcu to do stuff, just like mpsse is a protocol/instruction set that you use to ask some ftdi parts to do stuff for you (a bit different but in concept speak one protocol to a proxy agent that does something for you).
This mbed cli could possibly just be copying the file over for you which you could have just done yourself. Or maybe it is speaking some other protocol The first mbeds were based on NXP parts not ST and thus dont have the stlink protocol on the front end. They had/have the just copy the binary which I remember seeing someones blog have so maybe they hired that person or borrowed that open source project.
While the mbed sandbox may be great I recommend you try out the other options, first mbed to build the binary, then copy it over, mbed to build it and maybe openocd through stlink to write it to flash. ST and NXP parts have traditionally had a bootloader that would support a uart protocol you can try that, as that is something you would very likely use, or swd, to get into a chip on a board if you were working on some product built around or that used chips like these but was not some hobby/eval board like the nucleos. I also recommend trying baremetal without the libraries, just read the manual, I find that easier than the libraries, YMMV, also ST has at least one set of its own libraries I think they are in a transition between to software solutions, perhaps try both or try the new one as the other will lose support.
You can also get the SWD spec and there are github and other open projects that can help, take your nucleo board and develop a program on one mcu to talk to another (mcus have gpio making it an easy way to bit bang, you can bit bang an ftdi part or do other things dont have to use an mcu) and try to learn/understand that protocol itself. It is used by all the cortex-ms thus far.
There is also a usb protocol like stlink that is being pushed by arm, the newer MSP432 launchpads use it or support it. The stlink protocol itself for that matter.
Anyway I digress the nucleo through the (debug) usb has the stlink protocol and has the I am a thumb drive thing, so mbed tools are likely using one of those probably the latter since stlink is likely not found on non-st products. Very likely that the debug mcu is using swd to program the development/demonstration mcu, dont know how else it would be doing it.
QUESTION
When on GitHub, I stumbled upon this page (https://github.com/mbedmicro/pyOCD) which is there to help with using mbed boards. However, when i looked at their Hello World Example (below), i was real baffled. It uses an extremly odd python syntax (which is not valid as the complier threw an error).
Here it is :
from pyOCD.board import MbedBoard
import logging
logging.basicConfig(level=logging.INFO)
board = MbedBoard.chooseBoard()
target = board.target
flash = board.flash
target.resume()
target.halt()
print "pc: 0x%X" % target.readCoreRegister("pc")
pc: 0xA64
target.step()
print "pc: 0x%X" % target.readCoreRegister("pc")
pc: 0xA30
target.step()
print "pc: 0x%X" % target.readCoreRegister("pc")
pc: 0xA32
flash.flashBinary("binaries/l1_lpc1768.bin")
print "pc: 0x%X" % target.readCoreRegister("pc")
pc: 0x10000000
target.reset()
target.halt()
print "pc: 0x%X" % target.readCoreRegister("pc")
pc: 0xAAC
board.uninit()
My issue is the "pc: 0xAAC" lines which appear littered accross the code. Is this some special type of coding? It doesnt work, so would someone please point towards maybe what the author was trying to get at?
Thank you
ANSWER
Answered 2017-Jan-11 at 09:46It's an example, and they included the expected output in the text.
So the line
print "pc: 0x%X" % target.readCoreRegister("pc")
is expected to print something like
pc: 0xA64
So no, that's not valid Python code, and if you wanted to run the code yourself you should omit those lines.
They could have made this clearer by making those lines comments, of course, easily making the example runnable again:
print "pc: 0x%X" % target.readCoreRegister("pc")
# pc: 0xA64
Community Discussions, Code Snippets contain sources that include Stack Exchange Network
Vulnerabilities
No vulnerabilities reported
Install pyOCD
macOS: use Homebrew: brew install libusb
Linux: should already be installed.
Windows: download libusb from [libusb.info](https://libusb.info/) and place the DLL in your Python installation folder next to python.exe. Make sure to use the same 32- or 64-bit architecture as your Python installation. Note: due to a [known issue](https://github.com/mbedmicro/pyOCD/issues/684), the current recommendation is to use [libusb version 1.0.21](https://github.com/libusb/libusb/releases/tag/v1.0.21) on Windows instead of the most recent version.
Please see the [Developers' Guide](docs/developers_guide.md) for instructions on how to set up a development environment for pyOCD.
Support
Find, review, and download reusable Libraries, Code Snippets, Cloud APIs from over 650 million Knowledge Items
Find more librariesExplore Kits - Develop, implement, customize Projects, Custom Functions and Applications with kandi kits
Save this library and start creating your kit
Share this Page
