В руководстве указана скорость суммарная в обе стороны, полученная на специальной тестовой задаче. К указанной в руководстве скорости USB 16 MB/s  это тоже относится.

Константин!

1), 2) спасибо, понял

3)

Странность portENABLE_INTERRUPTS в том, что в sti передается не то, что вернул cli. Наверное, зачем-то так нужно, но как-то непривычно. Кроме того, в других местах кода Вы обкладываете sti/cli в ssync, а здесь нет.

etharp_* вызываются из контекста f_th_ethernetif_input, а lwIP любит, чтобы все вызывалось из tcpip_thread. М.б. это и не существенно. В принципе, f_netif можно ставить NETIF_FLAG_ETHARP, и тогда арпом будет заниматься tcpip_input в своем любимом треде.

Казалось, что есть еще пара странностей, но, похоже, ошибся.

В код Ethernet полез т.к. в обработке данных постоянно случаются вроде бы неоправданные затыки в 1-2 миллисекунды, коих не наблюдается в режиме USB. Вообще Вы сурово подошли к задаче – аж 6 тредов с кучей семафоров. Чем raw_api с callback-ами не понравилось?

4) Мне надо не столько собрать, сколько обсчитать данные. Модельная загрузка — 400ксэмплов/сек синуса на вывод в ltr34 + 400ксэмплов/сек на ввод c АЦП. При этом скорость обмена с ПК всего ок. 25кслов/сек. Release-build в режиме USB вполне пристойно справляется. В режиме Ethernet получается пока на половинной скорости – дальше начинаются затыки.

Александр! Что-то Вы клевещете на свое железо. Собрал стандартную прошивку с включенной оптимизацией  (заплатка все та же — медленный SDRAM, без лампочек; HAL собран в Debug). Уже 40 минут успешно гонит 400кслов/сек (2 канала LTR11 по 200 кГц). Синусоида в LGraph нормальная, без характерных разрывов. Грузит правда сильно — 20-30% ltrserver, 30-50% LGraph.

Почему в sti не то, что вернуло cli: поскольку на блэкфине cli/sti изменяет многобитовую маску, а не как обычно один системный бит, то эту маску надо хранить и передавать в sti.
Так, как сделано, получается одноуровневая конструкция (после portENABLE_INTERRUPTS прерывания всегда разрешены, вложенных disable disable enable enable быть не должно), а если возвращать то, что вернуло cli, то надо сделать еще обязательно локальную переменную для хранения этого значения, и получится многоуровневая критическая секция.

Как по мне так проще держать локальную переменную, чем помнить о глобальной g_save_imask. Ну да это дело вкуса.

Просветите, пожалуйста, ssync() сразу после cli() - это чтобы не упасть в прерывание в первых нескольких инструкциях после cli()? А зачем ssync() после sti() (например, в GetNumPPIDataReady)?

Ну в этом проекте маска разрешенных прерываний не меняется, эта переменная устанавливается в init.

Насчет SSYNC/CSYNC написано в ADSP-BF53x/BF56x Blackfin Processor Programming Reference глава 16.
CLI/STI модифицируют core MMR - IMASK. Возможно, достаточно и csync.

Тайминги SDRAM к зависанию, похоже, отношения не имеют. Эффект появляется, когда лампочка U желтая, и исчезает, когда не желтая. Т.к. лампочки управляются по SPI, похоже, что проблема именно в нем. Я попробовал подергать делитель в InitializeSPI() (было 13МГц, поставил 11). Debug-build даже отработал больше часа с желтой лампочкой. Release, правда, сразу завис. Есть еще идеи?

В исходную прошивку просто вставил в основной цикл g_mode_ULED = e_LED_Orange чтобы пошли AlteraWriteCommand. Теперь в режиме USB «событие» происходит через считанные секунды после сброса! Очевидно, природа та же, просто в режиме Ethernet в этом цикле Sleep(10), а в режиме USB цикл крутится с периодом в несколько десятков микросекунд.

Очень похоже, что рано или поздно случается какая-то накладка в spi read/write и на плиску уходит ноль — сброс. После этого плиска «умирает», а все остальные интерфейсы продолжают исправно работать.

Константин! Пожалуйста, посмотрите десяток строк в _ReadSPI_asm _ExchangeSPI_asm_WriteSPI_asm на предмет anomaly или возможных гонок со статусами SPI. Для меня это новая архитектура и разбираться сложно.

Игорь, я могу рассказать алгоритм тестирования канала  SPI (SPI_SEL5) связи с ПЛИСом, чтобы проверить версию аппаратной неисправности этого канала (если, конечно, Вы будете проверять такую версию).

Также могу рассказать, что нужно сделать, чтобы определить, по какой причине погасли индикаторы: был ли залётный ресет ПЛИСа или был начат цикл перезагрузки ПЛИС. Кстати, Вы JTAG используете?

Александр!

Еще одно наблюдение есть. Судя по всему, событие происходит, только если обмен с плиской по SPI происходит во время сбора данных. Быстро воспроизвести на стандартной прошивке можно так:

1. Загружаем прошивку из ltr_eu_8_16_fw.zip
2. Если крейт был в режиме Ethernet, переключаем в USB
3. Выкл/вкл
4. Запускаем ltrserver
5. Запускаем сбор данных (я запускал LGraph, 2 канала LTR11 @200kHz/канал)
6. Не останавливая сбор данных, выдергиваем кабель USB. Лампочка U становится желтой. Через 0 – 10 СЕКУНД обе лампочки тухнут.
7. Не подключая кабель USB нажимаем кнопку R на панели. Включается красная E и желтая U. Через 0 – 10 СЕКУНД обе лампочки тухнут.
8. Пункт 7 можно повторять, пока не надоест
9. Подключаем кабель USB.
10. Нажимаем кнопку R на панели. Лампочка U зеленая, E красная. Если не получилось, повторяем п.10.
11. Запускаем ltrserver. Все модули, кроме того, что гнал данные, обнаружены.
12. Ctrl-R — все модули обнаружены. Крейт в нормальном состоянии.

