IIC Status Register... WTF?

[Wings]

S908GT32A, 14.68Mhz bus, IIC Clock rate divider=7 (div by 40) = 370KHz IIC clock

Ok, before I get into any serious code for the IIC module I thought I'd have a look at what goes on in the status register (since the data sheet just confused the crap outa me). I wrote the code below to do that. It just generates a start condition and sends an address byte out to nowhere (since I have no device at address $CC). I specifically wanted to know when the TCF bit (7), the BUSBUSY bit (5), the IICIF bit (1) and the RXAK bit (0) would become set.

               LDHX           #$100
               MOV           IIC1S,X+        ;WHAT IT IS B4 WE FOOL WITH IT.
               MOV           #%10110000,IIC1C  ;IICEN+MST+TX = START CONDITION.
               MOV           #$CC,IIC1D      ;SEND ADDRESS BYTE.
SAVSTAT        LDA           IIC1S           ;3
               STA           0,X             ;2 SAVE STATUS REG.
               AIX           #1              ;2 FROM $100 AND UP.
               STA           SRS             ;4 (DO THIS THE LONG WAY AND
               CPHX          #$800           ;3 CONSUME EXTRA TIME TO REDUCE
               BLO           SAVSTAT         ;3 THE NUMBER OF DATA POINTS.)
                                             ;= 17CYC * 68nS = 1.16uS/loop
               NOP                           ;BREAKPOINT HERE.

The status register is written to the buffer every 1.16uS, and here it is:

00 Reads 00 before I do anything to the IIC.
00 Reads 00 immediately after getting it started.
80 TCF set after a few microseconds.
A0 Then BUSBUSY a uS later.
21 TCF cleared (huh?), RXAK set (huh?)
25 SRW set
25
25
25
24 RXAK cleared at 12 uS (?).
24
24
20 SRW cleared.
20
21 RXAK set, again!
21
21
25 SRW set, again.
25
24 RXAL cleared, again.
24
20 SRW cleared, again.
20
20
21 RXAL set yet again.
A3 TCF set, IICIF set after 30uS.
A3...A3 to end of buffer.

Kinda makes me wish I hadn't done this now, since I'm more confused than ever. Does anyone have any clues as to what's going on here?

But this is the kicker... even though I have it set for a 370KHz clock, the actual clock rate is 100KHz as seen on a scope. The IICIF bit is becoming set as though it was transmitting at 370KHz (30uS for 9 bits, + or -), but it's not. I'm lookin at it, and it's 100KHz. Start condition + 9 bits in 93uS.

If I reduce the IIC clock down to 50KHz (ICR=$24, divide-by = 288), I get TCF and IICIF both set after 56uS, but the IIC clock this time really is 50KHz, which means the byte isn't finished sending for 190uS (as seen on a scope). So why is TCF and IICIF becoming set way before the byte is complete?

[peg]

Hi Wings,

As I am considering a IIC device on a GT16 project I took a look at what you discovered here.
I duplicated the test you did using SCM on a GB Demo board and here I found similar results to what you did in that the status went through many intermediate states but settled on A3 earlier than it should have.
Then I decided that SCM is not the best mode to use so I set up the ICG to use the on board 32KHz xtal and step it up to 4.19MHz.
I then used /40 like you to achieve a IIC clock of 104.825KHz.
This come out on the scope at 86us for the 9 bits as expected (85.857us calc)
Now I get nearly exactly the pattern of status that you describe (just with a 1 sample jitter sometimes)
BUT the settle to status A3 occurs after 24/25 cycles which is 10us after the ninth bit, which pretty much makes sense.

Now looking back at your results it seems that your clock may be slower than you think it is. I have no explanation for the strange status states of SRW and RXAK though.

80   TCF Before start
80   TCF Start
80   TCF
A0   TCF, Busy
21   Busy, RXAK
25   Busy, SRW???, RXAK
25   Busy, SRW, RXAK
25   Busy, SRW, RXAK
25   Busy, SRW, RXAK
25   Busy, SRW, RXAK
24   Busy, SRW
24   Busy, SRW
20   Busy
20   Busy
21   Busy, RXAK
21   Busy, RXAK
21   Busy, RXAK
25   Busy, SRW, RXAK
25   Busy, SRW, RXAK
24   Busy, SRW
24   Busy, SRW
20   Busy
20   Busy   9th clock done, no ack as no slave
20   Busy
21   Busy, RXAK
A3   TCF, Busy, IICIF, RXAK
A3   etc

Here is my entire test code:

Code:

$Include "9S08GB60v1rdp.inc"               org           RomStart*********** Set-up ICG to clock the bus at 4.193 MHz **********************start          CLRA               MOV           #%00000000,ICGC2 ;               MOV           #%00111000,ICGC1 ;lockchk        sta           SRS               BRCLR         LOCK,ICGS1,lockchk  ;loop until FLL locks                 mov           #$07,IICF      ;/40, 10 hold               LDHX          #$100               MOV           IICS,X+        ;WHAT IT IS B4 WE FOOL WITH IT.               MOV           #%10110000,IICC  ;IICEN+MST+TX = START CONDITION.               MOV           #$CC,IICD      ;SEND ADDRESS BYTE.SAVSTAT        LDA           IICS           ;3               STA           0,X             ;2 SAVE STATUS REG.               AIX           #1              ;2 FROM $100 AND UP.               STA           SRS             ;4 (DO THIS THE LONG WAY AND               CPHX          #$800           ;3 CONSUME EXTRA TIME TO REDUCE               BLO           SAVSTAT         ;3 THE NUMBER OF DATA POINTS.)                                             ;= 17CYC * 238nS = 4.05uS/looploop           NOP                           ;BREAKPOINT HERE.               sta           SRS               bra           loop               org           $fffe               dw            start

 

[Wings]

"Now looking back at your results it seems that your clock may be slower than you think it is."

My thoughts exactly when I first saw this. But then, I had already checked my timers for the proper periods and they were right. Nevertheless, I wrote some code to bang a pin through a loop and inserted that code just before my IIC test. The bus really was 14.68MHz.

Can you try using an ICR of $00 (divide-by-20) to increase your IIC clock frequency to 200KHz and see if you really can get that? And also see when your $A3 appears in the status reg.


In my app I've got nothing to do while I wait for the IIC transfer (other than to respond to several interrupts that may fire), so I'm seriously considering going back to the way I've always done IIC, and that is the ole bit banging method. I wanted 400KHz so I don't spend so much time waiting on the IIC transfers and it seems that may be the only way to do it. On my IIC bus I've got a speech chip, a clock chip, 2 8KB EEPROMS, and an LED driver chip. It's the EEPROMS where I want speed because at times I have a lot to transfer.

[Wings]

Hey Peg, you were right! It was my busclk, not up to speed when my code was executed.

Here's what was going on... When I saw your code and noticed you were testing the LOCK bit it got me looking at my code. I was testing the DCOS bit. LOCK is good, DCOS is bad. Cause DCOS will set if the crystal isn't up to speed yet, and for 32KHz that can take a while. Anyway, that code I put in to test my busclk, just prior to my IIC test code, was showing me that I in fact DID have 14MHz. Because by the time I run the code then twirled around in my chair to look at the scope, the thing had locked at 14MHz. When I would run my IIC code (which was immediately after testing the DCOS bit) the FLL had yet to bump itself up to a 14MHz bus.

So there...and now I may use the IIC module after all.

Thanks for your input.

Still doesn't explain all the thrashing about that the IIC status register does. I'll have to go back and test that again. I won't feel good about using it until I understand it.