PIC18F8720 PORTD problem

[nverma]

Hi,

I'm trying to read PORTD on the PIC18F8720 and it just doesn't work. I have set the memcon.7 = 1 to enable it to read, but nothing seems to be working on that PORT. I have also set the TRISD register for inputs. What am I missing?

[Charles Linquis]

Make certain that PSPCON is set to "0".

[nverma]

Thanks, but that doesn't help either. The problem is still there. However I notice that the PIC only reads the input once at the time of reset and not after that in the loop I have. Also I notice that there is voltage drop on the inputs connected to PORTD. Instead of reading +5V(high) when they are on, the read +2.5V. Why is there a voltage drop? I think I have accounted for the MEMCON.7 = 1 and the PSPCON.4 = 0 and set the TRISD = %11111111.
Even after this, it still doesn't read on ever occurance of the loop. The PIC has to be reset for it to read the present inputs. Please help!

[mister_e]

schematic?

Code?

[nverma]

DEFINE OSC 20
DEFINE ADC_BITS 10
DEFINE ADC_SAMPLEUS 25


INCLUDE "MODEDEFS.BAS"
INTCON.7 = 1
MEMCON.7 = 1
PSPCON.4 = 0

TRISD = %11111111

channel var byte
outputAB VAR BIT
ch_onoff VAR BIT
SYSEN VAR BIT

CHANNEL = 0
OUTPUTab = 0
CH_ONOFf = 0
SYSEN = 0

loop:

channel.bit0 = PORTD.0
channel.bit1 = PORTD.1
channel.bit2 = PORTD.2
channel.bit3 = PORTD.3
channel.bit4 = PORTD.4
channel.bit5 = 0
channel.bit6 = 0
channel.bit7 = 0

outputAB = PORTD.5
ch_onoff = PORTD.6
SYSEN = PORTB.7

pause 500

