При доступе к Socrates 24624 со стороны контроллера - выход SCDO всегда равен 1.
По документации он связан со входом SCDI через логическое И.

Тестироваал так - SCDI=0, SCCK=1..3MHz.
Пытался загнать код 7E - без изменений.

Где-то читал, что выход вроде отключен изначально, и надо сначало его включить -
вопрос как - через JTAG или SCI ?

Собственно нужно проверить работает ли данный чип, а то плату изготовили,
а с какой стороны к ней подступиться - вопрос.

Рад бы помочь,но что то не помню таких ног у 22622.
Ксати не поделитесь даташитом на 24624 ? Поставшики с зимы завтраками кормят, ничего толком ответить не могут, на сайте как полагается информации 0 целых хрен десятых. Я даже не знаю это то что надо или нет, интересует 4,6Мбит по паре, т.е. то же что и 22622 но на скорость DSL в два раза выше.

Я не качал док по 22622, а в 24624 это последовательный интерфейс к контроллеру ( параллельного нет пока)

24624 v1.2 теоретически может до 6.3 Мбит, а следующая версия - в два раза быстрее.
На практике всё зависит от версии фирмвары.

В октябре были свободно доступны в инете следующие файлы:

EASY_24624_Toolbrief.pdf
meyer-berg_2.pdf
SDFE4_2_Rev3_V12_UM_SysDescription.pdf
* SDFE-4_ds1_v11usersmanual.pdf
sdfe-4-2-1-pb.pdf
* socrates_16Bis_rev6.pdf

ищите гуглом (сегодня не откликаются, но неделю назад ещё лежали...)
* помечанные - лежат и сейчас

По поводу документации (NDA) и тех.характеристик - позвоните Виталию Шмелёву (ИНТЕХ)
(495) 797-55-35

Сообщение отредактировал _4afc_ - May 15 2006, 06:53

Т.е. чо то типа SPI ?

Наелся в свое время обещаний инфинеона..
То что они пишут в Product brief работает на половину треть из которой работает не так как описано в datasheet

Кое что нашел, остальное возьмем по нда.

Вы брали оценочную плату или делали макет и bga паяли сами ? С бжа опыта нет, страшновато....

Хуже. Синхронный интерфейс.
То что пишет контроллер в SCDI складывается логическим И с внутренним выходом 24624 и подаётся на ногу SCDO. Соответственно если загонять туда 0, то по любому должен выходить 0.
Проблема в том, что туда надо загонять HDLC пакеты на скорости выше 1МГц, со стартом, адресом, данными, CRC и стопом.
Где-то на форуме читал, что при подобном интерфейсе у одной из микрух выход был в другом режиме.
У меня он всегда равен 1.




Разводил сам: 4 слоя, 0.15мм, via0.3, покрытие золото, изготовление - китай.
Сборка макета делалась полностью на стороне.

BGA - ничего страшного. Закройте via маской с двух сторон, сделайте золотые контактные площадки больше отверстий в маске и приготовте 600р за установку.

1. Речь идет о PEF 24624 SDFE - следующее поколение SHDSL чипсетов от Infineon .
2. Что бы перейти в режим полудуплекса по SCI интерфейсу (в которм как раз идет объединение по "и") нужно передать первый пакет CMD_WR_REG_AUX_SCI_IF_MODE(03H). Который собственно это переключение инициализирует. После этого чип отвечает ACK_WR_REG_AUX_SCI_IF_MODE и переходит в режим полудуплекса, что позволяет отслеживать коллизии. До этого момента никакой взаимосвязи м-у SCDI/SCDO НЕТ!!!

Я так и предпологал. Остаётся лишь сформировать этот пакет и отправить его по SCI интерфейсу, но сдесь у меня три загвоздки:
1. Изначально тактирование идёт по фронту или по срезу?
2. На какой минимальной скорости можно передать первый пакет?
3. Содержимое первого пакета?

Касательно содержимого:
Флаг = 7E
Адрес источника = F1 (HOST)
Адрес приёмника = F9 (AUX)
Регистр A9
Данные 03

CRCpoly 1021

Данные передаём 0 битом вперёд, CRC - 15 битом, после 5 единиц всовываем 0.

Передавал

7E [ 8F 9F 95 C0 87 7F ] 7E - по доке, CRC считаю до переворота данных, данные перевёрнуты
7E [ F1 F9 A9 03 87 7F ] 7E - по доке, CRC считаю до переворота данных, данные не перевёрнуты
7E [ 8F 9F 95 C0 E7 4C] 7E - по доке, CRC считаю после переворота данных, данные перевёрнуты
то же, но CRC инвертировано:
7E [ 8F 9F 95 C0 78 80 ] 7E - по доке, CRC считаю до переворота данных, данные перевёрнуты
7E [ F1 F9 A9 03 78 80 ] 7E - по доке, CRC считаю до переворота данных, данные не перевёрнуты
7E [ 8F 9F 95 C0 18 B3 ] 7E - по доке, CRC считаю после переворота данных, данные перевёрнуты

Передавал с тактированием на фронте, правда частота всего 55кГц.
Числа внутри скобок обрабатывались битстафингом.

Всё безрезультатно.

Не могли бы вы написать точную последовательность бит, или указать где я ошибся?

