PCaban

Всем доброго времени суток. Проблема - может быть кто сталкивался. Имеется устройство (к сожалению, не моей разработки), и в нем MAX3107, стоящий на макетной плате в качестве моста между SPI-интерфейсом проца (CC5515) и одним устройством с UART. UART - полнодуплексный, 921600. SPI - от 6 до 15 МГц. CS SPI-интерфейса расходится еще на три устройства, которые в данной конфигурации спят. Обмен через мост идет пакетами по 64 байта. На передачу связка работает без нареканий. При приеме же наблюдаю следующее - в вынимаемом из приемного FIFO потоке байт попадаются перестановки или вставки последовательностей байт из свежепринимаемых пакетов. Например, прилетели пакет P1 и за ним пакет P2. Последовательность вынимаемого из FIFO может выглядеть так: P1[1], P1[2],..., P1[18], P2[1], P2[2], P1[19], P1[20], P1[30], P1[31], P1[21],..., P1[29], P1[30], P[31]. Последовательность получается длиннее на длину "вклинившихся" кусков. Пробовал читать как одинарными обращениями к регистру RHR, так и пакетом (запись "0" в 0х00 MAX, затем пачка чтений). При одинарных обращениях ошибка возникает заметно реже (1-2 в 32 мбайтах потока), чем при пакетных (1 ошибка на 30-40 кбайт). При пакетной записи проблема отсутствует (проверяли логическим анализатором/бордой для приема UART на 921600).

Забыл отписать - проблема оказалась стара как мир, но я по серости узнал о ней случайно, и только с помощью осцилла. Втыкаю осцилл в шину и сразу же вижу, что из UART-а в блюгиговскую плату данные идут коротенькими пакетами с огромной паузой в 1 мс. Изредка проскакивают моменты, когда 1мс интервал заполнен передаваемыми словами очень густо. Стало ясно, что WT32 не виноват - просто ему не приходит достаточно данных для передачи. Нет данных - нет и потока в SPP-соединении. Ну, соответственно, и приема с нужной скоростью на другом конце. Как оказалось, мосты USB-COM в принципе не могут дать приличного потока данных из-за драйвера, т.к. у них обращение к регистрам USB-устройство драйвер привязывает к таймеру на 1 КГц. А буфер у Prolific-овского чипа, на котором сделана львиная доля ширпотребных переходников, крохотный (по 16 байт в одну и в другую сторону). Вот он и выдает поток в десятки кбит/c. Заменил переходники USB-COM на PCI-платы (брал первые попавшиеся Orient) - поток подпрыгнул раза в три (270-310 кбит/c). При этом видно, что в принципе беда у адаптеров та же (паузы в потоке передаваемых слов) - просто больше буферы (по 128 байт и на TX, и на RX) и расторопнее драйвер. В моем случае проблема возникла еще на этапе установки - финский инсталлер создает неработоспособное сочетание путей, и интерпретатор Питона встает аж до показа GUI. Времени разбираться просто не было - схватил другой.

Отдельные товарищи не стесняются его печь прямо из комбинаторики :) GC не страшен в том случае, если не ветвится. Если ветвится - ну, суицид. Вопрос: у Циклона III же, если не ошибаюсь, должны быть двухпортовые блоки памяти, аналогичные BlockRAM у хилых - там в принципе можно просто подключить двух абонентов в расфазированными клоками (напр. процессор снаружи и логику, сделанную в самом ПЛИС).

