Searching \ for '[PIC] Multiple F88 slaves on I2C buss' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/i2cs.htm?key=i2c
Search entire site for: 'Multiple F88 slaves on I2C buss'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Multiple F88 slaves on I2C buss'
2005\06\25@062326 by Jinx

face picon face
I've RTFM all F week and tried my best with both the F452 and
F88 timing diagrams. Sorted out most I2C issues for this application
but a couple of dots still need joining. The I2C guides I found were
all about dumb slaves (memories etc)

Got an F452 as master and > 4 F88s as slaves

The F452 sends out addresses on the buss to see what replies, and stores
those addresses it gets an ACK back from. So far, so good

        clrf    fsr0h             ;db address array
        movlw   db_addr1
        movwf   fsr0l

        mov     b'00001000',temp1 ;start address, 00001 + xx + /W

addr_lp  bsf     startb            ;start bit
        btfsc   startb
        bra     $-2

        movff   temp1,sspbuf
        btfsc   sspstat,r_w
        bra     $-2

        bsf     stopb
        btfsc   stopb
        bra     $-2

        btfsc   sspcon2,ackstat   ;0 = board ACKed
        bra     next_a            ;1 = board ACKed not
        movff   temp1,postinc0    ;store address as existing

next_a   incf    temp1             ;try next address (not inc bit1)
        incf    temp1
        movlw   b'00101100'       ;limit, 44
        xorwf   temp1,w
        skpz                      ;limit reached

        bra     addr_lp

Here's where it falls over. Contact each F88 in turn, lowest address first,
to send config data. What happens is that the first F88 contacted ACKs
and accepts data. The second ignores its address and NACKS

I'm trying to find out what I2C status bits/flags need to be looked at to
determine what the second F88 saw in the comms to the first and made
it ignore its address

Say the F88 code is waiting here

        btfss   startb       ;wait for Start bit
        goto    $-1

        bcf     b_full       ;clear BF
        btfss   b_full       ;wait for address byte
        goto    $-1

;and also

        bank0                ;address match
        bcf     pir1,sspif
        btfss   pir1,sspif   ;byte received
        goto    $-1

        movfw   sspbuf       ;clear BF

If the address compare is false, how does one go back to waiting
for a Start bit. Status bit(s) (BF, D/A SSPIF ?) to check or perhaps
wait for a Stop then loop ?

Any help finding the "Now leaving Ignorantville" sign would be
greatly appreciated

TIA

===============================================
If you aren't part of the solution, you're part of the precipitate


2005\06\25@102942 by Jan-Erik Soderholm

face picon face
Jinx wrote :

> ... and > 4 F88s as slaves

Hi.
Not sure that it
relates to your setup,
but, AFAIK, using the IOC in the B-port
and I2C
as slave on the F88 doesn't
work together.

IOC and I2C-host is fine on
the F88...

Jan-Erik.



2005\06\26@041512 by Jinx

face picon face
part 1 3200 bytes content-type:text/plain; (decoded 7bit)

> Hi.
> Not sure that it relates to your setup, but, AFAIK, using the
> IOC in the B-port and I2C as slave on the F88 doesn't work
> together

