Troubleshooting

The MCUHex SDK is not running on this computer.

This version of MCUHex sends the firmware to the SDK, and the SDK running here is old enough to still expect a file path instead. Nothing was written to the chip.

The MCUHex SDK stopped responding — it was quit or it crashed.

The SDK is running but no debug probes were detected.

Windows sees the probe, but no WinUSB driver is bound to it, so pyOCD cannot open it. The probe and the cable are fine.

Please select a device before connecting.

Another tool or debugger is connected to this device.

Access to the probe was refused — usually because another debugger already has it open.

Another tool already holds this probe — an IDE debug session, STM32CubeProgrammer, or a second MCUHex window.

The device is plugged in and enumerated, but it speaks over a path MCUHex has no driver for. Debugging today goes through SWD, over a CMSIS-DAP or ST-Link probe.

This probe's firmware predates the protocol the debug library speaks.

The selected probe driver does not match the connected hardware.

The device did not respond in time.

The USB device was removed during the session.

Could not read or write to the device memory.

The SDK did not respond to a command in time.

An unexpected error occurred.

The probe is working, but nothing answered on the SWD lines. The chip is unpowered, not wired to the probe, or its SWD pins have been switched to something else by the firmware on it.

The chip answered but no Cortex-M core was found behind its debug port. This is what a chip held in reset, or one whose core domain is unpowered, looks like from here.

The chip refused to power its debug unit. Usually the board is browning out, or the probe is reading the wrong target voltage.

The debug port answered and refused the access. That is what read-out protection looks like: STM32 RDP level 1, Nordic APPROTECT, Kinetis FSEC.

A wire-level fault occurred on the SWD/JTAG interface.

The target MCU is being held in reset and cannot communicate.

The target is running and memory cannot be accessed safely.

The target flash region is write-protected.

pyOCD knows which MCU this is but has no support pack for it installed.

The target MCU has entered a HardFault exception.

The selected firmware file does not exist on the SDK host.

Only .hex, .bin, .elf, and .axf firmware files are supported.

The programmed data does not match the source file.

Another flash operation is already running.

Connect to a debug probe before flashing.

The flash operation was cancelled.

PyOCD reports no programmable flash region for this target, so there is nothing to write firmware into.

Part of the image is addressed outside the memory this target has, so writing it would leave the chip with an incomplete firmware.

The chip on the board reports less flash than the part chosen for it has. Programming it with the wrong geometry would erase it against the wrong map, and that cannot be undone, so nothing was written.

The flash controller rejected a page write (PGSERR). Usually this means the target is running, write-protected, or requires a full chip erase before re-programming.

The flash controller rejected an erase, before anything new was written. What was on the chip is still there.

The image has to travel to the SDK before it can be programmed, and this one is over the 16 MB that fits in one transfer. An ELF carrying full debug symbols is usually what pushes it over — the part that gets programmed is a fraction of that.

The file has no contents, so there is nothing to program. A build that failed often leaves a zero-byte artifact behind where the firmware should be.

The image was rejected before programming started, so the chip is untouched.

Support for a chip is downloaded from the CMSIS-Pack servers the first time you pick it, and nothing on this machine is reaching the internet. Nothing was installed and nothing was changed.

Support for a chip is downloaded from the CMSIS-Pack servers the first time you pick it. This machine is online, but that download could not reach them, so nothing was installed and nothing was changed.

The pack download stopped because the folder it is cached in has no space left. Packs run from a few megabytes to a few hundred.

Chip support is cached in a folder under your user account. That folder refused to be written to, so the download had nowhere to go.

The component that fetches CMSIS-Pack files is missing from this MCUHex install, so no new chip can be added. Chips pyOCD already ships still work.

The SDK checks the CMSIS-Pack index against the vendor’s own list before trusting it. Some descriptors served from keil.com could not be downloaded, so the parts they cover — STM32 families among them — may be missing from this list.

Only .elf and .out files are supported.

Files must be under 32 MB.

The file could not be parsed for debug symbols.

The server took too long to process this file.

The file could not be uploaded to the server.

Could not reach the server.

You need to sign in to upload and parse files.

You have uploaded 10 files today. The counter resets at 00:00 UTC.

An unexpected error occurred.