Why Is My PIC18F45J10 Not Lighting Up an LED Despite Correct Code and Circuit?

[El Moriana]

Hi,
Here goes:

Problem
I'm having trouble getting my PIC18F45J10 to light up an LED.

I have a LED-res-ground connected to RC7 (pin 26).
My code is set to configure PORTC pins to be output and then set the RC7 bit.
Upon debugging, the following is shown:
TRISC=0x00
PORTC=0x80
RC7=0x00

It can be seen here that, though the RC7 bit in PORTC is set (shown by the '10000000' in PORTC), RC7 is not... my physical circuit is also devoid of any activity and my LED stays dark.

Quick Analysis of Problem
This is purely a code problem; the circuit has been checked and is working.

A major part of the problem is certainly because I am new to programming PIC18Fxxxx's. Also, I have never dealt with latches before. My guess is that my problem has to do with latches and how they affect the physical pin status. I have only a vague inkling of what the latches actually do.. as the I/O section of the datasheet mentions only that they are "useful" and that the most relevant threads on my problem I have found mention them and assume I already know all about them.

I was about to venture into the realm of vague google searching but I might as well also ask here: what are latches and why are they useful? (the latter is not always obvious)

I have provided my code below:

Code

;Imports
	LIST P=18F45J10		;directive to define processor
	#include <P18F45J10.INC>	;processor specific variable definitions

	;Config Bits
    CONFIG	FOSC = HS	;select HS oscillator

	;Start
		ORG	0x0000	;reset
		goto	Init	;go to initialisation

	;Initialisation
Init:
		clrf	PORTC	;clear register
		clrf	TRISC	;set all pins to output
		clrf	LATC	;clear data latch
		goto 	Main	
	;Main Code
Main:

		BSF		LATC, LATC7 ;run pin high
	
Loop:		
		goto 	Loop ;Infinite Loop

		END

I have also tried setting RC7 using

BSF		PORTC, RC7

but read somewhere I should always write to latches and never the actual port.. in anycase both gave me the same result in the debugger.

 

[Antiphon]

Make sure you configure all the peripheral hardware explicitly. Don't rely on the reset and subsequent defaults. For example disable all the comparators and a/d converters etc.

Also to debug it, change all the outputs not just the one you want.

Finally try turning the ports both on and off. Maybe you've flipped the sense of something.

 

[MATLABdude]

As Antiphon suggests, you may want to have toggle your output (say, with BTG) rather than just set and enter an infinite loop (i.e. incorporate the toggle into the loop). You should be able to generate a sqaure wave that you can then scope (assuming you have a scope here). If you don't have a scope, you can make it blink using delay statements (e.g. if your clock is 1 MHz, and it takes 4 clock cycles to execute an instruction, 32000 comparison with a NOP--two instructions, IIRC--will get you around a quarter of a second).

Back to your hardware, do you have both VSS and VDD lines hooked up to the appropriate rails, \overline{MCLR} hooked up to your VSS through a 1k or higher pull-up resistor, and your oscillator / crystal properly attached?

EDIT: According to the datasheet, toggle is one instruction cycle, branch / comparison is two if the branch is taken, one if not.

 

[mdjensen22]

The 18F45J10 family parts are only 3.6V (max) VDD parts - what voltage are you running your processor at? Are you trying to sink or source current for the LED? What is the forward voltage of your LED and what resistor value are you using?

Have you tried disconnecting your circuit and measuring the pin level with a meter or scope?

 

[El Moriana]

Managed to make it work! But it poses a new problem of sorts. This is what I found:

Usually
I code and build my files in the Microchip MPLAB IDE. Then I import the .hex to my PICKit 2 desktop app (separate from MPLAB). In the app I then write to the chip and usually click the 'On' checkbox to power the chip and start the program. This method did not work with this chip, however worked perfectly on a PIC16F690 i was playing with before.

This Time
I used the "Programmer>Select Programmer", "Programmer>Release from Reset" options in MPLAB. This method worked!

And I have no idea why ='(

Have any of you come across this before/know what is happening?

PS: I assume (due to the correct LED finally lighting up) that both my circuit and code are fine. I have checked this result across multiple PORTB and PORTC pins (changing the code each time accordingly and checking the non-LED pins with a meter) to ensure that it wasnt merely a fluke success.

 

[El Moriana]

I think I found the reason as to why the two programs were behaving differently.
I have no oscillator connected and expected the PIC to run automatically from its internal oscillator.

I think that the "Release from Reset" option in MPLAB forces the PIC into using internal oscillation for debugging purposes. The PICKit 2 programmer app however, runs the PIC directly, with whatever settings have been coded.

Does this seem plausible or have I got it way wrong?

I have tried setting the internal oscillator manually (setting the WDTEN and FOSC2 config bits as mentioned by the data sheet, p.30). It isn't working, so either my theory was wrong or that's not the way to set the internal oscillator. Help?

 

[El Moriana]

Progress! Managed to figure it out.
The discrepancy between MPLAB and PICKit 2 express was not due to a mysterious debug mode in MPLAB (as was my original theory above). It was, in fact, due to a combination of the MPLAB release-from-reset conditions and bad wiring on my part.

The full explanation
When one writes to a PIC from MPLAB and thereafter selects "Release from Reset" one can notice that in the PICKit 2 window it reports "setting MCLR Vdd". i.e. pin1 of the PICKit 2 is set high.

My circuit was such that my PIC MCLR pin was always and exclusively (therein lies the problem) connected to my PICKit 2 pin 1. Hence, whenever MPLAB set MCLR to Vdd, my PIC would run and happiness ensued.

The PICKit 2 express app only contains Vdd-On checkbox. Ticking it does exactly what the name implies. It sets the Vdd Pin of the PICKit 2 (pin 2) high. This does not affect the MCLR pin whatsoever. Due to my MCLR pin not being connected to Vdd in any way, it is now plain to see that the voltage-starved PIC would not turn on and run.

I have now modified my circuit accordingly and lo-and-behold, happiness ensues in both MPLAB and PICKit 2 express.

I hope I have not been too annoyingly ignorant for all those that replied earlier. Thank you for your suggestions =). Hopefully someone may profit from my mistakes, be they unfortunate enough to fall into the same ignorance-trap.

E Moriana