Hi J-E, IOC isn't being used at all, so I can rule that out. Currently
I'm trying the reception code below. Just one of many permutations
of code/flags/directives that all seem to have a similar outcome ;-((((

The time-line for the attached gif is as follows (9th clock highlighted)

F452 transmits a sequential series of addresses (up to the dashed
lines), storing those it gets an ACK back from. In the example, two
F88s were enabled with addresses 0000100x and 0001000x
respectively. Both ACK, as expected (hoped for), and always. Next
the F452 contacts the first address on the list, the 0000100x F88. Now,
sometimes it ACKs, and sometimes it doesn't, which is a little
disconcerting.
Analyses are taken > 1s after power-up, so there shouldn't be any noise,
and you'd expect the circuits to be stable. Both SCL and SDA have 1k
pull-ups. When the F88 does ACK, it won't ACK past the first byte of
data (addres and two data shown), and the next F88 on the list, the
0001000x won't ever ACK at all

I'm completely stumped, most probably because I don't know
what I don't know. So any suggestions would be very welcome

TIA again

i2c_lp   bank0
        bcf     pir1,sspif   ;clear flags
        movfw   sspbuf
        bcf     sspcon,sspov
        bank1
        bcf     b_full

wait_ab1 bank0
        btfss   pir1,sspif   ;wait for address byte
        goto    $-1
        bsf     marker
        bcf     sspcon,sspov
        bcf     pir1,sspif
        bcf     marker
        bank1
        btfss   b_full       ;address matched
        goto    wait_ab1     ;byte received was not address

        movfw   sspbuf       ;clear BF
        bank1
        bcf     b_full

        bank0
        call    ms01         ;wait for address polling to finish
        call    ms01
        call    ms01

        bcf     sspcon,sspov
        bcf     pir1,sspif
        movfw   sspbuf
        bank1
        bcf     b_full       ;address matched

wait_ab2 bank0
        btfss   sspcon,sspif ;wait for address byte
        goto    $-1
        bsf     marker
        bcf     sspcon,sspov
        bcf     pir1,sspif
        bcf     marker
        movlw   b'00001000'
        xorwf   sspbuf,w
        bnz     wait_ab2

        bank0
        bsf     marker
        movfw   sspbuf       ;clear flags
        bank1
        bcf     b_full

        bank0                ;pick up 11 data bytes
        bcf     marker
        movlw   r_byte       ;received bytes counter
        movwf   fsr
        mov     .11,temp0

wait11   btfss   sspcon,sspif ;wait for data byte
        goto    $-1
        bsf     marker
        bcf     sspcon,sspov
        bcf     pir1,sspif
        bcf     marker
        bank1
        bcf     b_full
        bank0
        movfw   sspbuf       ;copy byte, clear BF
        movwf   indf

        incf    fsr
        decfsz  temp0
        goto    wait11      ;loop for 11 bytes

        bcf     marker

        goto    i2c_lp       ;repeat on reset





part 2 3785 bytes content-type:image/gif; (decode)


part 3 35 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

2005\06\26@070033 by Jan-Erik Soderholm

face picon face
Jinx wrote :

> > Hi.
> > Not sure that it relates to your setup, but,
AFAIK, using the
> > IOC in the B-port and I2C as slave on the F88
doesn't work
> > together
>
> Hi J-E, IOC isn't being used at all, so
I can rule that out.

OK, that was just a note I saw on another
forum...

Problem with the F88 (and maybe others) is that if you enable
IOC, and use I2C in slave mode (where the I2C-clock/RB4 is
an input
pin) the IOC interrupt will fires on every I2C clock
comming in from
the I2C-master. Not exectly what you want...

The guy in the other
forum said that this had been
acknowledged by Microchip as a bug i the
current F88 silicon.

Apart from that, I know close to nothing about
I2C... :-)

Best Regards
Jan-Erik.



2005\06\26@093830 by Jinx

face picon face
> Apart from that, I know close to nothing about
> I2C... :-)
>
> Best Regards
> Jan-Erik.

Well, I'm not too bad in some areas of I2C and have a pretty
good idea of what's needed in various situations. I think this
problem is more related to implementation on the F88. I'd like
to see more documentation (wave/timing diagrams for example
showing the status of all the internal flags) than is in the manual,
and hopefully a tutorial specifically for the F88

I've had a quick look around Microchip's site and the forums
but nothing jumps out at me. Have to persist though, as this is
an integral part of a new product and can't put it off or chuck it
in the Too Hard basket


2005\06\26@160836 by Robert Rolf

picon face
If the 'F88 is acknowledged by Microchip to have
silicon bugs (IOC for instance) maybe it also has
bugs in I2C implementation. It's wouldn't be the first
time they've screwed up there.

It may be worth your time to port your code to a
DIFFERENT PIC chip with I2C capability, and confirm
that the code works as expected there. DIP parts and
solderless breadboards are your friend...

Robert

Jinx wrote:

{Quote hidden}

2005\06\26@163005 by Jan-Erik Soderholm

face picon face
Robert Rolf wrote :

> If the 'F88 is acknowledged by Microchip to have
> silicon bugs (IOC for instance) maybe it also has
> bugs in I2C
implementation...

Note that the errata was updated as late as
23 Jun
2005 (Rev J !).

ww1.microchip.com/downloads/en/DeviceDoc/80171j.
pdf

Check "Issue 7" !

Jan-Erik.



2005\06\27@232820 by Jinx

face picon face
part 1 2440 bytes content-type:text/plain; (decoded 7bit)

I think I've got a grip on what's going (famous last words)

The F452 had previously talked to 2 F88s in a simpler environment,
so I broke the s/w back into bite-sized chunks and doggedly persisted
examining flags. The inclusion of the F452's address polling routine
was the key. A (the ?) solution is to add a routine to the F88 that
counts Start/Stop conditions. By doing this, the F88 is not left messed
up by the address polling routine and is ready to receive its data. Still
early stages and plenty of tinkering to do, but at least something is
working

i2c_lp   bank0
        bcf     pir1,sspif   ;clear flags
        movfw   sspbuf
        bcf     sspcon,sspov

        clrf    temp4    ;count start/stop bits

ct_sb    bank1
        btfss   startb
        goto    $-1

        btfss   stopb
        goto    $-1

        bank0
        bsf     marker
        incf    temp4
        nop
        nop
        bcf     marker
        movlw   .18          ;number of addresses sent
        xorwf   temp4,w
        skpz                 ;count done
        goto    ct_sb

        bcf     pir1,sspif   ;clear flags
        movfw   sspbuf
        bcf     sspcon,sspov

wait_ab1 bank0
        btfss   pir1,sspif   ;wait for address byte
        goto    $-1
        bsf     marker
        bcf     sspcon,sspov
        bcf     pir1,sspif
        bcf     marker
        bank1
        btfss   b_full       ;address matched
        goto    ct_sb        ;byte received was not address

        bank0
        bcf     sspcon,sspov ;clear flags
        bcf     pir1,sspif
        movfw   sspbuf

wait_ab2 btfss   pir1,sspif   ;wait for address byte
        goto    $-1

        bsf     marker
        bcf     sspcon,sspov ;clear flags
        bcf     pir1,sspif
        movfw   sspbuf
        bcf     marker
                             ;pick up 11 data bytes
        movlw   r_byte       ;received bytes counter
        movwf   fsr
        mov     .11,temp0

wait11   btfss   pir1,sspif   ;wait for data byte
        goto    $-1
        bsf     marker
        bcf     sspcon,sspov
        bcf     pir1,sspif
        bcf     marker

        bank0
        movfw   sspbuf       ;copy byte, clear BF
        movwf   indf

        incf    fsr
        decfsz  temp0
        goto    wait11      ;loop for 11 bytes

        bcf     marker

tst_end  goto    tst_end





part 2 5571 bytes content-type:image/gif; (decode)


part 3 35 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

2005\06\29@015338 by Jinx

face picon face
Here's something interesting, can anyone offer an explanation ? I
discovered it by the "Hmmm, what happens if I do this" method

Using the last code (Start / Stop bit counting) I posted previously
in this thread, which appeared to work alright with a single F88 I
added a second F88 to the I2C buss. The result was disappointing

http://home.clear.net.nz/pages/joecolquitt/2xF88_not_OK.gif

However, with the addition of a leading Start / Stop it marvellously
all came together

http://home.clear.net.nz/pages/joecolquitt/2xF88_OK.gif


'[PIC] Multiple F88 slaves on I2C buss'
2005\07\03@194200 by Jinx
face picon face
After an intensely frustrating fortnight (investigating every permutation
of code order, bit testing, board proving) trying to get this I2C network
going reliably I think I've hit on the problem. Hopefully this will help
anyone who has problems getting I2C to work. Initial single slave
tests were done with the buss running at 98.8kHz, and that seemingly
worked OK. When that set-up was moved to the production unit
comprising a master and 4 slaves - flakey, to say the least. Results
just didn't make logical sense, and the bodgineering needed to make
the comms work was getting ridiculous

The final fix appears to be running the "100kHz" buss at > 104kHz.
So far nothing is going wrong at 106kHz and my code is performing
as it should have been two long long weeks ago

If I wasn't so relieved I'd be dancing

2005\07\03@195324 by Jinx

face picon face
BTW, just for reference

        mov     0x59,sspadd        ;set buss speed @ 39.3216MHz

; 0x57 109.8kHz OK comms
; 0x58 108.6kHz OK
; 0x59 107.4kHz OK
; 0x5a 106.3kHz OK
; 0x5b 105.1kHz OK
; 0x5c 104.0kHz OK
; 0x5d 102.9kHz /OK
; 0x5e 101.8kHz /OK
; 0x5f 100.8kHz /OK
; 0x60  99.8kHz /OK
; 0x61  98.8kHz /OK

2005\07\04@015326 by Wouter van Ooijen

face picon face
> The final fix appears to be running the "100kHz" buss at > 104kHz.
> So far nothing is going wrong at 106kHz and my code is performing
> as it should have been two long long weeks ago
>
> If I wasn't so relieved I'd be dancing

But do you have any idea why this fiex works (or rather: why the
slightly lowe speed fails)?

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\07\04@041136 by Robert Rolf

picon face
Generally one would like to understand the failure mode, in
order to ensure that you are not going to be bitten again later.

Could it be a silicon bug? e.g. divisor not providing the correct
clocks in the F88. You would think slower would be better,
but maybe there is some glicthyness in your lines.

A quick test would be to double your crystal frequency
on one side, and then the other to see if it's an
absolute time, or relative time (bit period vs Tcy) issue.

You're not sending continuous data streams are you?

Robert

Wouter van Ooijen wrote:

{Quote hidden}

2005\07\04@042505 by Jinx

face picon face

> > The final fix appears to be running the "100kHz" buss at > 104kHz.

> But do you have any idea why this fiex works (or rather: why the
> slightly lowe speed fails)?                  

I have absolutely no idea, which is why a problem with the clock speed
never occured to me before. I thought a 100kHz buss would tolerate
1% on a byte-by-byte basis. The only reason I looked at it now was
because of the remote possibility of line reflections or ringing or
something equally dopey (although even connecting the two PICs
together 1" apart made no difference). Slowing the clock down just
made it worse, so I tried speeding it up. Not until it reached +4% did
the comms become reliable and repeatable. Now I have four slave
boards attached to the master, and comms between them all is exactly
how I wanted it

I've run several tests with this today and it's as solid with the higher
frequency as it was unreliable with the slower. Everything works
perfectly. With the old speed, I was seeing things on the analyser
that just didn't make sense. Particularly a marker pulse I was putting
out on PortB5. I presume that the I2C module gets it's knickers in
a twist and the h/w messes up PortB, perhaps through some r-m-w
effect. I noticed a little improvement when the marker was moved
to PortA2

I understood the I2C module to be edge-triggered via SCL, not
sampled as RS232 is. Although not actually spelled out in black and
white, this is what I infer from the manuals and references. For
example, mention is made of bits changing on clock edge, the block
diagram is laid out as you'd expect a h/w shift register to be and so on.
Plus there's no explicit mention of a sampling rate


2005\07\04@043815 by Jinx

face picon face

> Generally one would like to understand the failure mode, in
> order to ensure that you are not going to be bitten again later.

Yes, absolutely. I really got sucker-punched

> Could it be a silicon bug? e.g. divisor not providing the correct
> clocks in the F88. You would think slower would be better,
> but maybe there is some glicthyness in your lines

The supply is well-filtered, and at one stage the master-slave were
almost soldered together. I've looked at SCL and SDA and other
lines very very closely and find no noise. The F88s I have are all
the same batch, so I can't disprove a silicon bug

> A quick test would be to double your crystal frequency
> on one side, and then the other to see if it's an
> absolute time, or relative time (bit period vs Tcy) issue.

Master is running at 39.321MHz, slave at 8MHz internal. This is
how I envisioned them in production, so that's the environment I'd
like the I2C to work in, but your suggestion is worth pursuing to
gather more clues

> You're not sending continuous data streams are you?

No. The address polling is the longest activity. This is 18 bytes
separated by S/P, altogether taking just short of 2ms. Next
longest is address + 11 data to the slave, about 1ms

2005\07\04@100123 by olin piclist

face picon face
Jinx wrote:
> The final fix appears to be running the "100kHz" buss at > 104kHz.

This doesn't sound like a fix at all, just a bandaid covering up the real
problem.  I went back and looked, and you are using a 18F452 as master.  Are
you using the *same* pullup resistor value on both lines?  Are these pullups
about as low as allowed, like around 2Kohms?

Apparently the original problem is that you are getting a NACK from a slave
when you were expecting an ACK.  Try putting 100pF to ground on the SDA line
only, not the SCL line.  This will help work around one of the MSSP bugs
which causes exactly this symptom.

> I have absolutely no idea, which is why a problem with the clock speed
> never occured to me before. I thought a 100kHz buss would tolerate
> 1% on a byte-by-byte basis.

IIC is synchronous and controlled by the master only.  The original IIC spec
had a few selected frequencies only.  Maybe there are devices out there that
only support those specific frequencies, but PICs are fully static and
definitely don't care how slow you go.  I've debugged IIC by toggling
individual bits so that I can see them on LEDs.

> With the old speed, I was seeing things on the
> analyser that just didn't make sense.

This sounds like a clue.  What exactly on the IIC bus didn't make sense?

> Particularly a marker pulse I was putting out on PortB5.

Now it's starting to smell like a firmware bug on the master.

> I presume that the I2C module gets it's knickers in
> a twist and the h/w messes up PortB, perhaps through some r-m-w
> effect. I noticed a little improvement when the marker was moved
> to PortA2

But you're on a 18F and are only writing to the LAT register to do the
marker, right?  RMW shouldn't be an issue then.

> I understood the I2C module to be edge-triggered via SCL, not
> sampled as RS232 is. Although not actually spelled out in black and
> white, this is what I infer from the manuals and references. For
> example, mention is made of bits changing on clock edge, the block
> diagram is laid out as you'd expect a h/w shift register to be and so
> on. Plus there's no explicit mention of a sampling rate

The data line is changed on the falling edge of clock and read on the rising
edge, or at least that's how its supposed to work, which is different from
how the MSSP works in all cases.  Personally I've been very dissappointed
with Microchip's IIC implementation.  I try to avoid using PICs for IIC or
use my own firmware-only IIC driver.  It's a shame, because PICs would
otherwise be useful in many IIC applications.  I don't know why Microchip
can't get this right, but they show little interest in fixing anything.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\07\04@100619 by olin piclist

face picon face
> Could it be a silicon bug? e.g. divisor not providing the correct
> clocks in the F88.

This doesn't make sense.  There is no internal clock in a slave.  In fact
the clock rate register is re-used for something else in slave mode if I
remember right, like the slave address.

It's been a long time since I used hardware IIC on a PIC because of all the
problems.  My first answer is don't design a system around IIC using PIC
hardware.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\07\04@171447 by Jinx

face picon face
> Are you using the *same* pullup resistor value on both lines?  Are these
> pullups about as low as allowed, like around 2Kohms?

Both are 1k8

> Apparently the original problem is that you are getting a NACK from a
> slave when you were expecting an ACK

True, but not quite that simple. Perhaps the address and a couple of
following data would ACK, then it would degenerate from there, but
that wasn't always the case, so I couldn't say it was anything cumulative.
You'd never get the same pattern of ACKs, NACKs and markers
from successive runnings. I confirmed what I was seeing with the analyser
by having the 452 echo any slave ACKs it saw to one its pins

The only reliable comms were in the address polling routine. Each adddress
is within S and P. Slave boards would always ACK their address. Later
on though, they might not

> Try putting 100pF to ground on the SDA line only, not the SCL line.
>  This will help work around one of the MSSP bugs which causes exactly
> this symptom

Thanks, I'll try that. I'm also going to try the F88 with variety of clock
sources and then substituting it with an F877 to see if I can narrow it
down to some operating condition of the F88. I would like to stick
with the F88 because it has peripherals that are useful on the slave
boards

> > With the old speed, I was seeing things on the
> > analyser that just didn't make sense.
>
> This sounds like a clue.  What exactly on the IIC bus didn't make sense?
>
> > Particularly a marker pulse I was putting out on PortB5.
>
> Now it's starting to smell like a firmware bug on the master.

At the receiver (F88) end

wait11   bank1
        btfss   b_full       ;wait for data byte
        goto    $-1
        bank0
        bsf     marker
        bcf     sspcon,sspov
        bcf     pir1,sspif
        movfw   sspbuf
        movwf   indf
        bcf     marker

a short pulse is output on originally b5, later a2. One very confusing
effect was that in this loop, below 104kHz, you'll see two closely-
spaced marker pulses for this loop, when there should only be one.
I clearly haven't written s/w to make two pulses. Similarly, marker
pulses appear repeated, lengthened and at seemingly random places
throughout the transfer. All of these phantoms just disappear when
the speed is raised above 104kHz and all waveforms are perfect


2005\07\04@175916 by olin piclist

face picon face
Jinx wrote:
> I confirmed what I was seeing with the
> analyser by having the 452 echo any slave ACKs it saw to one its pins

Yes, but what were you seeing on the analyser?  From what you are saying,
the first thing that goes wrong is an ACK is missed.  Do you see this ACK on
the bus?  It would be important to know whether the slave is failing to ACK,
or the master is failing to see the ACK.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\07\04@182331 by Jinx

face picon face
> > I confirmed what I was seeing with the analyser by having the
>> 452 echo any slave ACKs it saw to one its pins
>
> Yes, but what were you seeing on the analyser?  From what you are
>  saying, the first thing that goes wrong is an ACK is missed.  Do you
> see this ACK on the bus?  It would be important to know whether
> the slave is failing to ACK, or the master is failing to see the ACK

What I saw on the analyser (and I am so grateful to have one) was
at times an illogical mess of ACKs, NACKs and markers. To the
point where I was disbelieving the analyser. The 452 unfailingly sees
whatever the slave does, whether it be ACK or NACK. I'd look
at the state of the 452's ACKDT bit and set a 452 pin accordingly.
ACKDT bits were also stored in a couple of variables which were
then displayed in binary on an LCD as another visual verification

The whole thing is going to get picked over today and I'll put the
results up on a page. I'd like to know whether this is something
peculiar to the F88 and, if so, under what conditions. I don't, at
this stage, believe there's a problem on the 452 master side

2005\07\04@184051 by olin piclist

face picon face
Jinx wrote:
> What I saw on the analyser (and I am so grateful to have one) was
> at times an illogical mess of ACKs, NACKs and markers.

Screw the markers.  We want to find out what, if anything, is going wrong on
the IIC bus itself.  To do that you have to get a trace and carefully go
over it.  The only important part is the *first* thing that isn't right.
After that it may easily become a mess, but that doesn't matter.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\07\04@202417 by Jinx

face picon face
> over it.  The only important part is the *first* thing that isn't right.
> After that it may easily become a mess, but that doesn't matter.

That's right. Something initially causes the I2C module to spaz out

BTW, I meant to say the 452's ACKSTAT is examined, not ACKDT

2005\07\05@002411 by Jinx

face picon face
part 1 757 bytes content-type:text/plain; (decoded 7bit)

> Screw the markers

I've left them in, just so you can see. They're on a2, I2C is on b1 b4.
Poor I2C (and what else ?) on PortB can affect PortA by the look of
it. I've seen something like this on a Scenix and it was traced to r-m-w
on PortB

> We want to find out what, if anything, is going wrong on the IIC
> bus itself

It seems to me that the master 452 is OK. The problem looks to
be squarely in the F88. From the tests I've done today it appears
that the F88 and I2C speeds need to be "compatible" for the buss
to work properly. For whatever reason, I think it's just that simple

For now, 4MHz IRC and a little over 100kHz seems to be reliable
and allows me to carry on with other coding







part 2 23884 bytes content-type:image/gif; (decode)


part 3 35 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

2005\07\05@073722 by olin piclist

face picon face
Jinx wrote:
>> I've left them in, just so you can see.

So of the 11 runs in your picture, what is a good one and what is a bad one?

*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\07\05@080509 by Jinx

face picon face
> So of the 11 runs in your picture, what is a good one and what is a
> bad one?

Sorry, should have made that clear. Top trace is SCL, next is SDA,
lowest is the s/w marker (see what I mean about the doubles ?). SDA
consists of address, 5 non-zero data bytes and 4 zero data bytes. The
second half of the SDA trace should be clear (0 data and ACKs)

2005\07\06@075601 by olin piclist

face picon face
part 1 1189 bytes content-type:text/plain; (decoded 7bit)

Jinx wrote:
> Sorry, should have made that clear. Top trace is SCL, next is SDA,
> lowest is the s/w marker (see what I mean about the doubles ?). SDA
> consists of address, 5 non-zero data bytes and 4 zero data bytes. The
> second half of the SDA trace should be clear (0 data and ACKs)

OK, so we finally know that the ACK was being sent on the bus.  The start of
the second trace is interesting, so I snipped it out and attached it.  The
master is sending the address byte, which is for address 16 of a write
transfer.  The bus signals themselves look good, and the first evidence of
something wrong is the master producing the second debug pulse.  This seems
like the thing to investigate.  At this point I would probably set the ICE
to trigger on the second time it produces the debug pulse, then look at the
trace and see how it got there.

There is definitely something wrong in the master, and it's apparently
timing dependent.  It's probably a firmware bug.  It could also be a MSSP
bug (wouldn't be the first time), but I wouldn't start out assuming that.
Changing the clock to make the symptom go away would make be very nervous.


part 2 1273 bytes content-type:image/gif; (decode)


part 3 35 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

2005\07\06@083433 by Jinx

face picon face
> something wrong is the master producing the second debug pulse

Olin, my sincere apologies, but the marker pulse in the diagrams is
produced by the slave, not the master. My fault entirely for not
labelling the traces properly. I appreciate your attention. I do use
another marker (generated by the master on reception of an ACK),
but that's not shown in the diagram. That master pulse always reflects
accurately the state of ACKSTAT and hasn't been a concern

Here are the two ends of the transfer. Currently the slave always
ACKs, so the "bra set_da" is a loose end. With the routines seeming
to be OK now I'm trying to pick up the pieces, so the code isn't as
tight and as comprehensive (the final NACK for example) as it
should be. Because I have the analyser to work with and I can
(mostly) see where things go wrong and can do without error
routines for the time being

Master F452

next_td  movfw   postinc0        ;load element from address array
        skpnz                   ;exit if 0, ie not address
        bra     tst_over

        bsf     startb          ;else start transfer
        btfsc   startb
        bra     $-2

        movwf   sspbuf          ;send address
        btfsc   sspstat,r_w
        bra     $-2

        btfsc   sspcon2,ackstat ;check for ACK
        bra     set_da
        bsf     portb,7         ;slave ACKed address
        usec                    ;show with a pulse
        bcf     portb,7

set_da   movlw   dg1             ;set data array address
        movwf   fsr1l
        clrf    fsr1h

        mov     .9,temp1
data_lp  movff   postinc1,sspbuf
        btfsc   sspstat,r_w
        bra     $-2

        btfsc   sspcon2,ackstat ;check for ACK
        bra     nextd
        bsf     portb,7         ;slave ACKed data
        usec                    ;show with a pulse
        bcf     portb,7

nextd    decfsz  temp1
        bra     data_lp         ;loop for more data

        bsf     stopb           ;done
        btfsc   stopb
        bra     $-2

===================================

Slave F88

wait_bf  bank1
        btfss   b_full       ;wait for data byte
        goto    $-1
        bank0
        bsf     marker       ;put one pulse/byte out on a2
        bcf     sspcon,sspov
        bcf     pir1,sspif
        movfw   sspbuf       ;copy byte, clear BF

        movwf   indf
        bcf     marker

        incf    fsr
        decfsz  temp0
        goto    wait_bf     ;loop for more

2005\07\06@084555 by Michael Rigby-Jones

picon face


{Quote hidden}

The image dosen't have enough resolution to say one way or the other, but the data goes high somewhere very close to the falling edge of the 2nd clock pulse after the start condition.  I'd want to zoom in and check the timing there is ok.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2005\07\06@091820 by Jinx

face picon face
part 1 294 bytes content-type:text/plain; (decoded 7bit)

> The image dosen't have enough resolution to say one way or the
> other, but the data goes high somewhere very close to the falling
> edge of the 2nd clock pulse after the start condition.  I'd want to
> zoom in and check the timing there is ok


part 2 474 bytes content-type:image/gif; (decode)


part 3 35 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

2005\07\06@095302 by Michael Rigby-Jones

picon face


>-----Original Message-----
>From: piclist-bouncesspamKILLspammit.edu [.....piclist-bouncesKILLspamspam.....mit.edu]
>Sent: 06 July 2005 14:18
>To: Microcontroller discussion list - Public.
>Subject: Re: [PIC] Multiple F88 slaves on I2C buss
>
>
>> The image dosen't have enough resolution to say one way or
>the other,
>> but the data goes high somewhere very close to the falling
>edge of the
>> 2nd clock pulse after the start condition.  I'd want to zoom in and
>> check the timing there is ok
>

Well, I guess that's ok then!

Cheers

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2005\07\06@182513 by Jinx

face picon face
> >> 2nd clock pulse after the start condition.  I'd want to zoom in and
> >> check the timing there is ok
> >
>
> Well, I guess that's ok then!

With the addition of 100pF to SDA the 320ns increases to 360ns. (I
just noticed that the trailing 380ns should have read 280ns, sorry for
the typo). It increases to 300ns with 100pF

I've got limited time for further testing at this stage but did try a couple
of things. F88 slave @ 4MHz IntRC, comms work in every case. @
8Mhz IntRC, of these only 107.4kHz works

I2C = 530kHz, SSPADD = h10, SDA L-H = 320ns, H-L = 280ns
I2C = 107.4kHz, SSPADD = h59, SDA L-H = 320ns, H-L = 280ns
I2C = 98.8kHz, SSPADD = h61, SDA L-H = 300ns, H-L = 260ns
I2C = 75.9kHz, SSPADD =  hFF, SDA L-H = 300ns, H-L = 260ns


More... (looser matching)
- Last day of these posts
- In 2005 , 2006 only
- Today
- New search...