SAM3U и I2C, как slave работает не правильно. Опции

[*rust*]

Добрый день!

Пытаюсь реализовать I2S на SAM3U, причем проц. должен работать как slave. Прежде всего хочу отметить что в описании на slave mode есть ошибки.
1.Бит SVREAD регистра TWI_SR говорит об направлении (прием\передача). лог.1-чтение мастером, лог 0-запись мастером, что вытекает из описания битов регистра TWI_SR(стр.656). На рисунке 33-32, стр. 661. наоборот.

2. Бит RXRDY регистра TWI_SR говорит о состоянии приемника. лог 1- был принят байт в регистр приемника TWI_RHR, после последнего чтения, лог 0- не был принят байт в регистр приемника TWI_RHR, после последнего чтения. На рисунке 33-32, стр. 661. опять же наоборот.


Но ошибки это не главное, чудеса начинаются после запуска.

После того как был принят свой адрес, направление передачи "R"-чтение, sam3u посылает ASK-это нормально, и я должен положить байт в регистр передачи TWI_THR. Я так и делаю, но в зависимости от значения байта, мой SAM3U(slave) либо отпускает линию SDA или нет - а вот это уже странно.
Как вообще slave может удерживать линию SDA?

Судите сами.
(адрес slave -10)
1 картинка- после ASKа загружаю 0xFF. sam3u отпускает шину SDA - нормально. Далее мастер формирует ПОВСТАРТ и СТОП-условие
 receive_FF.bmp ( 19 килобайт ) Кол-во скачиваний: 17

2 картинка- после ASKа загружаю 0x01. sam3u не отпускает шину SDA- не понятно. Далее мастер пытается сформировать СТОП, но Sam3u пытается удерживать линию SDA в нуле.
 receive_01_first.bmp ( 18.54 килобайт ) Кол-во скачиваний: 14

3 картинка для информации, что происходит после 2 картинки, когда линия SDA в каком-то непонятном состоянии.
 receive_01_second.bmp ( 18.51 килобайт ) Кол-во скачиваний: 8


А теперь главный вопрос, кто виноват и что делать? Я готов написать в ATMEL, но хотелось бы услышать, мнения форумчан.
Может где-то мой косяк зарыт? Код перекраивал много раз, итог один.

[aaarrr]

Про атмеловский TWI ничего хорошего не скажу. У меня была надежда, что в SAM3 его исправят, однако практика показала, что воз и ныне там.

А вот картинки ваши странные: средний уровень откуда взялся? У мастера push-pull на SDA?

[sonycman]

Про атмеловский TWI ничего хорошего не скажу. У меня была надежда, что в SAM3 его исправят, однако практика показала, что воз и ныне там.

А можете подробнее рассказать про грабли TWI модуля?

[aaarrr]

А можете подробнее рассказать про грабли TWI модуля?

Они практически в полном составе унаследованы от SAM7, разве что убрали наиболее одиозные глюки и добавили PDC. Идеология, однако, осталась прежней: мастер синхронного интерфейса у них может вылететь в overrun/underrun.

Мое общение с TWI на SAM3 закончилось довольно быстро. Сдуру был написан честный драйвер с PDC и прерываниями, однако на тестировании выяснилось, что из 10 слейвов в составе устройства отзываются 8. Два AD9887 принципиально не дают ACK после адреса.
Памятуя безблагодатные пляски с бубном при аналогичных симптомах на SAM7, не стал даже разбираться в причинах сего явления и просто откатился на bit-band.

[sonycman]

Они практически в полном составе унаследованы от SAM7, разве что убрали наиболее одиозные глюки и добавили PDC. Идеология, однако, осталась прежней: мастер синхронного интерфейса у них может вылететь в overrun/underrun.

После беглого прочтения доки заметил пока, что если в режиме Master Receiver не успеть вовремя (перед приёмом последнего байта) взвести STOP бит, то вместо NACK будет выдан ACK и принят лишний байт.
Это оно?

Мое общение с TWI на SAM3 закончилось довольно быстро. Сдуру был написан честный драйвер с PDC и прерываниями, однако на тестировании выяснилось, что из 10 слейвов в составе устройства отзываются 8. Два AD9887 принципиально не дают ACK после адреса.
Памятуя безблагодатные пляски с бубном при аналогичных симптомах на SAM7, не стал даже разбираться в причинах сего явления и просто откатился на bit-band.

Странные капризы. Возможно, слейвы тоже не без греха.
Буду надеятся, что меня не коснётся

[aaarrr]

После беглого прочтения доки заметил пока, что если в режиме Master Receiver не успеть вовремя (перед приёмом последнего байта) взвести STOP бит, то вместо NACK будет выдан ACK и принят лишний байт.
Это оно?

Это еще один прикол, затрудняющий применение PDC на приеме: последний ничего о ACK/NACK не знает.
Если в Master Receiver не прочитать вовремя RHR, то получим OVRE, хотя можно было бы просто притормозить прием.

Странные капризы. Возможно, слейвы тоже не без греха.
Буду надеятся, что меня не коснётся

Да нет, подобное наблюдается исключительно на атмеловских армах. С программным I2C и на других хостах те же AD9887 работают замечательно.
Насчет не коснется сказать заранее нельзя: повезет - заработает, не повезет - увы. Главное, не пытаться расшибить голову в последнем случае.

Вот удивительно: на AVR сделали вполне приличный TWI, а тут просто говно откровенное.

UPD:
Сейчас глянул свежие даташиты на SAM7S/X в плане TWI.

UNRE and OVRE bit fields removed from TWI Status and Interrupt register tables

Гениально: нет битов - нет и проблемы