Сбой TWI транзакции после сна на Xmega - PullRequest
Новая
       37

Сбой TWI транзакции после сна на Xmega

1 голос
/ 31 марта 2011

у нас были некоторые проблемы с TWI / I2C после пробуждения от сна с Atmel Xmega256A3. Вместо того, чтобы углубляться в детали TWI / I2C, мы решили использовать прилагаемый twi_master_driver от Atmel, прикрепленный к примечанию к приложению AVR1308.

Проблема в одной или нескольких неудачных транзакциях TWI сразу после пробуждения из спящего режима. На шине I2C, подключенной к XMega, у нас есть несколько потенциометров, термометр и RTC. XMega действует как единственный мастер на шине.

Мы используем функции сна, найденные в AVRLIBC: 

{code for turning of VCC to all I2C connected devices}
set_sleep_mode(SLEEP_MODE_PWR_DOWN);
sleep_enable();
sleep_cpu();
{code for turning on VCC to all I2C connected devices}

XMega, пробуждаемая из сна RTC, которая устанавливает высокий пин. После пробуждения XMega, мы хотим установить значение на одном из потенциометров, но это не удается. По какой-то причине результатом TWI-транзакции является TWIM_RESULT_NACK_RECEIVED вместо TWIM_RESULT_OK в первой транзакции. После этого все, кажется, снова работает.

Мы что-нибудь здесь пропустили? Есть ли известные проблемы с XMega, сном и TWI? Нужно ли сбрасывать TWI сбрасывать любые флаги после пробуждения из сна?

С наилучшими пожеланиями Фредрик

1 Ответ

2 голосов
/ 01 апреля 2011

Существует общая проблема на I2C / TWI, когда внутренний конечный автомат застревает в промежуточном состоянии, если транзакция не завершена полностью. В этом случае ведомое устройство не отвечает правильно, когда обращается к следующей транзакции. Это обычно происходит, когда мастер сбрасывается или прекращает вывод сигнала SCK частично через чтение или запись. Решение состоит в том, чтобы вручную переключить строку SCK 8 или 9 раз перед началом любых транзакций данных, чтобы все внутренние конечные автоматы в ведомых устройствах были сброшены до начала точки передачи, и все они затем ищут свой адресный байт.

...