pic16f627a port a problems

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

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

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:

On a sunny day (21 Feb 2007 07:44:59 -0800) it happened snipped-for-privacy@btinternet.com wrote in :

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?

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

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