Окончание FxS не реагирует на изменение СУВ

[san]

1. Создал на плате VE-02 окончание FxS
2. Со стороны коммутатора TDM изменяю значение СУВа для таймслота соответствующего окончанию с 1 на 0.
3. Ожидаю, что окончание перейдёт из состояния Idle в Dialtone, однако этого не происходит.

Посмотреть на это можно в блоке 192.168.1.104, VE-02 в слоте 5, окончание FXS в канале 2.
Ревизия ПО VE-02 - 24

[alx]

При передаче в плату комбинации СУВ 0101 (вместо исходной 1101) в лог выводится следующее:

Apr  5 06:59:14 comcerto daemon.info sip_ua[451]: fxs.cpp:433: ---> ts=1, state=Idle: CAS A activity detected, ts=1, flags=0000, data=0
Apr  5 06:59:14 comcerto daemon.info sip_ua[451]: fxs.cpp:433: ---> ts=1, state=Idle: CAS event, ts=1, flags=0000, data=11

Первая строчка говорит о том, что CSP получил из ПЛИС нулевое значение СУВ А (то есть из кроссплаты в VE-02 изменение СУВ А действительно поступило).

Вторая строчка говорит, что MSP видит в канале комбинацию СУВ 1011 (десятичное значение 11), что не соответствует ожидаемому 0101. Так как MSP сообщает, что СУВ A (старший бит в тетраде) равен 1 (что соответствует разомкнутому абонентскому шлейфу), канальное окончание остается в состоянии Idle.

Далее я провел еще несколько экспериментов, передавая в канал различные комбинации СУВ. Вот результаты:

Передаваемая комбинация	Принимаемая комбинация
1101	1011
0101	1011
0001	0011
0010	0101
0011	0111

Судя по результатам, MSP принимает комбинацию СУВ со сдвигом на один бит, в результате чего СУВ B видится MSP как СУВ A, а настоящий СУВ А не видится вообще.

Наличие сдвига также подтверждается тем, что плата SW-01 видит от платы VE-02 комбинации СУВ 1110 во всех каналах вместо ожидаемых 1101.

Также сдвиг на один бит наблюдается в речевых каналах - в плату SW-01 приходят комбинации 11101010 вместо ожидаемых 11010101.

В качестве причин такого поведения могу предположить следующие:

• нарушение (неверное расположение - задержка или полное отсутствие) сигнала FS относительно данных на шине между ПЛИС и контроллером VE-02;
• неверная инициализация MSP (сообщили неверное расположение сигнала FS относительно начала цикла) - это мне кажется маловероятным, так как передаются "забитые гвоздями" константы;
• баг MSP (инициализирован правильно, но почему-то работает со сдвигом).

[san]

Какие будут предложения по уточнению причины? Может перезапустить её? Если заработает, то первую причину наверное можно будет исключить... Или может быть можно как-то отдельно MSP переинициализировать?

[alx]

Replying to san:

Какие будут предложения по уточнению причины? Может перезапустить её? Если заработает, то первую причину наверное можно будет исключить...

Если под первой причиной подразумевается "нарушение сигнала FS относительно данных на шине между ПЛИС и контроллером VE-02", то не понимаю, каким образом описанный эксперимент может это исключить. По-моему не может. Мне кажется, что это можно подтвердить/опровергнуть только с помощью осциллографа...

Или может быть можно как-то отдельно MSP переинициализировать?

Можно, но для этого надо специально модифицировать программу. Штатно sip_ua при каждом старте переконфигурирует ПЛИС.

[alx]

Можно зайти с противоположной сотоны. Если нет возможности непосредственно понаблюдать осциллографом расположение FS, можно "потревожить" внутренности ПЛИС, например попереводив ее (с помощью spictl) в режим slave и обратно в master. Или, в конце концов, вообще переконфигурировать ПЛИС без перезапуска программы. Если это "исправит" ситуацию, наверное, можно сделать вывод, что проблема в ПЛИС...

[san]

переконфигурировать ПЛИС без перезапуска программы. Если это "исправит" ситуацию, наверное, можно сделать вывод, что проблема в ПЛИС...

Думаю это разумно. Проведи этот эксперимент, пожалуйста.

[alx]

Replying to san:

Думаю это разумно. Проведи этот эксперимент, пожалуйста.

Провел эксперимент: записал в регистр ПЛИС 0x105 (ms_master) значение 1, а затем вернул значение 0. В результате речевые данные и СУВ от VE-02 в SW-01 стали приходить правильно (11010101 и 1101 соответственно), СУВы от SW-01 MSP также начал воспринимать правильно.

Предполагаю, что при старте ПЛИС какой-то счетчик (?), связанный с выдачей FS, был инициализирован неправильно, в результате сигнал FS из ПЛИС выходил со сдвигом относительно данных на 1 такт. Перевод ПЛИС в режим slave и обратно в master сработал как принудительная переинициализация счетчика, что привело к устранению пробемы.

Считаю, что будет полезно пересмотреть исходник ПЛИС на предмет выдачи FS - вдруг обнаружится причина проблемы...

Также должен отметить, что эксперимент не на 100% чистый, так как при переводе в режим slave ПЛИС перестает выдавать в сторону MSP тактовую частоту и сигнал FS, переводя соответствующие линии в режим входов. Пропадание тактовой частоты могло каким-то образом повлиять на работу MSP.

[alx]

Посмотрел исходный код ПЛИС. Как оказалось, в нормальном режиме (ms_master=0) сигнал FS на контроллер платы идет прямо с кросс-платы, а не формируется внутри ПЛИС. Следовательно, сдвиг на 1 бит возникал где-то в сигналах управления сдвиговыми регистрами. Управление там сложное, сразу не разобраться...

Подключаю автора ПЛИС. Толя, посмотри, пожалуйста, где и как мог возникнуть сдвиг на 1 бит.

[alx]

Ой. Ошибся в имени Толи. :)

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

[alx]

Я здесь вряд ли чем-то еще могу помочь. Передаю тикет Анатолию.