1. SCI тактируется по фронту. Ваша передача по заднему фронту (SDFE хватает по переднему), ваш прием по переднему фронту SCK (SDFE выдает данные по заднему фронту).
2. Минимальная частота SCI у меня получилась порядка 300 кГц (экспериментально)
3. По CRC: данные не инвертируются, CRC сумма начинается с FFFFh (не с 0000h !!! )
4. Пакет: "F1 F9 A9 03 CRCH CRCL", data LSB first, CRC MSB first (тут у вас все правильно)

Спасибо, мне удалось перевести SDFE4(v1.2) в режим полудуплекса.
Основная моя ошибка была в битстафинге (как уже кто-то здесь до меня говорил - ноль надо вставлять после 5 единиц - всегда!).
Передачу и приём надо делать как вы и описали.
А вот контрольная сумма в принципе не важна, чип переходит в полудуплекс ещё не считав второй байт CRC (можно вообще нули передавать).

А вот получить в ответ на CMD_WR_REG_AUX_SCI_IF_MODE(03H) сообщение ACK_WR_REG_AUX_SCI_IF_MODE
мне не удалось. Дело в том что мой SDFE4(v1.2) в режиме 3 выводит на SCDO только то, что приходит на SCDI!
Соответственно ни каких ответов на запись или чтение он в этом режиме не даёт (SCDI=0 и SCDO=0).

В режимах 0 или 1 SCDO=0 (хотя может там открытый коллектор).
В режиме 2 (по умолчанию) я получаю ACK и на чтение и на запись:

HOST: 7E | F1 F9 A9 02 97 5E | 7E
SDFE: 7E | F9 F1 89 FF AA | 7E

HOST: 7E | F1 F9 A8 00 84 2D | 7E
SDFE: 7E | F9 F1 89 02 1D 3B | 7E

Ответ появляется через 3 такта, до и после ответа SCDO=1.
Как видно из ответа SDFE не устраивает моя контрольная сумма, как в прочем и его мне не нравится.

Собственно вопрос - отсутствие ACK в режиме 3 - это особенность v1.2 или мне так повезло?
А то если делать по докам, то ACK должен быть...

У меня SDFE v1.3. Но в errate и delte про это ничего нет. На режим 3 у меня точно приходит ACK (даже если CRC не правильная). Другие режимы включать не пробовал, сразу заработало. С контрольной суммой вы все правильно понимаете, бит RSTA_CRC д.б. 1 (0xА9 valid byte).
А SCDI у вас точно уводится в 1 после передачи пакета?

Гдеж вы v1.3 отхватили? Рассыпухой только v1.2 видел. Или у вас 22624?



Как вы считаете CRC не правильно считаю я или SDFE?



В режиме 3 SCDI=SCDO жёстко. Вне зависимости что и когда передаётся и что приходит после стоп флага. Давал и единицы и нули.

SCDO у меня в режиме 2 до и после флагов равен 1, даже если SCDI=0.
Упакую фирмвару - попробую запуститься на втором режиме.

Я управляю через порты Atmega128 и смотрю изменение бит на ноге - так что всё точно.

Сообщение отредактировал _4afc_ - May 31 2006, 14:03

- да, у меня PEF22624
- по CRC следующее. Перед тем как засунуть ее подсчет в ПЛИС. Делал ее табличным методом прямо в контроллере (у меня тоже АТMega128). Таблицу взял из примеров JAR(кажется).
ф-я:
unsigned int fast_crc16(unsigned int sum, unsigned char data)
{ sum = pgm_read_word_near(crc16_table + ((sum >> 8) ^ data)) ^ (sum << 8);
return sum;
}
таблица стандартная (первый эл. 0x0000 , последний 0x1ef0)

- SDFE c CRC разумеется не корявит.(сейчас это пишу ч-з канал Ethernet-SDFE <-> SDFE-Ethernet)
- Хуже всего, что как и PEF22622 на линии он работает неодназначно.

Немного не в тему, но вопрос есть - что значит неоднозначно? Похоже у нас та же ситуация.
Поясняю: у нас в проекте также стоит этот самый PEF и до боли странно поднимает на линии связь.
Во первых слишком долго (3-15 минут, в идеале до 1 минуты, но это скорее на столе, а не на линии).
Во вторых - непонятно от чего это зависит (loss=33 дБ по его показаниям, изменения мощности сигнала однозначного результата не дают - может поднять при мощности 6.5дБ(мастер) - 9.5дБ(слэйв), а может при 11.5дБ(мастер) - 14.5дБ(слэйв). Это как - от фазы луны зависит что-ли?)
Меняется ли характер работы (и время установления связи) от версии фирмвари?
Хочется понять - только у нас такая проблема, или она вообще присуща этому чипу?

Ну да, так и есть. Проблема не только с параметрами связи (Line Loss, Signal Quality, SnR). Пусть они будут разные от соединения к соединению. Плохо то, что и факт соединения не гарантирован. На одном и том же участке кабеля стал свидетелем 3-х вариантов развития событий:
- активация с первого раза, качество сигнала порядка 5-и
- активация после 5-и минут, качество сигнала около 0-я
- 1 час, активации линии нет
При всех вариантах начальные условия одинаковые (пары кабеля те же, модемы те же (с теми же настройками), каждый эксперимент начинался со сброса питания на обоих модемах)
Получается, что гарантировать работу не могу. Как следствие заниженные паспортные данные модемов по дальности. С globespan-ообразными модемами конкуренции не выходит.
По поводу firmware. Использую COT15/RT15. Версии 16, 17 считаю не жизнеспособными(по помехозащищиенности). Да и проблему с активацией они не решили.

Грустное подтверждение...
А как в этом плане себя SDFE чувствует? Уверенней или так же странно?