pic16f627a port a problems

[[email protected]]

Hi I hoping someone might be able to help me.

I am using a pic16f627a to perform bit banged i2c & update of a video
on screen display chip. all lines used to do this, 5 in total, are on
port a.

OSD Chip select, OSD clk, OSD data are on port a bits 0, 1 & 2
respectively
I2C SCL and SDA are on port a, bit 3 and 4 respectively.

I have a very wierd problem. If I set or clear bits on bits 0,1 or 2
something happens and causes an i2c bus collision on the sda line.
sda, is cleared!!

as a consequence my master grinds to a halt

I have CMCON reg = 0x07 so all comparators etc.... are disabled.

Any one out there experienced anything wierd like this ?

any thoughts would be greatly appreciated.

Anbeyon

 

[Roger Hamlett]

Hi I hoping someone might be able to help me.

I am using a pic16f627a to perform bit banged i2c & update of a video
on screen display chip. all lines used to do this, 5 in total, are on
port a.

OSD Chip select, OSD clk, OSD data are on port a bits 0, 1 & 2
respectively
I2C SCL and SDA are on port a, bit 3 and 4 respectively.

I have a very wierd problem. If I set or clear bits on bits 0,1 or 2
something happens and causes an i2c bus collision on the sda line.
sda, is cleared!!

as a consequence my master grinds to a halt

I have CMCON reg = 0x07 so all comparators etc.... are disabled.

Any one out there experienced anything wierd like this ?

any thoughts would be greatly appreciated.

This sounds like the RMW problem.
'RMW', is 'read modify write'. On the PIC, when you read a port register,
it returns the state of the pins, not what is in the output latches
'driving' these pins. So if you set a bit, then set another bit, on the
second instruction, the state of the pins is read, having only just been
changed in the last clock cycle of the previous instruction, this value is
modified to set/reset the required bit, and this is written to the
internal register. If the voltage of the first pin, has not actually
reached the level required to be seen as 'high', the pin will be cleared.
So a single 'bit set' instruction, is actually executed as a 'read,
modify, write' sequence, and if two such instructions are executed one
after the other in particular, output data may be lost.
The first question then is what pull-up resistors you have on the I2C
bus?. The recommended value will depend on the loading. It sounds as if
your pull-up on the SDA line may not be low enough. If these resistors are
too high, the I2C lines will take a long time to reach the 'high' level,
and trigger this problem. The second question is whether there are any
delays present between output instructions?. If not, consider adding a
'nop' between these.

Best Wishes

 

[James Beck]

Hi I hoping someone might be able to help me.

I am using a pic16f627a to perform bit banged i2c & update of a video
on screen display chip. all lines used to do this, 5 in total, are on
port a.

OSD Chip select, OSD clk, OSD data are on port a bits 0, 1 & 2
respectively
I2C SCL and SDA are on port a, bit 3 and 4 respectively.

I have a very wierd problem. If I set or clear bits on bits 0,1 or 2
something happens and causes an i2c bus collision on the sda line.
sda, is cleared!!

as a consequence my master grinds to a halt

I have CMCON reg = 0x07 so all comparators etc.... are disabled.

Any one out there experienced anything wierd like this ?

any thoughts would be greatly appreciated.

Anbeyon

If you are doing any RMW instructions like bit manipulations on PORTA
you may be having problems with the dreaded PIC RMW "bug". Since the
RMW instructions work on the read value of the port NOT on what you may
think is (for example) a 1 or 0 written to a pin, you may have a
situation where the MCU is reading back a 0 because the output is loaded
down even though you think it is a 1. To keep things happy, you need to
do your port operations on a shadow variable and write that to the port
in a byte wide move.

Jim

 

[Anthony Fremont]

Hi I hoping someone might be able to help me.

I am using a pic16f627a to perform bit banged i2c & update of a video
on screen display chip. all lines used to do this, 5 in total, are on
port a.

OSD Chip select, OSD clk, OSD data are on port a bits 0, 1 & 2
respectively
I2C SCL and SDA are on port a, bit 3 and 4 respectively.

I have a very wierd problem. If I set or clear bits on bits 0,1 or 2
something happens and causes an i2c bus collision on the sda line.
sda, is cleared!!

as a consequence my master grinds to a halt

I have CMCON reg = 0x07 so all comparators etc.... are disabled.

Any one out there experienced anything wierd like this ?

any thoughts would be greatly appreciated.

Sounds like a potential read-modify-write issue. Try using a "shadow"
register to hold the information you want written to the output port and
moving data only one way, a whole byte at a time. When you use bsf, bcf
instructions on an output port, the hardware "reads" the whole port (the
actual pin values and not the latches), modifies the bit you specified and
then rewrites the entire port. If a pin is heavily loaded, it can
unexpected "flip" on you.

