PIC16F1779 not running code after programming with MPLABX and PICKit3, MPASM code

Hi All,
I am having trouble getting this chip to run after loading a simple program. I am using MPLABX, PICKit3, and the program is 100% MPASM code.The code compiles correctly, but after MPLABX downloads and verifies successfully, there is no indication that the chip is doing anything.

The oscillator section appears working as set by the configuration settings and default power-on states - I've tried both the internal R-C oscillator, and an external crystal. The program should result in a pin toggling to indicate some program activity -  but nothing happens. Pins appear just Hi-Z - their power-on state. Pulling MCLR low stops the oscillator, and when released, the oscillator restarts.

I have tried several devices and the 2 available silicon issues - all with the same result.

I get the impression that I have overlooked something fundamental with this device, but can't spot what it is !!

Putting the exact same program code into a PIC16F1789 results in the expected output toggling.
The '1789 device is very similar to the '1779, so this seems a fair check of the program.

Can anyone suggest what the problem might be ?

With best regards, Paul.

Paul,
Since the program works on one chip and not the other, I would focus on what the difference is between the chips. Unfortunately, I don't have time to check but I'd suspect something in how the outputs are enabled or mapped to pins. Since you are using MPASM, check where you write the IO registers to make sure you are writing the correct bits to the correct registers to enable the outputs.

Hi Paul-Is anything else connected to the PGC and PGD pins or do they go directly t the ICSP connector?How about the MCLR pin?  Is there a pullup resistor on it? Try disabling MCLR and make it an I/O.Also- make sure LVP is turned off.Please let us know if any of this helps.-Rick

Hi Elizabeth and Simon,
Many thanks for your replies.
As far as I/O registers go, I believe I have correctly set banks for the TRIS, PORT and LAT registers. I have just double-checked this, and they are correctly set. Mapping through the PPS registers has not been made in my test program, the default POR settings are expected.

This has prompted me to check the function of the ANSELn register POR settings. According to the datasheet, a pin defaults to analogue input on POR, but a digital output set in the TRIS register will override the analogue function. My toggling pin is RD2, with the whole PORTD bus set to o/p.

On the PGC and PGD pins, these remain connected to the PICKit3 only, there are no other components connected. The MCLR pin is set in the CONFIG1 register as the MCLR function currently, with a 10KOhm pullup to 5V. Currently CONFIG2 sets LVP off.

I will try disabling  MCLR, and let you know !

With thanks, Paul.

Apologies Rick, for calling you Simon !
Best regards, Paul.

Hi Rick,
Have disabled MCLR in CONFIG1, and confirmed this by pulling it low and checking the oscillator o/p -Osc. no longer stops when MCLR is low. I then added clearing instructions for all ANSEL registers in Bank 3, to disable any analogue functionality - still no program toggling activity. The toggling pin is still Hi-z, as I can bias it with resistors to a voltage between the supply rails.

The program is quite short - I could post a file if this would help ?
With best regards, Paul.

Hi Paul,
The devices are in the same family and have the same flash footprint; the only interesting difference I can see - correct me if I'm wrong - is that they are different packages.
Assuming I am correct, make sure you have correct connected ALL ground and power pins. Other than that, you haven't shown us how you are connecting. How long are the wires? If they are more than a few cm to the connector to the PICKIT, then reduce them significantly, and try again.The other possibility is the voltage you are applying to the target. If you are applying voltage from the programmer, increase it by a few hundred millivolts. Regards,
Mike.

Hi Paul-I don't have a PIC16F1779 here, so there's not much I could do with the file.  Perhaps one of our other readers has one and would be willing to try programming it.........-Rick

Hi Paul-Another thought- Which pin are you trying to toggle? I wonder if one of the peripherals that shares that pin may be enabled by default. Try declaring a bunch of pins as outputs and toggle all of them.  Then look to see if any are changing.-Rick

Hi Mike and Rick,
Thanks for your posts. W.r.t. packages, I have both types in the 40 lead DIP package. I initially started the original project with the '1789, but this silicon had interrupt issues, so I moved to the later device '1779.

Both devices have 2 x Vdd and 2 x Vss pins, which are both connected and decoupled. The connection to PICKit3 is on the long side at 4.5"/12cm, but MPLABX repeatedly loads programs and verifies without any fault at all, so I assume the connection is secure.

The supply is from the project, not PICKit3, and measures 5.05V on my DMM, and my 'scope agrees with this. MPLABX/PICKit3 recognizes that the device is powered when programming.

W.r.t. the toggled pin, this is RD2, but the whole of the PORTD bus is declared as output. I will get back to you a bit later with the result of your change Rick.

One observation I have, is that with the internal R-C oscillator selected via the CONFIG1 register, I can't change its frequency, which is done by program code and the OSCCON register. It defaults to the POR value of 500KHz only. Banking for the register is correct ! ( Bank 1.)

With best regards, Paul.

Paul
Although I haven’t used them lately, my experience (and also reported by other EE web posters like yourself) is that Microchip support is good. They reply promptly and to the point. Since it appears we don’t have any direct experience, might I suggest that you create a case with Microchip

Hi Rick and Aubrey,
Rick - I have tried your suggestion and added RD<7:4> as a group to be toggled, but no change, the pins are as RD2 - in a Hi-z state.

Thanks Aubrey for your suggestion to contact Microchip - It certainly looks like a good idea. However, in the past I have tried this, and didn't get through to them. If I remember correctly, the procedure gave me a case number, but then it froze, and I was unable to raise my question with them. I'll try again - perhaps I will have success this time.

The impression I am getting is that the chips are not running ANY code at all, as all I am seeing is the default POR conditions, and the CONFIG register settings -as if stuck in some sort of reset state, despite the MCLR pin being either high, or disabled altogether.

