Connect with us

pic16f627a port a problems

Discussion in 'Electronic Design' started by [email protected], Feb 21, 2007.

Scroll to continue with content
  1. Guest

    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
     
  2. 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
     
  3. James Beck

    James Beck Guest

    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
     
  4. 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
     
  5. 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?
     
  6. 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
     
  7. 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
     
  8. Rich Grise

    Rich Grise Guest

    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
     
  9. 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
     
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day

-