28X PortC pins 2,3 problem

[kenmac]

Hi folks,
I was working on programming I2C on a 28X when I had a problem.
Testing the SCL (pin c3) showed that it wasn't changing.
I then ran a quick programmed basic output check, monitoring the port with LED's on each pin.
This revealed that pins c2 and c3 were not responding to "high portc pin" commands.
I found that if pinsc = %11111111 is invoked, all outputs do activate.
Thinking that it may be a case of a damaged chip, I tried two more brand new 28X's on my proto board and discovered that they behaved exactly the same!
So, I checked the datasheet for the IC (16F873) thinking there may be something different about those two pins, but found nothing.
There was a note re being carefull when using Trisc register because of possible interaction of any peripheral control, which can over-ride the Trisc setting.
Of course, in the case of a Picaxe, this would only refer to controls implemented by the bootstrap program (I assume).
Anyway, it is time to ask the Forum for any ideas/answers.

kenmac

 

[Technical]

i2c is an open collector system. It therefore cannot be tested via LEDs to 0V on the SDA / SCL pins. This is also the reason you need 4k7 pullups on the bus.

Once the i2cslave command is issued the SDA / SCL pins change to open collector input/outputs and so can only be used by i2c commands (not high portc commands etc).

 

[kenmac]

Technical - yes I understand that.
I tested the outputs without any I2C call, just a simple sequential LED blinker program .
The I2C pins are c3 & c4 - the problem is with c2 & c3.
c4 works OK.
They all work when set with "pinsc =" .

ken mac

 

[kenmac]

Any more comments/info folks?

kenmac

 

[hippy]

I'll drag some 28X hardware to test, but sure it has worked when tested before. It's not just a mistake of using ...<code><pre><font size=2 face='Courier'>
High PortC pin2 </font></pre></code> Where &quot;pin2&quot; should just be the number &quot;2&quot; ?

 

[kenmac]

Hippy,
I'm using v5.08.
The outputs were tested in a simple &quot;set high, delay, set low, delay&quot; sequential loop, using the correct &quot;high portC 2&quot; syntax, and no other code present.
I also tried just setting the one pin - no go!
As I said before, all portC pins work OK when set with &quot;pinsc = $11111111&quot;, so it's not a local wiring/external problem.
I was wary of any unknown 28X (16F873) parameter but couldn't see anything relevant in the Microchip datasheet, apart from the reference to Trisc settings.

I'll have another look at it tomorrow.

kenmac

 

[kenmac]

Problem solved.
Watching the test program action, it first lit up all the portC outputs (LED's)using &quot;pinsc = %11111111&quot;, then it went thru a loop of sequentially turn on/turn off of each portC pin.
I noticed that when the loop progressed to the two errant pins they both went off at the same time, as if they were tied together.
Checks with a DVM ohmmeter indicated that there was no connection between them.
Anyway, I decided to do an inspection of the underside of the strip board, using a magnifier.
I couldn't see anything that would affect these two pins, but I took a sharp knife and ran it down between all the adjacent tracks just to make sure!
Then I re-tested and found that the fault had cleared - everything was working again.
Because the portC pins worked OK for the &quot;pinsc&quot; command, I had assumed that there wasn't a problem with the board.
It seems that if both pins were set high together they both worked, but when set individually, the pin couldn't respond because it was being held low by the other pin.
Why the ohmmeter test didn't show the connection is a mystery - perhaps it only showed up when voltage was applied!
The &quot;strip&quot; type boards are very convenient for &quot;one-offs&quot; and prototyping, but they can be a bit of a trap if you aren't carefull!
This episode just emphasises the necessity to clear the gaps between the copper strips, even if there is nothing visible.
I usually do this by running a sharp knife point between each line of copper.
Lesson learnt - again!

kenmac