Thanks all for your inputs. Iif anyone thinks of anything else please post it, I'll keep watching here.
With best regards, Paul.

PIC's don't like toggling.  Try XOR

and make sure
movlw   07
movwf   CMCON

Hi Peter,Thanks for the CMCON prompt. I remember that was a "gotcha" in one of my early projects, using a PIC16F877A ! However, for the PIC16F1779, while it has 8 comparators, all comparators default to OFF at POR, so I hope that issue can't occur with this device.
W.R.T. the toggling code, I use the form you suggest on the LAT register for the output :-
test_loc    movlw      b'00000100'               ; Set bit for RD2
    xorwf       LATD,F                           ; Toggle RD2.    nop                                                    ; String of "nop"s for a loop delay.    .....    .....    nop    bra           test_loc
Previous to this, the PORTD TRIS and LAT registers were initialised clear.
STOP PRESS !!With code especially written by Rick Curl, who PM'd me, I have at last got some activity from the PIC16F1779 devices. He wrote some code in BASIC, then compiled it to a HEX file for me to run.His code uses a slightly different CONFIG file setting to my code, so there is a starting place for me to explore.
I would be happy to PM my code to anyone to take a critical look at - if they feel inclined.
With thanks to Rick and all other contributors, Paul.

Paul, I just noticed your comment about the ANSEL register. You do have to turn that 'off' to get GPIO functionality, input or output. Unless they have changed that behavior in that particular device. Try it anyway IMHO.
Cheers,
Mike.

Hi Mike,
Thanks for your observation on ANSEL.  Indeed, the ANSEL bits do default to analogue on POR, so I added "clrf  ANSELn" instructions to all 5 ANSEL registers.

I am new to MPLABX, but I "bit the bullet" so-to-speak and tackled debugging through my PICKit3.  The program has always given the impression of doing nothing at all, except responding to CONFIG changes and MCLR input. Single-stepping and using the Watch screen on SFR's was a revelation.

The Bank changing instruction "MOVLB" was seen to do nothing to the register "BSR", which should follow the instruction's argument value for setting the requested Bank. This meant that any Bank changes to modify TRIS, LAT, ANSEL, or OSCCON didn't take effect, but instead only addressed Bank 0 by default. "MOVLB" was completely ignored !

Looking at the .LIS file, it became clear why. The instruction should be assembled as h'002n' - where n is the bank number, my code was h'014n' - in fact a non-existent instruction code. The chip was doing the sensible thing and ignoring it completely !
Modifying the register manually as  required during single-stepping got the program functioning as expected. Conclusion - assembler software error, most likely in a lookup file somewhere for the PIC16F1779. For comparison I had put the program into a very similar PIC16F1789 - which worked - the code for "MOVLB" is correctly assembled.

I would like to prove the fault by editing the HEX file, but don't know the format rules. I can see there is a 2-digit checksum at the end of each line, so that would have to be corrected too. I might be able to edit the program code through the debugger - I don't know if that is possible.

With thanks to all for your interest in a perplexing problem. I need to update my MPLABX, and see if that fixes this error. If not then a error report to Microchip.

With best regards, Paul.

Wow- you really had to get down to the nitty gritty on this one! Glad you're making headway though.Please let us know when you get it completely resolved.
-Rick

Hi Rick,
Yes - quite a debug trial. I have replaced the "movlb  bank_no" instruction with the 2 instructions "movlw  bank_no" and "movwf  BSR", with instant success. While this fixes my test program, it is not a viable solution for the project I originally chose the '1779 for. It uses many library files which I am definitely NOT editing for this bug !

I hoped an update to MPLABX from my v3.15 to the newest v4.15 might be a fix, but that stalled on installation - frustrating after its 625MB download. The installer lamely said that "Sorry, but MPALBX has a problem and has to close." ( My PC is an aged XP NT SP3, but with 2GB RAM, but runs v3.15 OK.)

Seeing that v3.15 works, an alternative is to edit the correction into wherever MPLABX keeps the instruction assembly data, but I don't know where to start with that. I have already had to edit the "p16f1779.inc" file for an error - changing the SFR's for CCP4 to CCP8.

With best regards, Paul.

Hi All,I did a short assembler experiment with the devices in the PIC16F1773/6/7/8/9 family, assembling the offending 'movlb bank_n' instruction, with the following result :-'1773 - correct - h'002n''1776 - correct - h'002n''1777 - wrong  - h'014n''1778 - wrong  - h'014n''1779 - wrong  - h'014n'Microchip appear to have really messed up with this family, and I can't understand how that was managed. I would expect the instruction set and assembly codes to be all the same for any Enhanced PIC16F1XXX device ! Hey-ho.With regards, Paul.

Hi All,
Just thought readers would like to know how this problem was eventually resolved. My current MPLABX version was v3.15 - quite an old version.

Thinking that Microchip would have corrected the assembler problem in the latest MPLABX version, I downloaded v4.15, but this wouldn't install on my aged XP system, although a user elsewhere claimed that it did run on his XP system, if with some initial difficulties.

After this disappointment, I looked at the Hex file, and wrote a BASIC program on my Micromite Backpack to massage the hex data, and change any occurrence of the faulty code to the correct one, including the necessary updates to the line checksums, but although the corrections looked fault-free, the code wouldn't run correctly.

I then read that another user was running the v3.65 revision, so I downloaded that, and found that it did install, AND run OK !

Checking the assembly code for the troublesome MOVLB instruction showed that it had been corrected in this revision, and my application code then ran too - phew!

Probably I could have loaded a somewhat later version than v3.65 - but will leave that to another day.

With best regards, Paul.