How are you bit banging your I2C values. Instead of actively driving the
CLK and DATA lines, use external pull-ups, write a 0 to the port pins for
CLK and DATA. Then to send bits and simulate an open-collector output,
write a 1 to the TRIS register to send a 1 or a 0 to send a 0. This works
by allowing the external pull-ups to pull the CLK and DATA lines high since
an input pin (1 in TRIS register is input or course) is high impedance.
When you write a 0 to the TRIS reg, the pin will become output and will
actively drive the line low since the port bits are preset to 0's. Does
that make any sense at all?

IN SUMMARY:

1) Always use a shadow register when trying to modify individual bits of an
output port.
2) Avoid actively driving the CLK and DATA lines when bit-banging I2C

 

[Jan Panteltje]

Hi I hoping someone might be able to help me.

I am using a pic16f627a to perform bit banged i2c & update of a video
on screen display chip. all lines used to do this, 5 in total, are on
port a.

OSD Chip select, OSD clk, OSD data are on port a bits 0, 1 & 2
respectively
I2C SCL and SDA are on port a, bit 3 and 4 respectively.

I have a very wierd problem. If I set or clear bits on bits 0,1 or 2
something happens and causes an i2c bus collision on the sda line.
sda, is cleared!!

Output operations on porta are read modify write.
If you have the porta bit 4 open drain as bidirectional IO configured,
then I could imagine sometimes a SDA ack (from a slave) is read, and then
a zero written back, and your system locks up.

This correct?

 

[Spehro Pefhany]

Hi I hoping someone might be able to help me.

I am using a pic16f627a to perform bit banged i2c & update of a video
on screen display chip. all lines used to do this, 5 in total, are on
port a.

OSD Chip select, OSD clk, OSD data are on port a bits 0, 1 & 2
respectively
I2C SCL and SDA are on port a, bit 3 and 4 respectively.

I have a very wierd problem. If I set or clear bits on bits 0,1 or 2
something happens and causes an i2c bus collision on the sda line.
sda, is cleared!!

as a consequence my master grinds to a halt

I have CMCON reg = 0x07 so all comparators etc.... are disabled.

Any one out there experienced anything wierd like this ?

any thoughts would be greatly appreciated.

Anbeyon

Sounds like a read-write-modify issue. With that particular part
(series of parts) you may end up having to maintain a shadow port A
file register.


Best regards,
Spehro Pefhany

 

[Paul E. Schoen]

Sounds like a read-write-modify issue. With that particular part
(series of parts) you may end up having to maintain a shadow port A
file register.


Best regards,
Spehro Pefhany

I just got "bit" by this "bug" myself. I am using a PIC18F242, which also
has an LATA register which can be used to fix this problem by writing to it
instead of the port. The datasheet does not give any warning about the
consequences of bit-banging the port directly, but it makes sense. The
architecture of the PIC is such that a bit operation involves a byte-wide
write, and the only way it can do this is to read the values on the port,
change the desired bit, and then do a write. There are some good articles
about this on the Microchip website if you search read/modify/write. It is
unfortunate that the discussion is not contained in the datasheet for the
part.

This problem is especially treacherous because it will not show up using
the software simulator, and it can depend on things like board layout,
stray capacitance, noise, clock speed, and other variables. It is
especially bad when one of the port pins is open drain, driving an LED
through a pullup. When the port is driven high, it actually floats, and the
nonlinearity of the load allows it to float at an ambiguous logic level of
one or two volts.

I have checked my code on past projects, and there are some problems that
will need to be corrected. In some cases, I originally had shadow
registers, but then later I removed them to make the code "cleaner"! Now
that I fully understand the problem, I don't think I will make this mistake
again. (FLW!)

Paul

 

[Rich Grise]

Sounds like a read-write-modify issue. With that particular part
(series of parts) you may end up having to maintain a shadow port A
file register.

Well, I can see if he's doing a read-write-modify, how that could lead
to issues. ;-) ;-) ;-)

(I know you mean read-modify-write - it's these pesky Chinese keyboards!)
;-)

Cheers!
Rich

 

[Spehro Pefhany]

Well, I can see if he's doing a read-write-modify, how that could lead
to issues. ;-) ;-) ;-)

(I know you mean read-modify-write - it's these pesky Chinese keyboards!)
;-)

Cheers!
Rich

Ah, crrrap. Thanks so much for pointing out what everyone else was
politely ignoring.

I did happen to have a (traditional) Chinese mini-keyboard plugged
into this machine just yesterday. See, the MS one died (something to
do with some spilled/spilt Scotch, I think), and it wouldn't recognize
a PS2 keyboard hot-plugged, so fortunately the other one was waiting
in the wings to allow me save a bunch of work. I just used the English
keys, not the hundred and change shifted radical keys. Anyway, the new
MS one is mushier and will take a bit of getting used to. Bill decided
to nix the built-in USB hub to make himself a bit more scratch. 8-(


Best regards,
Spehro Pefhany