pyOCD | Open source Python library | Code Inspection library

You 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.

I 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.

In 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", ),

Seems like a bug in the package: https://github.com/mbedmicro/pyOCD/issues/442

I 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.

It's an example, and they included the expected output in the text.

So the line