PICSimLab .hex File Not Loading? Board, MCU and File Checks

You built your firmware, opened PICSimLab, loaded the .hex file — and nothing happened. Either the load itself fails, or the file appears to load but the board behaves as if no program is there. This page works through the causes in the order they actually occur, from a board/firmware mismatch down to a stale build file.

Symptoms

  • Loading the .hex file produces no visible change: no code runs, outputs stay idle.
  • The simulation runs, but the board behaves like it still holds an older program — or no program at all.
  • A .hex file that worked before stops working after you switched to a different board in PICSimLab.
  • The file loads on one board (for example McLab2) but not on another board you tried.

Why it happens

PICSimLab does not run “a hex file” in the abstract — it runs firmware compiled for the specific microcontroller selected on the currently selected board. A .hex built for a PIC18F4550 cannot run on a board configured for a PIC16F877A, and an AVR .hex built for an Arduino Uno (ATmega328P) cannot run on a PIC board. When the firmware and the selected board/MCU do not match, the load either fails outright or produces a simulation that does nothing meaningful.

The other common causes are mundane: the .hex on disk is stale because the last build in your IDE actually failed, the file is empty or truncated because the build was interrupted, or you changed the board after loading the file — switching boards resets the simulation state, so the previously loaded firmware is no longer in place.

Fix

  1. Confirm the board and MCU match the firmware. Check which board is selected in PICSimLab and which microcontroller it is set to, then check what chip your project was compiled for. For example, the McLab2 and PICGenios boards support the PIC16F777, PIC16F877A, PIC18F452, PIC18F4520, PIC18F4550 and PIC18F4620; if your chip is not selectable on the current board, pick a board that supports it (the generic Breadboard covers many additional PIC and AVR parts).
  2. Rebuild and confirm the build really succeeded. In MPLAB X, the Arduino IDE or VS Code with PlatformIO, fix any build errors first, then note the exact output path of the fresh .hex file. A failed build often leaves yesterday’s file in place, which makes a fixed program look “still broken”.
  3. Check the file itself. The .hex should be a non-trivial text file (an empty or near-empty file is a failed export, not firmware). If in doubt, move or copy it to a short, simple folder path and load it from there, so a moved project folder or a stale network path cannot confuse the load.
  4. Load in the right order: board first, then file. Select the board and microcontroller first, then load the .hex file. If you loaded the file and then switched boards, simply load the file again on the new board.
  5. Run and reset. After loading, make sure the simulation is actually running, and pulse reset once — some programs only show activity after a clean reset, exactly as on real hardware.
  6. Isolate with a known-good program. Load a minimal blink program built for exactly the selected chip (our PIC16F877A LED blink tutorial is built for the McLab2/PICGenios pair). If the blink program loads and runs, PICSimLab and the board selection are fine and the problem is inside your original project’s build; if even the blink program does nothing, re-check steps 1–3.

Still stuck?

Revisit the basics in order: the first-project blink tutorial shows the exact board-then-load sequence, and the Windows installation guide (with the platform pages under Download) rules out a damaged installation. If a correctly built .hex for a supported chip still will not load on a fresh PICSimLab v0.9.3 install, report it — with your board, MCU and PICSimLab version — on the project’s tracker: github.com/lcgamboa/picsimlab/issues.

Similar Posts