serout PORTB.4,N9600,["Channel = ",#channel,13]
serout PORTB.4,N9600,["Output AB ",#outputAB,13]
serout PORTB.4,N9600,["Channel ON/OFF = ",#ch_onoff,13]
serout PORTB.4,N9600,["SYSEN = ",#SYSEN,13]


goto loop

end

[skimask]

DEFINE OSC 20
DEFINE ADC_BITS 10
DEFINE ADC_SAMPLEUS 25
INCLUDE "MODEDEFS.BAS"
intcon.7=1:memcom.7=1: pspcon.4:trisd=$ff:channel var byte
outputab var bit:ch_onoff var bit:sysen var bit:channel=0: outputab=0
ch_onoff=0:sysen=0
loop:
channel=portd:channel=channel & $1F: outputAB=portd.5:ch_onoff=portd.6
sysen=portd.7:pause 500
serout portb.4,n9600,["Channel = ",#channel,13,"Output AB ",#outputAB,13,"Channel ON/OFF = ",#ch_onoff,13,"SYSEN = ",#SYSEN,13]
goto loop
end

Which revision of the '8720 do you have?
The early ones had REAL, documented problems running above 4Mhz. The problems varied and depended mainly on the code running, some things worked fine, others didn't. Try running your program at 4Mhz or less once and see if it works.
I had issues with the early ones awhile back, couldn't figure it out. Read the errata sheets about the 4Mhz problem. Tried running programs at both 4Mhz and 10Mhz...4Mhz worked, 10Mhz didn't, and this was only blinking LEDs.
After I got a few of the new revisions, the problems went away.
And I simplified your program a bit...

[nverma]

I think I have a recent version of 8720 and I'm running it at 20 MHz. I really can't try running it slower because the PIC is already assembled with a 20 MHz osscilator. Any other suggestions?

[skimask]

I think I have a recent version of 8720 and I'm running it at 20 MHz. I really can't try running it slower because the PIC is already assembled with a 20 MHz osscilator. Any other suggestions?

What are the markings on the top of the '8720 itself?

[skimask]

I think I have a recent version of 8720 and I'm running it at 20 MHz. I really can't try running it slower because the PIC is already assembled with a 20 MHz osscilator. Any other suggestions?

What are the markings on the top of the '8720 itself?
What voltage are you running the PIC at?

[Charles Linquis]

I, too, found some real weirdness with early
8720s. They were the only chip big enough to
handle my task, so I couldn't switch to another
device or slow it down. I found myself doing all
sorts of work-arounds to get it to work.

The "late model" (July 2005 and later) 8720s and the
8722's are fine.


Something you might try -
Read PORTD with one instruction

Something like:

PORTDMirror = PortD

channel.bit0 = PORTDMirror.0
channel.bit1 = PORTDMirror.1
channel.bit2 = PORTDMirror.2
channel.bit3 = PORTDMirror.3
...

[nverma]

Markings are as follows:

PIC18F8720
-I/PT
05473PP

And I tried reading the whole port at once aswell. It didn't make any difference. Wow something so simple, I really wonder what the problem is now.

[skimask]

Markings are as follows:

PIC18F8720
-I/PT
05473PP

And I tried reading the whole port at once aswell. It didn't make any difference. Wow something so simple, I really wonder what the problem is now.

Date code of 0547...that makes it a newer revision...

Watchdog timer disabled?

[nverma]

Yes, watchdog timer and low voltage programming disabled. And im running the PIC at 5 V.

[mister_e]

What happen if you do a SEROUT loop and skip the PORT reading?

Which device programmer, PBP and MPASm version are you using?

[nverma]

If I skip reading the port and just do a SEROUT loop, then I always read the initial value that was input on the port at the time of reset. Like I said, if the PIC is reset, it does read the port with the correct inputs. It just doesn't read continuously during the program at every reading. Its almost like the port stop working after reset. I am using melabs programmer v4.10, MicroCode studio v2.3.

[skimask]

If I skip reading the port and just do a SEROUT loop, then I always read the initial value that was input on the port at the time of reset. Like I said, if the PIC is reset, it does read the port with the correct inputs. It just doesn't read continuously during the program at every reading. Its almost like the port stop working after reset. I am using melabs programmer v4.10, MicroCode studio v2.3.

Which version of PBP?

[nverma]

Oh sorry, v2.46a

[skimask]

Oh sorry, v2.46a

This is what I see for PBP 2.47 that might relate to your problem...

--Adds minor optimizations for PIC18Xxxxx.
--Changes internal bit names to avoid possible conflicts.
--Fixes possible memory allocation of word-sized variable at odd address on page boundary for PIC18Xxxxx.

Will any of these have an effect? Who knows...
Have you thought about swapping out the '8720 for an '8722?

[nverma]

Well I would replace the 8720 with the 8722 if I had a choice, however I am working on an existing design which uses a 8720, so I am forced to use 8720 and PORTD. I would have changed the port as well, but I no choice.

[skimask]

Well I would replace the 8720 with the 8722 if I had a choice, however I am working on an existing design which uses a 8720, so I am forced to use 8720 and PORTD. I would have changed the port as well, but I no choice.

The '8722 is pin compatible and software compatible with the '8720 and it's only got a couple of different registers to worry about. I would think it would be an easy replacement. And removing an TQFP isn't all that hard, if you do it one pin at a time (at least that's what they teach in the class I just got back from).

[nverma]

Well I guess if I can't get it working soon, I'll most probably do that. Thanks, please let me know if anyone else knows what im doing wrong.

[skimask]

Well I guess if I can't get it working soon, I'll most probably do that. Thanks, please let me know if anyone else knows what im doing wrong.

For grins, try changing your variable names and accessing registers like the MEMCON, PSPCON, etc. with the peek/poke to their actual locations vs. using their actual names...
Ya never know...

[mister_e]

We could still compile a HEX file with PBP 2.47 to see what happen?

Unfortunately i don't have those on hand... out of stock and there's no plan around them soon. Even if it was the case....
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2533&product2=PIC18F8722&product1=PIC18F8720

[skimask]

Unfortunately i don't have those on hand... out of stock and there's no plan around them soon. Even if it was the case....
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2533&product2=PIC18F8722&product1=PIC18F8720

Back a few years ago, when I saw the errata sheet for the 4Mhz limitation, I put that MCU in 'Not Recommended for ANY design' bin.
I've got a couple of '8722's that haven't failed me yet (well, at least any more than anything else).

[nverma]

I found the problem! So surprising enough, PORTD needs to be driven at more current, I replaced the 10K resistor arrays with 1.5K resistor and now it seems to be working fine. But really these CMOS inputs should not need this much current. Just thought you guys would be curious. Thanks!

[T.Jackson]

That's a bit of a worry. With 877's on PORTD, I typically use 100KΩ + resistors with no problems at all. Theoretically, with CMOS - up to 1MΩ should actually work.

[skimask]

I found the problem! So surprising enough, PORTD needs to be driven at more current, I replaced the 10K resistor arrays with 1.5K resistor and now it seems to be working fine. But really these CMOS inputs should not need this much current. Just thought you guys would be curious. Thanks!
....which is why mr_e suggested posting a schematic or something like it back in post #4....

[mister_e]

and 18Fs are actually a bit much noise sensitive than 16Fs.

10K to 1.5k seems a big jump, but if this working...

100K - 1M :eek: internal Pull-up, are better than this. Not something i would use/trust myself in a noisy environment 100000 X :eek:

Now, maybe i'm wrong, i didn't read the whole thing once again, but it might be caused by a Read-Write-Modify thingy.

General 18Fs rules, You write to PORTx, you read from LATx.

[T.Jackson]

I have a commercial serial IO controller KIT out there using 100K's for pull ups.
Project uses a 16f877a - no probs reported at all.