Спасибо. Жалко, железо нужно допиливать. Программировать 2540 на собственный стек нет, конечно, резона :( Спасибо. Жалко, железо нужно допиливать. Программировать 2540 на собственный стек нет, конечно, резона :(

Спасибо. Жалко, железо нужно допиливать. Программировать 2540 на собственный стек нет, конечно, резона :(

Peps, Раз уж можно спросить :) Сколько через него удается прокачивать, если не писать с нуля софт для СС2540 (т.е. на BGScript)? Просто встал в полный рост вопрос - WT3x или имеющееся железо с BLE112. Коллеги с помощью финского софта получали предельно грустные цифры, около 2-3 кБайт/c - на порядок меньше, чем хочется.

Всем доброго времени суток. Упали мне в руки два блюгиговских кита с WT32. Потребовали наскоро (ха-ха) испытать чип на пропускную способность при использовании UART/USB (USB временно отпал в связи с врожденной инвалидностью iWRAP). Оба кита подключил к ПК под Win7 через Prolific-овские адаптеры PL2303X, драйвер 3.4.36.247 (июль 2012). Пробую под терминалами (PuTTY, Hyperterminal от хрюши, т.к. блюгиговский BGTerm упорно не желает работать). Flowcontrol аппаратный. WT32 прошит iWRAP 4, билд 317. 1. Опробовал обмен путем передачи на WT32 файла с заведомо быстрого BT-устройства, профиль OPP. Настройка UART WT32 - 115кбод, измеренная скорость передачи близка к теоретическому максимуму (~80кбит/c). Настройка UART WT32 - 56кбод, скорость передачи ~40кбит/c. Настройка UART WT32 - 230кбод, скорость передачи ~110кбит/c...? Настройка UART WT32 - 460кбод, скорость передачи ~110кбит/c...?! 2. Два WT32, обмен друг с другом, немультиплексированный SPP, скорость UART-ов 460кбод, аппаратный flow control. Проверяю путем выбрасывания в терминал одного из модулей текстовика (после установления "прозрачного" режима). Скорость обмена катастрофическая (ниже 25кбит/c). Явно что-то делаю очень не так, но что? Поискал по форуму и в инете вообще - проблема встречается, но не в столь мрачном виде. В тесте с SPP на подозрении программы терминала (не успевают пропихивать байтовый поток из файла в COM-порт?). В тесте с OPP не знаю на что думать. Формально последний датащит на iWRAP обещает Но вот что мешает выбросить данные на достаточной скорости при профиле OPP - не понимаю. В userguide на iWRAP встречал цифру в максимум 50 кбит/c при использовании OBEX - очевидно, что это не совсем так, но и потолок в 110кбит/с выглядит престранно. З.Ы. Конечно, следовало бы или прикрутить к обеим китам по платке с контроллерами (для управления и передачи данных по UART) и обойтись без такой непрозрачной вещи, как виртуальный COM-порт и программный терминал. Или браться за xIDE и программировать BlueCore, стоящий на модуле.

Сами удивляемся. Но, по правде сказать, проектировщик платы допустил некоторую бардачность в части разводки и обвеса резетов и пинов жтага, так что мыши теперь колются и едят кактус :05: По п.1 большое спасибо, у нас три человека и ВСЕ намертво забыли об этой возможности :laughing: Оживим питание платы (если получится) - начнем с этого. З.Ы. глюк при понижении частоты жтага дополнительно в 4 раза (pod_tckpredivena=YES) у нас тоже был, по крайней мере с самоделкой (кит с С6713 устойчиво соединяется с CCS и при 20МГц на JTAG)

UPD: :smile3046: На плате накрылось питание ядра третьего Спартана и C6713 (1.2В) - из-за пробоя конденсатора идет пила 20КГц от 1.2 до 1.4В. Проц при этом упорно не соединяется с эмулятором (что вроде бы логично, но заставляет задуматься о покупке веночка и пузыря для поминок по красивому квадратику в шариковом корпусе) Перед этим успел убедился - TCK и TCK_RET действительно соединены прямо под колодкой JTAG-а. Увы, не могу сказать, что разрезание дорожки и подпайка проводков разной длины что-то изменили. Видимо, доступ по порту все же нормальный (например, нехитрая прога счета импульсов на GPIO 4 раза в секунды вываливает длинное сообщение и кучу цифр в консоль CCS. Сигнальные линии при этом загружены сильней чем когда-либо, но сбоев не видно). Также отпали версия с неправильным резетом логики JTAG-порта на самом C6713 (пуллап на #RST давил #TRST = 0, подаваемый эмулятором при коннекте к процессору).

К сожалению, не успел посмотреть печать :( зная наших конструкторов - соединение TCK и возвратной линии может быть и где-то на полдороге между процессором и колодкой. На колодке разница TCK и TCK_RET невелика, по осциллографу практически полное совпадение в середине амплитуды (около 1.5В) и разбег 2-4нс на других участках. Спасибо за наводку, хоть документацию копнем в этом направлении, ибо пока ничего кроме "Designing for JTAG emulation" (который из мануалов CCS) не изучили :)

Всем доброго времени суток. Столкнулись со следующей проблемой: имеется кит DSK6713 и плата-самоделка с TI C6713B (версия 2.0) в конфигурации, аналогичной DSK6713 - к самому С6713В подключены на EMIF ПЛИС и флэшка с CFI-интерфейсом на правах программного РОМа). С китом использовался SAU510-USB и CCS 3.1, никаких затруднений не возникало. При подключении эмулятора к самодельной плате соединение CCS с процесором устанавливается, есть возможнсоть без сбоев закачать программу и запустить ее на выполнение. В некоторых ситуациях процессор после этого нормально функционирует (например, пашет тестовый обмен с ПЛИСом по GPIO и последовательным интерфейсам). А вот при попытке остановить выполнение программы, запущенной без точек останова, или на остановленной программе включить/выключить точку останова - после непродолжительного раздумья CCS выбрасывает табличку: -- Trouble Halting Target CPU: Error 0x80000020/- 1070 Fatal Error Execution. An unknown error prevented the emulator from accessing the processor in a timely fashion.It is recommended to RESET EMULATOR. This will disconnect each target from the emulator. The targets should then be power cycled or hard reset followed by an emureset and reconnect to each target. -- То же самое происходит при некоторых операциях ввода/вывода. Например, при попытке самодельным FBTC стереть флэшку процессор подает на шину памяти ровно четыре слова (а для стирания их, как на зло, надо шесть :) ), после чего - отсоединение от JTAG-а. Все перечисленные операции на DSK проходят на ура. По этой причине под подозрение попала электрика самоделки, отличающаяся от "доски" следующими моментами: - сигнал TRST# из-за косяка в проектировании в итоге был подпаян к RST# (последний на внешней подтяжке). - CLKMODE0 оставлен висеть в воздух в уповании на внутренний пуллап (на DSK сделана внешняя подтяжка через 1кОм). - нет буферизации сигналов JTAG-интерфейса, т.е. процессор подключается непосредственно к колодке (проводники около 3см). Возвратный TCK_RET в том числе. При этом, воткнувшись осциллографом в сигналы JTAG-интерфейса, криминала в форме сигналов не заметил, за исключением изредка встречающегося в линии TDO длинного пологого фронта, несколько напоминающего переходы напряжения в линиях с абонентами с третьим состоянием (к сожалению, осциллограф упорно не хотел слать скрин на флэшку :(). Такие же переходы обнаружил и просматривая TDO при подключении эмулятора к DSK. - напряжение ядра из-за кривоватой схемы питания с периодом около 30КГц поднимается короткими треугольными импульсами с 1.2 до 1.4В. Однако никаких других колебаний напряжений питания ни по 1.2В, ни по 3.3В не обнаружили, в т.ч. при попытке записать больше четырех слов в EMIF. В остальной плата-самоделка идентична DSK по связям. Встречался ли кто-нибудь с такой проблемой? Поискав, нашел несколько людей с похожей ситуацией на западных форумах, но где корень зла - в линии JTAG-проц (интуитивно вроде бы оно, кривая линия мешает обмену), или еще где-то - установить не могут.

Концентрация институтов на юге Москвы иногда поражает )) P.S. Отправил резюме в приват.