Если гипотеза верна, то без обмена с плиской по SPI во время работы я, конечно, обойдусь. Но разобраться надо, согласны? Я, например, из-за этой желтой лампочки уйму времени потратил в поисках несуществующих багов в своем коде.

Если что-то можно быстро проверить – напишите, попробую. В идеале хотелось бы, чтобы вы все-таки воспроизвели и побороли дефект у себя в LCard. Кстати, чем мой крейт от ваших отличается? По серийнику разобраться нельзя?

JTAGа нет.

"Если гипотеза верна..."
- Какая гипотеза?

"событие происходит, только если обмен с плиской по SPI происходит во время сбора данных"

Игорь, остаётся ждать пока на наших экземплярах крейтов мои коллеги-программисты целенаправленно протестируют случай частых  обращений к ПЛИСу по SPI на фоне сбора данных. Без JTAGa Вам смотреть что-либо на низком уровне будет затруднительно. С аппаратной точки зрения Ваш экземпляр крейта не отличается от нашего с точностью до естественных разбросов характеристик элементов и с точностью до потенциально возможных специфических неисправностей. В случае, если мы не обнаружим проблем в наших экземплярах крейтов, останется только привезти к нам Ваш крейт... Вы далеко от Москвы?

Не столько далеко, сколько за границей - в Запорожье. Ниже некий summary в стиле официального обращения в техподдержку.

Изделие: LTR-EU-8 S/N 2D228300

Прошивка: ltr_eu_8_16_fw.zip с сайта LCard FirmwareVersion = 1.0.0.1 FpgaName = LTR-030 FpgaVersion = 1.0.7.0 FpgaComment = Прошивка ПЛИС EP1C8 контроллера крейта LTR-EU-8(16). L-CARD

Дефект: самопроизвольный останов сбора данных с зависанием

Дополнительные признаки: 1) проявляется с вероятностью 100% при подключении по Ethernet через 0 – 50 минут после начала сбора данных; 2) не проявляется при подключении по USB; 3) в момент самопроизвольного останова потока данных гаснут светодиоды на передней панели; 4) после самопроизвольного останова потока данных крейт пингуется, но обнаруживается ltrserver как пустой (без модулей).

Результаты экспериментов с модифицированной прошивкой.

1) При добавлении строки g_mode_ULED = e_LED_Orange в основной цикл функции main.c:main_task дефект проявляется при подключении по USB через 0 – 10 СЕКУНД после начала сбора данных с вероятностью 100%. После сброса крейта кнопкой R нормальная работа НЕ восстанавливается вплоть до отключения питания.

2) После удаления из функции main.c:main_task фрагмента кода if (g_mode_ULED == e_LED_Orange)…, отвечающего за управление светодиодами, дефект не воспроизводится.

Гипотеза: Дефект проявляется только при обращении к регистрам ПЛИС по SPI во время сбора данных. Крейтом можно пользоваться, если модифицировать прошивку как указано выше, однако в случае закрытия соединения с крейтом без остановки сбора данных вероятно появление дефекта при повторном подключении.

Игорь,
мы обнаружили эффект сбоев SPI на наших крейтах LTR-EU-8/16 (Board_Revision = 1), выпускаемых с начала 2010 года. В более ранних крейтах (Board_Revision = 0) такой эффект не обнаружен. Эффект внешне проявляется при работе по Ethernet (при отключенном USB-кабеле) в виде подмигивания светодиодов E и U на панели. Проблема лечится добавлением согласующей RC-цепи на линию PF13 (SPI_SCK), эта цепь поглощает отражённую волну и улучшает форму SPI-клока. К сожалению, программного способа решения проблемы нет. Доработку будем делать в наших производственных условиях L-Card. Позже сообщу подробности.

Игорь, чтобы Вам через границу не везти, попробую в ПЛИСе сделать комплекс защитных мер, которые резко уменьшат вероятность таких сбоев. Но на сколько уменьшат - это будет предметом испытаний Вашего экземпляра крейта... У Вас режим работы системы какой, 24 ч в сутки непрерывно? Система обслуживаемая?

Александр! Подмигивание я тоже замечал, но не придал значения. Система предназначена для автоматизации виброиспытаний. Иногда требуется непрерывно отрабатывать смену - 8 часов. В принципе, в случае самоостанова возобновить работу можно, но пользователи будут нервничать . Для уменьшения вероятности сбоя в прошивке DSP непрерывное мигание лампочками я отключил. Когда подправите прошивку плиски - напишите, погоняю. Частота SPI невысокая, так что, полагаю, цифровой фильтр в плиске будет не хуже RC-цепочки.

Игорь, я выслал Вам на e-mail прошивку 1.0.9  для LTR-EU-8/16. Пожалуйста, долговременно испытайте её совместно со штатным ПО Blackfin от L-Card и сообщите результат. На моём крейте на текущий момент на 100% проблема решилась.

Игорю.
Большое спасибо за проявленное терпение и понимание. Благодаря Вам удалось найти и устранить  дефект в новой модификации крейтов LTR-EU-8/16. Подробнее см. http://www.lcard.ru/forumthreads/9991