In 18F4520 output_high(PIN_B2); instruction is being ignored

[jlucas]

I've been stuck on this for over a week now.

Pin_B2 on an 18F4520 is an output connected directly to input Pin_B4 on a 16F685. All it does is go high or low to signal the other chip. It works in one section of the code, but in another section, the instruction for it to go high is simply being ignored.

If I put the following at the beginning of the code, I can check the pin with a volt meter, and watch it go high and low.

[PCM programmer]

[jlucas]

If I put that section of code into the Init() routine near the beginning of the program, it works just fine. It's only later in the program that if fails.

The LEDs on A1, A2, and E0 all work fine. I only put them there to show that this section of code is executing, and that these other pins work when B2 doesn't.

There are no external resistors or other components on any of these pins. A1, A2, and E0 go directly to the LEDs and then to ground. B2, the troublemaker, goes directly to B4 on the 16F685.

I can't physically isolate B2 without damaging a rather expensive board, and even if I could repair it, I couldn't sell it later. I'd like to avoid that if possible.

The fuses, etc. are as follows:

[PCM programmer]

[jlucas]

Vdd is 5.08V.

The LEDs aren't the problem. They are only there for testing purposes, e.g., if (variable == n){output_high(Pin_A1);}else{output_low(Pin_A1);}. When I get everything to work, these 3 LEDs will be taken out, and all references to them in the code will be removed. Pin_B2 fails to go high regardless of whether the instructions for the test LEDs are present in that section of code.

I have even tried repeating the instruction several times with 10 ms delays between each iteration, but that doesn't work, either.

[FvM]

[PCM programmer]

[jlucas]

Unfortunately I can't get that test to work. There's a lot of interplay between the two chips before the code gets to the part that fails.

The 18F is connected to a data radio which receives 28 bytes of data in a short burst every second, and a lot of what happens depends on the input from that. I need the pin to go high when it's receiving data, so an abbreviated code in either chip can't duplicate the problem.

I can't be sure, but I doubt that the corresponding input pin on the 16F is causing the problem. The pin shows 0.00 V whether it's supposed to be high or low. The only way the input pin on the 16F could cause this would be if it had a dead short to ground. I don't think this is the case, since it works fine in another part of the code.

In the first case, when it does work, pin B2 in the 18F goes high in response to an input pin from the 16F going high. Then when that pin goes back to low, B2 on the 18F goes low.

In the second case, when it doesn't work, B2 on the 18F is supposed to go high when an if statement becomes true (based on the data being received). When that happens, two 1-bit variables are supposed to go from 1 to 0, and B2 is supposed to go high. The two variables are indeed going to 0, but B2 remains low. If I add a line to tell one the test LEDs to go high or low, the LED always works fine.

One clue that might be useful: It just occurred to me that B2 works when the chip is not receiving data from the radio module; it fails when it is receiving data. It's getting the data via the #use rs232...stream=ac statement above. Could this somehow be "distracting" it?

Anyway, it's about 1:30 a.m. here, so I'm going to turn in. Thanks again.
_________________
Always remember, things are never so bad that they can't get worse.

[PCM programmer]

1. Edit the 18F4520 code so that it never makes Pin B2 into an output pin.
Make sure it is always an input pin.

2. Tack a pull-up resistor on the pin.

3. Put an oscilloscope on the pin. It should be initially at a high level.

4. Run both programs.

5. Watch if the pin ever goes low. If it does, then the 16F685 is driving
it low.

This assumes there are no other circuits connected to the pin, and that
the 18F4520 code was completely checked, so it never touches pin B2.

[jlucas]

Uh oh, it looks like I'm one post behind.

[jlucas]

[jlucas]

PCM, I tried to run your test, but I couldn't figure out a way to get it to work. First, the output from Pin B2 is critical to making the system work. Without it, the program can't progress to the point where it was failing. Second, if I found a workaround for that, in order for the program to get to that point, I have to be out on the road and moving, so even if I could get it to work, I can't use my O-scope (it doesn't travel well), and the internal resistance on my multimeter is too low to measure the voltage on a pin with a 22k pullup resistor without the meter itself pulling the pin back down to near zero.

I did put some 330 ohm resistors on the LEDs. Unfortunately, that didn't fix anything. As a matter of fact, one critical feature that was working before has now stopped working.

That's been the story of this project for the past 2 years. Every single element of this system has worked at one time or another, but I have never been able to get everything working at once. Whenever I fix one problem, three other things will stop working, and it takes weeks to get back to where I was, i.e., just one last thing to fix, and it's done.

It looks like I have some work ahead of me just to get back to the point where the subject of this post may or may not become a problem again.

Thanks for all your help.
_________________
Always remember, things are never so bad that they can't get worse.

[asmboy]

after watching your pain for a while -

i wonder:

do you have any pins that are "tris'd" to change from Input to output dynamically during program execution?
or is teh I/O state cosntant for every pin , ie: always an in or out?

perhaps you could identify all your I/O states - and add

#USE fastio(all)
and then explicitly Specify TRIS for your port pins
----------
ALSO
would it be a problem to post as much of the schematic as you are comfortable with so we can SEE for ourselves that all is
fine && dandy in circuit land?
you see you make me very nervous about the WHOLE when you talk about adding a 330 ohm resistor .
----------------
as to the potential link between your soft serial port - and the pin failure -
i am very VERY suspicious of an interaction between slightly bent circuitry
and the perceived code problem. a schematic of as much as possible would set my mind at ease as to what is REALLY wrong
--------------

and very lastly - you have tried ANTHER pic in the circuit right ?
( not just the same pic over and over ?)

i have had pics that were funky and a source of much mischief
in my history. Trying a fresh pic is always a good idea.

[asmboy]

[jlucas]