A 10  minute change that has taken 3 days

I needed to change a time delay in a 8-pin PIC12F675 project started 4 years ago but has been updated since.  No problem I thought, change the time, recompile, save a new output file and program some chips.

But the chips didn’t run. All that had changed was the time delay, one number.  It compiled and programmed without error.

As the SOIC chip is programmed then attached to the small board during production, each trial and error attempt was a lot of work.  So I modified a board to add a DIP socket and used a PIC12F675 DIP chip from old stock; a 2003 date code.

DIP works SOIC does not

The DIP chip worked, so I went back to the SOIC chip which still didn’t work with the same code file programmed.  This is weird.

Looking at the errata information there are no bugs or corrections that explain this.  It is the same part number but there are 13 years between the DIP and SOIC chips.  The other files that came from  the same source still work in the current SOIC chips.  It is just the latest file that doesn’t work.  The source is assembly, produced using MPLAB on Linux, as has been used for many projects for several years.  The code occupies most of the available 1K of program memory.  MPLAB is not the latest version but has been used extensively without this type of problem.

This is quite annoying and has cost me almost 3 days so far. I have just ordered 100 new SOIC chips from Element-14 to compare with my existing stock which is just over a year old.  Meanwhile the customer waits.

Problem Solved – simple really

The problem is with the source file and how it configures the chip configuration.  This application uses the MCLR pin as a GPIO.  The latest MPLAB output programmed the SOIC chips leaving the MCLR pin set to MCLR rather than GPIO.  The strange thing was that it worked fine in the older DIP chip.

Never mind.  The permanent solution was to ensure that the MCLR configuration was properly set to GPIO.  A batch of chips programmed and they all work fine.