[*rust* 0]

Добрый день!

 

Пытаюсь реализовать 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

2 картинка- после ASKа загружаю 0x01. sam3u не отпускает шину SDA- не понятно. Далее мастер пытается сформировать СТОП, но Sam3u пытается удерживать линию SDA в нуле.

receive_01_first.bmp

3 картинка для информации, что происходит после 2 картинки, когда линия SDA в каком-то непонятном состоянии.

receive_01_second.bmp

 

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

Может где-то мой косяк зарыт? Код перекраивал много раз, итог один.

 

 

[aaarrr 69]

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

 

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

[BurglarInt 0]

 

*rust*, Здравствуйте, у меня сейчас те же проблемы, которые были у тебя (AT91SAM3U). Каким образом с тобой можно связаться (желательно по e-mail) ?

Изменено 1 июня, 2011 пользователем IgorKossak
Бездумное цитирование

[*rust* 0]

[email protected]

 

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

 

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

 

Slave не отпустил линию, а мастер FTDI232 пытается утянуть эту линию в 1. Девайс, на котором реализован мастер-штука проверенная.

[BurglarInt 0]

*rust*, письмо на твой e-mail я отправил, спасибо.

[aaarrr 69]

Slave не отпустил линию, а мастер FTDI232 пытается утянуть эту линию в 1. Девайс, на котором реализован мастер-штука проверенная.

Может и проверенная, но тогда это уже не I2C (как, впрочем, и у атмела), ибо там ничего "утягиваться" в '1' не должно по определению.

[*rust* 0]

У FTDI232 100 процентов не I2C, многое не по спецификации. Т.к FTDI232 можно сконфигурировать для разных интерфейсов, то вполне возможно это какие-то внутреннее дела.

[sonycman 0]

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

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

[aaarrr 69]

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

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

 

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

Памятуя безблагодатные пляски с бубном при аналогичных симптомах на SAM7, не стал даже разбираться в причинах сего явления и просто откатился на bit-band.

[SergeyDDD 0]

По идеологии I2C, таких ступенек как у Вас принципиально быть не может.

SDA и SCK мастера и слейва должен работать на открытом коллекторе и обе линии подтягиваются внешним сопротивлением в ~2,7K.

При этом при возникновении конфликтной ситуации на линиях шины (0 с одной стороны и 1 с другой) в любом случае должен получаться логический 0, а не такие ступеньки как на Вашей осциллограмме.

Такое впечатление что порты линий TWI не сконфигурированы как открытый коллектор.

Собственно в такой ситуации сформировать ACK невозможно, так как ступенька будет восприниматься как лог. 1

[sonycman 0]

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

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

Это оно?

 

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

Памятуя безблагодатные пляски с бубном при аналогичных симптомах на SAM7, не стал даже разбираться в причинах сего явления и просто откатился на bit-band.

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

Буду надеятся, что меня не коснётся :)

[aaarrr 69]

После беглого прочтения доки заметил пока, что если в режиме 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

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

[sonycman 0]

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

это грустно.

 

В мануале по поводу I2C с PDC в режиме мастера на приём сказано задавать длину пакета как size-1.

Ну это понятно, STOP то надо выставлять после приёма предпоследнего байта.

Ну а сам последний байт надо считывать уже ручками? DMA его не читает?

 

Может ли TWI модуль выдавать REPEATED START (режим мастера)?

Судя по документации, он это делать клинически не обучен :(

 

И ещё - нашёл в регистре TWI_SR описание для битов ENDRX, ENDTX, RXBUFF и TXBUFE.

Только про них больше нигде ничего не сказано.

Что это такое? Останки какой-то вырезанной фичи по буферизации?

 

ЗЫ: а, нашёл по последнему вопросу описание в разделе PDC... :)

[aaarrr 69]

Ну а сам последний байт надо считывать уже ручками? DMA его не читает?

Ручками, ага.

 

Может ли TWI модуль выдавать REPEATED START (режим мастера)?

Судя по документации, он это делать клинически не обучен :(

При чтении делает автоматом, по желанию пользователя не обучен.

 

[*rust* 0]

Привожу мою переписку с тех. службой ATMEL, хотя они на последнее мое письмо не ответили и я решил проблему(хоть и не полностью).

 

I am trying to launch TWI in slave mode, but I have some problems.

First of all I would like to say that datasheet on SAM3U series has some mistakes in chapter of description slave mode:

1. Bit SVREAD in the TWI_SR indicates the direction of the transfer. 1- indicates that a read access is performed by a Master, 0-indicates that a write access is performed by a Master, according to description on page 656. If you look at example of read and write operations in Slave mode on fig. 33-32, page 647, you can notice that the work of SVREAD is wrong.

2. Bit RXRDY in the TWI_SR indicates that character has been received in the TWI_RHR, and software can read it, 1- a byte has been received in the TWI_RHR since the last read, 0- no character has been received since the last TWI_RHR read operation, it is according to description on page 655, but on fig. 33-32, page 647 this bit works wrong.

As for work of TWI in Slave mode, there are two strangeness:

1. After getting SADR+R has been received, sam3u sends ASK-this is normal, and I have to put byte into register transfer TWI_THR. I am doing it, but depending on the value of byte, sam3u (slave) locks SDA line in "0" or unlocks in "1". How do slave can hold the line SDA?

On the picture 1.bmp is correct behavior of sam3u. I put 0xFF in TWI_THR in after SADR+R. On the picture 2.bmp you can see what happens if I put another byte (not 0xFF) in TWI_THR in after SADR+R, for example 0x01.(SADR=10)

What should I do to make sam3u works correctly with any bytes as shown in 1 picture?

 

2. I use the interrupt method for the handle of TWI. My first interrupt occurs when SADR+W/R has been received, TWI_IER= SVACC and TWI_SR=0xF01C. In the body of handler interrupt I switch off SVACC in TWI_IDR and change TWI_IER = TXRDY | EOSACC (for example). After exit from interruption I get back in the handler of interrupt second time, and TWI_SR=0xF018, although this should not happen. According to TWI_IMR and TWI_IER values I have to come in the interrupt when a flag TXRDY or EOSACC set in TWI_SR. My third interruption is correct, because TXRDY or EOSACC set in TWI_SR.

I cannot understand why second interruption occurs. What should I do to fix it?

 

 

Их ответ:

________________________________________________________________________________

____

You are right regarding the flowchart. I asked to modify it, thanks for the feedback.

 

Regrading the 2 questions you have:

1. I don't see any obvious reason why the SDA line is not released. I you could provide your code I could have more inputs to give.

2. Do you write some data in the TWI_THR in your interrupt handler? If no the TXRDY flag could be set to 1, that is why you see the second interrupt.

If you could send the code of the interrupt handler that would be helpful.

 

Thanks,

 

 

Best Regards,

Guylain Pouly

Atmel Technical Support Team

________________________________________________________________________________

_____

 

мое 2 письмо:

Have a nice day.

 

Guylain, thanks for your reply.

 

In the attachment you can find the code.

 

Maybe I am making something wrong, but I've tried a lot of variants to solve

problems. The code which is attached is a final version, but it also has the

same problems. I think, the main trouble is not release the SDA line, after

ASK. As I can understand the slave device (sam3u) is waiting clock from the

master when I put the byte in TWI_THR, and hold SDA in null.

 

Waiting for your reply!

 

 

Вот уже три недели жду ответа нет.

________________________________________

1.bmp

2.BMP

TWI_code.txt