TWI slave state-machine vs SCTRLB for ATtiny 1-Series

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

(I'm targeting an ATtiny214 but the TWI slave section of the Rev C datasheet seems common to other 1-Series. There are no applicable TWI errata for that revision.)

 

Can't help thinking there's something I've misunderstood; I'm puzzled by the slave state-machine diagram (Figure 26-16). Suppose a slave gets SLA+R and won't be able to process the read: it should NACK to inform the master. The master then has two options:

 

-   It can retain ownership of the bus and issue a Repeat-Start, then either retry the slave or address a different one. (That possibility's shown in the diagram, albeit oddly: the NACK transition via S1 returns to a Start but in this context, without an intervening Stop, strictly it should be a Repeat-Start.)

 

-   Instead the master can give up, issuing a Stop to complete the transaction and relinquish the bus.

 

Is there something I've missed which explains why that second option isn't shown in the diagram? It's available if the slave gets SLA+W and won't be able to process it, so why not for SLA+R?

 

From the diagram it appears a read transaction can't be completed with Stop except via an ACK from the slave followed by a data interrupt. That seems a strange exit path if the slave can't process the read.

 

Do we just have to live with it: ACK and proceed to the data interrupt, then issue a completion without returning data which we've told the master to expect? And if so, where's the NACK to prompt the master to quit with Stop, instead of assuming it might be worth retrying endlessly while hogging the bus?

This topic has a solution.
Last Edited: Fri. Feb 5, 2021 - 09:15 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

I think it's there, to the right of SLAVE DATA INTERRUPT.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the quick reply Matt. Yes, that's the diagram all right.

 

But I don't see any indication, on the top row, of a NACK from the slave followed by completion via Stop. it's shown for a write (the bottom row) but not for a read AFAICT.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


You are right.  I looked through the standard and can't find what slave behavior is supposed to be in this case.  It seems to be saying that, for writes, after the master gets a NACK on the address it may still send data.  However, once a slave NACKs it seems it should be in a state waiting for the next start.

 

EDIT: The master is supposed to issue a STOP or re-START.  If a node is in slave mode waiting to be master it seems, it should go to a state waiting for STOP.

Last Edited: Thu. Feb 4, 2021 - 10:21 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The slave effectively goes back to waiting for a start (or repeated start, same thing) when it nacks an address. Whether there is a stop or not makes no difference, even though you can still watch for a stop and do something if seen (the dashed line). Not sure why they have the /W ack path showing both /A A but its probably wrong (look up a samd10 datasheet, same diagram, basically same peripheral, which looks correct).

 

A repeated start or a stop gets you back to square one when you are somewhere in the transaction after ack'ing an address (or to square one point one if sr). In contrast, nack'ing an address already gets you back to square one and you have no need for the stop to 'reset' your twi internal state machine.

 

So for a slave, nack an address when you don't want to answer the phone (they'll call back), nack when you don't want to listen any more (they still have to be the one to hang up), and I guess you are powerless if they keep demanding answers you don't have (just make something up).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is there a particular name associated with that style of state diagram? Never seen one, before. Looks like it might be useful.

 

Thanks,

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks again Matt. Yes AFAICT too, that's the only place where the standard addresses this situation.

 

This part's significant: "The master can then generate either a STOP condition to abort the transfer, or a repeated START condition to start a new transfer." It proves that the diagram - which I suspect just describes the hardware incorrectly - is wrong in this specific case of an SLA+R being NACKed. It omits what the standard clearly allows: the possibility of the master then immediately generating a Stop.

 

As has been pointed out, it'll still work of course. A complying master isn't bound by Microchip's diagram; the slave can't force it to follow a NACKed SLA+R with only a Repeated-Start. If the master generates Stop as the standard allows, the slave will respond correctly. We know that: the slave can recognise Repeated-Start, so it must no longer be clock-stretching and therefore can recognise a Stop too. (The diagram even implies that Stop will be accepted, it just doesn't show it. After returning via S1, a Stop interrupt's allowed for if the slave has enabled it; there'd be no point in that if the slave were still clock-stretching and couldn't recognise a Stop.)

 

I'm going to chalk this up to my standing distrust of Microchip's datasheets and hope they clarify it in a future revision. It still leaves some questions which I'll put in replying to @curtvm.

 

Thanks again for your time and help :-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi @curt, thanks for your reply.

The slave effectively goes back to waiting for a start (or repeated start, same thing) when it nacks an address.

That's true. My point is that the diagram shows it as the only option but according to the standard it's not: an immediate Stop would also comply (and FAIK it's what most masters may do), yet the diagram omits it.

Whether there is a stop or not makes no difference, even though you can still watch for a stop and do something if seen (the dashed line).

Yes, that dashed-line option's reassuring: whether a Stop interrupt's enabled or not, it implies that the slave hardware will correctly accept a Stop after a NACKed SLA+R.

Whether there is a stop or not makes no difference

is only partly true though. It probably doesn't prevent the slave from working (but see below**); however, if the diagram were correct and only Repeated-Start were allowed in this case, then the master could potentially hog the bus for a long time. That's a significant difference from what the standard allows: immediately generating Stop and relinquishing the bus.

 

 

** What prompted this thread is: In this specific case of SLA+R then NACK, how can the slave's Address Interrupt handler in an ATtiny214 use SCTRLB.ACKACT and SCTRLB.CMD to steer transitions correctly? What the CMD and DIR bits offer appear inconsistent with what the hardware will allow as described by the diagram.

 

It now seems clear that the diagram's wrong, but that doesn't mean there's not a corner case in the hardware. I'll be testing the ISR+hardware combination very carefully before I'm convinced that the ATtiny214 slave always plays nice with standards-compliant masters.

 

Again, thanks for your time and advice.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Jim. Me either! Which may say more about my sheltered upbringing than about state machine diagramming, but ...

 

Yes, I like it too. I'd like it more in this case if I had more confidence that it had been used to show the slave's behaviour correctlylaugh.

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

is only partly true though. It probably doesn't prevent the slave from working (but see below**); however, if the diagram were correct and only Repeated-Start were allowed in this case, then the master could potentially hog the bus for a long time. That's a significant difference from what the standard allows: immediately generating Stop and relinquishing the bus.

 

The slave sees no distinction in a start or repeated start. If the slave nack's an address, whether the next action from the master is a stop, repeated start, or stop+start, the slave is waiting at the same place in all cases (looking for a start, and 'noticing' a stop if it desires) and it makes no difference how the master gets to the next start. The slave also has no concept of bus ownership, so what the master does with the bus is up to the master. Any normal master is going to send a stop after an address nack from a slave, but in this case the slave doesn't really care as it is simply now watching for a start, and an address match to whatever you have configured. (See below for possibly a scenario where you use the wrong command).

 

 

** What prompted this thread is: In this specific case of SLA+R then NACK, how can the slave's Address Interrupt handler in an ATtiny214 use SCTRLB.ACKACT and SCTRLB.CMD to steer transitions correctly? What the CMD and DIR bits offer appear inconsistent with what the hardware will allow as described by the diagram.

 

I'm not sure they always get their tables right, and I recall using both the samd10 datasheet and the avr0/1 datasheet to figure out the twi (they do have a table wrong somewhere in twi, but not sure if it was the one you are looking at, could also be an error only in some of the various avr0/1 datasheets).

 

Here is a twis driver I have-

https://github.com/cv007/Avr01Dx...

 

I previously had two functions for ack/nack, and they both used the response command, but I just changed it to ack/nackComplete which is probably more correct. I suspect if a master doesn't follow the 'rules' you can still end up in the isr if comptrans is not used, but if comptrans is used then something like a master reading/writing more data after the slave said 'enough' (nack+comptrans) will just result in a master seeing an idle sda line if reading, and if writing the slave just ignores (no isr).

 

It looks to me the slave only needs to use 2 values for sctrlb- one for ack+response and another for nack+comptrans. The nack is unused for a read so the use of nack is harmless in that case-

address irq - ack+response (we here), or nack+comptrans

write irq - read value, ack+response (more ok) or nack+comptrans

read irq - write value + ack+response, or nack+comptrans (we have no more, master sees 0xFF as value)

read irq also needs to deal with rxack after first data byte sent

 

If using a nack+response instead of nack+comptrans (like I originally did), it could mean you may still end up in the isr if the master decides to go rogue and ignore your nack for some reason. With the nack+comptrans, you are out of the game until another start.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey that's great, Curt - thanks. Yes, I too found the older AVR datasheets useful for clarification, even though their TWI architectures are a little different from the ATtiny214's.

 

My application makes this a bit harder than it might be, by limiting which other implementations are similar: I have to poll the TWI slave in a strictly paced assembler loop. Your driver's a useful example though, especially around your choice of CMDs. (FWIW, the table I'm using for that is just 26-5: Command Settings from the ATtiny214 datasheet Rev C.)

 

 

Cheers :-)