problem RB4-7 on a 18F876A

hello all

last year i had a problem on these inputs also. i had a keypad matrix with RB0-3 as outputs (with diode) and RB4-7 as inputs (external pull downs, no interrupts!). with a keypad with a cable of 20cm it ever works fine. later in the installation with a keypad cable of about 150cm, after a while the pic ever seems frozen in a state where he never came back. because i hadn't much time then i solved the problem when i changed the inputs RB4-7 to RC0-3 where the longer cabel never was a problem.
some idea what that could be then?

now, RB5-7 are inputs with internal pull up and interrupt. the pic-board is powered by a power supply. i have an old soldering iron. when i turn it out, i get some short noise over 230V back to the 5V of my pic. then an interrupt is initialised over my RB5-7 inputs. i solved it now with a 10ms delay in the begin of the interrput servide routine and asking RB5-7 back again before execute the code.
but what could be the reason for this? that the pull up of RB5-7 are connected to 5V....

sorry for this mystified characterisation and thanks for any ideas

If your VDD is not well decoupled

Hi,

It is a good practice to have the PIC powered by a separate regulator and the rest with another one. When the internal pull-ups are enabled and there is a glitch in the PS then interrupts can occur without possibly resetting the chip through brown-out detect. I have found that in noisy environments with tens of MOCB and contactors switching in an out there are false interrupts due to interference. I revised my PCBs and redesigned the PS. It did improve but was never totally fool proof. Normally the PICs are very stable from EMI standpoint. So the only way out was software. I introduced a short delay just entering the interrupts and checked that if the PIN was still high (or low). Since the interrupt is predictable you can detect if it was a glitch. Then simply clear the flags and quit from the interrupt. BTW I use asm interrupts.

Hope this helps.

Regards

Sougata

EMI point of view

hi

thanks for your answer. i thinked about it first, so my late reply now...

i've also played with the brown out (disabled it), but no effect.

can you explain me please some details to separate regulation for the pic? i didn't really understood it...

in general, for EMI, are there some other hot tips? i've readed once from mister_e a 0.1uF condensator as well a 10uF Tantal over power supply helps a lot. so for EMI more things should be necessary

thanks

new aspect

hello all

i got a new problem around portb4:7. because i have a device out with this inputs interruptable where allways some problems occur (pic seems like frozen, must be repowered again) i start to try something.

a simple code like below stops to run when i connect RB6 (only this one makes problems it seems) to a long cable (about 30m) with no connection at the other end!!! no charm!
the led goes out and nothing happens again. test it on the lab-x2 and it must be made a reset.
when i uncomment te additional three lines in the main loop, sometimes it is possible to restart the code again with some connect rb6 and reconnect.

anyone an idea why this could be? works it like an antena? ways to try further on?

thanks a lot for any hint

Code:

include "modedefs.bas" ' include serial modes '-- FUSE CONFIGURATIONS ----------------------------------------- @ device pic16F876a, hs_osc ' oscillator selection @ device pic16F876a, wdt_off ' watchdog timer @ device pic16F876a, pwrt_on ' power-up timer @ device pic16F876a, bod_on ' brown-out reset @ device pic16F876a, lvp_off ' low-voltage programming @ device pic16F876a, cpd_on ' data eeprom protection _on @ device pic16F876a, wrt_off ' flash program memory write @ device pic16F876a, protect_on ' program code protection _on '-- DEFINITIONS ------------------------------------------------- DEFINE OSC 20 ' oscillator speed '-- PORTS ------------------------------------------------------- led1 var portb.0 led2 var portb.1 led3 var portb.2 but1 VAR portb.4 but2 VAR portb.5 but3 VAR portb.6 '-- CONSTANTS --------------------------------------------------- '-- VARIABLES --------------------------------------------------- inp var byte ' inputs portb4:7 '-- INITIALIZATION ---------------------------------------------- init: clear ' set all ram registers to 0 TRISA = %00000000 ' input : an4 TRISB = %11110000 ' input : buttons 1 - 3 TRISC = %10000000 ' input : rx ADCON1 = 7 ' a/d und comp off; ra = d OPTION_REG.7 = 0 ' enable portb pull-ups lcdout $fe,1 ' clear lcd pause 50 ' wait for start up lcd portb = 0 ' clear all outputs on portb '-- MAIN LOOP --------------------------------------------------- main: led1 = led1 ^ 1 ' toggle led 'lcdout $fe,$80,"status = ", dec led1, " " ' write led status 'inp = Portb >> 4 ' shift portb inputs 'lcdout $fe,$c0,"b4:7 = ", dec2 inp ' write input value pause 500 GOTO main '-- INTERRUPT SERVICE ROUTINE ---------------------------------- '-- SUB -------------------------------------------------------- '-- END --------------------------------------------------------- END '----------------------------------------------------------------

The problem is certainely the internal pull-ups. too weak to be good. try lower value let's say 1K.

BTW it's always agood practice to pca something betwen a PIC and the exterior world if you plan to use long distance cables. Opto coupler are still a good choice.

RB6:rB7 are still programming pins... look at the programming sequence of your pic... it make me think it could be something around it or not.

How about your MCLR pin?

How about the whole setup.

Bad ground screening, bad proto-board may give you some serious headache... worst @20MHZ. You may try to remove (for testing purpose only) those capacitor around your crystal.

Knowing your entire setup would help

Hi,

Internal pull ups are weak as stated and Steve is again damn right. Optocontrollers do help but then you need an additional power line light the LEDs. PCB layout is equally important. If you post your whole code then we can find out if it is an interrupt issue. Normally a PIC would reset if it freezes, (WDT) so an improper code may put your PIC in endless loop especially interrupts. If you do not have an ICD then it is possible to dump some values of the SFRs related to PIC power, stack etc,. This would ease diagonisis what went wrong and where.

hello steve and sougata

thanks for your hints.

i plan to change this three inputs (b5,b6,b7) to change to a2,a3,a5 and renew to code from the interrupt handler to a subroutine.
on the build in board which makes some troubles, the long connection is on b5. b6 and b7 are in the device so about 10cm long.
i will make a separate regulator from 12v to 5v from the same power supply to source a relais. sink them with the long cable outside to ground. this ground is also the internal gnd from the circuit. did you think this is a problem? the relais contact then switch in the device the input a5.

the mclr pin is set with 1k to 5v.

the setup is on a proto-board...

in the actual test circuit i also add a debug_off, with no success.
interesting is that when the pic seems frozen and i read back the codes with melabs serial programmer, the code starts again normal when it is finished...

cheers

Then you loose interrupts too

Hi,

If you change from PORTB to PORTA you will be loosing interrupts. So might limit the functionality of your system. Why not revise the pull-ups have a clean PS proper freewheeling diodes for the relays and so on

sorry, don't unterstand...

Quote:

Why not revise the pull-ups have a clean PS proper freewheeling diodes for the relays and so on

what means this? external pull ups and then ... power supply something...?

sorry, my english is not so fine ;-)