Rainbow Electronics AT88SA100S - Manual (Page 11)

AT88SA100S [ Preliminary]
11
8558A–SMEM–03/09
3.4.1. IO Timeout
After a leading transition for any data token has been received, the device will expect another token to be transmitted
within a t
TIMEOUT
interval. If the leading edge of the next token is not received within this period of time, the device
assumes that the synchronization with the host is lost and transitions to a sleep state.
After the device receives the last bit of a command block, this timeout circuitry is disabled. If the command is properly
formatted, then the timeout counter is re-enabled with the first transmit token that occurs after t
PARSE
+ t
EXEC
. If there is
an error in the command, then it is re-enabled with the first transmit token that occurs after t
PARSE
.
In order to limit the active current if the device is inadvertently awakened, the IO timeout is also enabled when the
device wakes up. If the first token does not come within the t
TIMEOUT
interval, then the device will go back to sleep without
performing any operations.
3.4.2. Synchronization Procedures
When the system and the device fall out of synchronization, the system will ultimately end up sending a transmit flag
which will not generate a response from the device. The system should implement its own timeout which waits for
t
TIMEOUT
during which time the device should go to sleep automatically. At this point, the system should send a Wake
token and after t
WLO
+ t
WHI
, a Transmit token. The 0x11 status indicates that the resynchronization was successful.
It may be possible that the system does not get the 0x11 code from the device for one of the following reasons:
1. The system did not wait a full t
TIMEOUT
delay with the IO signal idle in which case the device may have interpreted the
Wake token and Transmit flag as a data bits. Recommended resolution is to wait twice the t
TIMEOUT
delay and re-
issue the Wake token.
2. The device went into the sleep mode for some reason while the system was transmitting data. In this case, the
device will interpret the next data bit as a wake token, but ignore some of the subsequently transmitted bits during
its wake-up delay. If any bytes are transmitted after the wake-up delay, they may be interpreted as a legal flag,
though the following bytes would not be interpreted as a legal command due to an incorrect count or the lack of a
correct CRC. Recommended resolution is to wait the t
TIMEOUT
delay and re-issue the Wake token.
3. There is some internal error condition within the device which will be automatically reset after a t
WATCHDOG
interval,
see below. There is no way to externally reset the device – the system should leave the IO pin idle for this interval
and issue the Wake token.
3.5. Watchdog Failsafe
After the Wake token has been received by the device, a watchdog counter is started within the chip. After t
WATCHDOG
, the
chip will enter sleep mode, regardless of whether it is in the middle of execution of a command and/or whether some IO
transmission is in progress. There is no way to reset the counter other than to put the chip to sleep and wake it up
again.
This is implemented as a fail-safe so that no matter what happens on either the system side or inside the various state
machines of the device including any IO synchronization issue, power consumption will fall to the low sleep level
automatically.
3.6. Byte and Bit Ordering
The device is a little-endian chip:
• All multi-byte aggregate elements within this spec are treated as arrays of bytes and are processed in the order
received.
• Data is transferred to/from the device least significant bit first on the bus.
• In this document, the most significant bit appears towards the left hand side of the page.