PICSimLab Simulation Not Running? Clock, Reset and Workspace Fixes

The firmware loads, you press run — and the board just sits there. No blinking, no output, no reaction to buttons. A dead-looking simulation in PICSimLab is usually one of four things: the simulation is not actually running, the board is held in reset or mis-clocked, the selected microcontroller does not match the firmware, or a saved workspace (.pzw) is restoring a broken configuration. Work through them in order.

Symptoms

  • The simulation window opens and the board is drawn, but nothing ever changes.
  • A program that visibly worked yesterday does nothing today, with no code changes.
  • Code runs, but absurdly slowly — a one-second blink takes many seconds.
  • Inputs (buttons, spare parts) have no effect at all.

Why it happens

The simulation is stopped or the board is in reset. PICSimLab can sit in a stopped state with the board fully drawn; a board held in reset executes nothing, just like real hardware.

Clock mismatch. PICSimLab boards have a configured crystal/clock, and PIC firmware is normally built with a matching assumption (in XC8, the _XTAL_FREQ value used for delay calculations). If the code assumes 20 MHz but the board is configured for a much lower clock, delays stretch by the same factor and a lively program can look frozen. The mismatch does not stop the CPU — it makes everything happen in slow motion.

Wrong microcontroller selected. If the selected board is set to a different MCU than the one the .hex was compiled for, the loaded firmware does not correspond to the simulated chip and the board stays inert (see also our guide on .hex files not loading — searching this site for “hex file not loading” finds it).

A corrupted or mismatched workspace. A .pzw workspace file saves the board, its configuration and the loaded setup. If that file was saved from a different board setup, or was damaged, reopening it can faithfully restore a configuration in which nothing works — the file loads fine, the setup it describes does not.

Fix

  1. Start the simulation and pulse reset. Make sure the simulation is in the running state, then reset the board once and watch for the program’s start-up behaviour (most example programs blink or initialise outputs immediately).
  2. Verify board + MCU against the firmware. The selected board and microcontroller must be exactly the chip the .hex was built for. After any board change, load the .hex again.
  3. Check the clock. Compare the board’s configured crystal frequency with the frequency your code was built for (for XC8 projects, the _XTAL_FREQ define). Align them — either set the board clock to the value the code expects, or rebuild the code with the board’s frequency — and re-test: correct timing returning is the confirmation.
  4. Recover from a bad workspace. Close PICSimLab, reopen it without loading your .pzw file, select the board and microcontroller manually, load the .hex fresh, and re-add any spare parts (or reload the parts configuration, .pcf, if you saved one). If the simulation now runs, the old workspace was the problem: save a new workspace from this working setup and discard the old file.
  5. Prove the setup with a minimal program. Run the PIC16F877A blink tutorial on McLab2 or PICGenios, and if you need to see whether the CPU is toggling pins at all, probe a pin with the built-in oscilloscope as shown in Using the PICSimLab Oscilloscope. A clean square wave there means the simulation is running and the issue is in your program’s logic, not the simulator state.

Still stuck?

The blink tutorial and the oscilloscope walkthrough give you a known-good baseline to compare against. If a fresh manual setup (no .pzw) with matching board, MCU and clock still will not run the official-style blink example on v0.9.3, report it — board, MCU, clock setting and version included — on the project’s tracker: github.com/lcgamboa/picsimlab/issues.

Similar Posts