пятница, 20 августа 2021 г.

ADC12DJxx00 GUI Problem

 Всем привет!  

При работе с отладочной платой от TI была обнаружена проблема: в варианте платы ADC12DJ2700 в GUI по умолчанию происходит настройка PLL2 для чипа LMK04828 в режим использование redundant клока,  т.е.  VCO Mux = External VCO. При этом чип используется просто как делитель частоты в моем случае 2700 МГц в 10 раз, и 270 МГц подается в качестве референсного клока на MGT банки FPGA.  Это не является штатным режимом работы LMK04828, но все попытки запустить  в штатном режиме использования PLL2  не увенчались успехом. Для исследования проблемы я стал смотреть на поведение сигнала CPout2. Это выход фазового детектора. Он не реагировал на изменение счетчиков, и напряжение на нем появлялось только при ресете всего модуля из GUI. При этом другие вещи перестают работать, но при этом можно запустить фазовый детектор и убедиться, что он работает. 

Мне требуется сделать следующие настройки см. рис.1:

 Рис.1

 В вкладке PLL2:  R Divider = 10, NDivider =81, Prescaler = 3, VCO Mux = VCO 0.  Таким образом частота VCO0 будет 2430 МГц, при частоте опорного кварцевого генератора 100МГц. Частота сравнения 10МГц.  Тогда, для получения частоты дискретизации 2700МГц необходимо на FPGA MGT подать 270 МГц. Для этого в вкладке Clock Outputs (Рис.2): нужно выставить CLKout 0 and 1 DCLK Divider = 9, для удобства на выходе CLKout 10 and 11 DCLK Divider = 27,  тогда на J23 J24 отладки можно посмотреть поделенный в 27 раз генерируемый клок, он в моем случае должен быть 90 МГц. 

Рис.2

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

Решение: выяснено, что значение в регистре LMK04828 по адресу 0x173 становится 0x60(Рис.3) , т.е. это power down для фазового детектора. 

 Рис.3

Запишем туда 0, и проблема решена. Частота дискретизации 2700МГц генерируется из того же клока 100МГц чипом LMX2582. Тут дополнительные настройки не требуются. (Рис.4) 

Рис.4

 


воскресенье, 24 ноября 2019 г.

Автопилот на AT91SAM7: Образец для испытаний. Год 2019.


Итак, к сожалению в этом году не получилось испытать доработанный софт автопилота с новой платой для него. Однако, что сделано:
1) Изготовлены новые платы, датчик цифрового компаса HMC6352 заменен на LSM9DS0, поскольку все 4 датчика, присланные из Ижевска по 1200 р. оказались неисправными. Так же дописан софт для этого датчика. Кроме того, существует возможность отказаться от дорогостоящих датчиков ADXL213E(2500р) и возможно гироскопа MEV50(~1200р). Но это еще не проверено. Параметры гироскопа LSM9DS0 в 5 раз уступают параметрам MEV50.


2) Отлажено программное обеспечение для параллельного подключения к выходным разъемам приемника. Теперь на требуется выводить сигнал канальных импульсов из приемника, а также можно использовать пульты с синхронными импульсами..
3) Программа сделана под 2 варианта пультов - с последовательными канальными импульсами и синхронными. Управление стало более качественным и прозрачным. Т.е. если включен пульт, то управление одинаковое по чувствительности если включать серво напрямую к приемнику( без автопилота) или через автопилотные недра.  
4) Обновлен софт для подключения микро-SD большого (от 8 GB) объема. FAT32. Оказывается начиная c 4GB меняется алгоритм инициализации SD карт.
5) Собраны и испытываются 2 комплекта автопилотов на печатных платах, и один старый "наколенный" тоже готов к вылету. Там тоже новый алгоритм работы с пультом. Но SD карта старая, 16 МБ, FAT12. Котик помогает отлаживать.
6) На SD карте теперь содержится маршрутный файл отдельно и файл модели, где хранятся данные в т.ч. реверса серво, часового пояса, имя модели, настройки автопилота.
Автопилоты испытываются  и тестируются на макете Dusty c различными вариантами пультов с приемниками. Тип пульта также указывается в файле модели.

 
При отладке выявилась необходимость добавления одного диода Шоттки, для обеспечения режима стирания и перепрограммирования контроллера через USB интерфейс. А также перепутанность 2 контактов для подключения светодиодов.
 



Готовые и отлаженные платы могут быть высланы для желающих получить макеты полноценных автопилотов (не полетных контроллеров)  для написания своего софта или доработки существующего. Стоимость готового автопилота укомплектованного GPS датчиком, BT модулем и SD картой будет составлять около 32000 р. Дорого, да, но это не ширпотреб, а только стоимость комплектующих составляет около 15 тыс. р. 


К собранной и отлаженной плате будет прилагаться схема, рисунок PCB, инструкция по подключению,  исходники программного обеспечения(Bare Metal).  Подробное описание системы автопилота и результаты летных испытаний можно увидеть в этом блоге. 








пятница, 15 ноября 2019 г.

ZYNQ-7000 Soc: QSPI programming problem

Всем привет. При разработке новой платы с xc7z012s была установлена QSPI флеш память типа MX25R6435F (Jedec ID = 0xC2 0x28 0x17. Попытка запрограммировать эту память используя VIVADO (2018.2) или SDK оказалась неудачной. Изучение вопроса показало, что общение с памятью начинается и заканчивается на считывании из памяти JEDEC ID командой 0x9F. После этого Vivado выдает сообщение "[Xicom 50-186] Error while detecting SPI flash device - unrecognized JEDEC id bytes: c2, 28, 17".


При программровании через SDK происходит примерно тоже самое. Тут больше сообщений от софта в консоли отладчика. Еще больше информации можно получить вставив в переменные окружения XIL_CSE_ZYNQ_DISPLAY_UBOOT_MESSAGES и задав его равным 1. Поддерживаемые QSPI флешки можно найти тут. Иногда решение проблемы можно найти в pdf документе. Полезно вывести отладку через com-port. Для этого в файле D:\Projects\..\<project name>.sdk\fsbl\src\fsbl_debug.h добавить строчку #define FSBL_DEBUG_INFO.


Решить проблему удалось заменив 3 байта в файле  D:\Xilinx\Vivado\2018.2\data\xicom\cfgmem\uboot\zynq_qspi_x4_single.bin. При настройке hardware manager я выбрал ближайшую по параметрам флешку MX25U12835F с jedec ID = 0xС2 0x25 0x38.
Таким образом находим в бинарнике zynq_qspi_x4_single.bin фразу C2 25 38 и заменяем на С2 28 17. После этого флешка успешно программируется. Вот такой лог получен при загрузке уже с запрограммированной QSPI flash. Нужно отметить, что скорее всего при компиляции u-boot нужно также добавить такую флешку в header, как предлагается в документе.  
В заключение хочется отметить, что несмотря на кажущуюся простоту интерфейса QSPI к вопросу нужно подходить крайне серьезно. Разные устройства имеют разные наборы команд, поэтому лучше использовать при разработке компоненты, описанные Xilinx  как проверенные. Не все QSPI (и NAND)флешки можно заставить работать с ZYNQ, у Xilinx есть черный список.  


пятница, 7 июня 2019 г.

Zynq UltraScale+ : DDR4 : подключаем 16-битную шину и создаем загрузчик FSBL.

Продолжаем возиться с 16 битным режимом, до переразведенной платы далеко, а хочется Linux прямо сейчас:)
Что получилось  теперь:
1) Создал проект "fsbl" с стем же что и для проекта helloworld BSP ( это важно).
2) Далее требуется те же изменения, что в tcl файле внести в файл pcu_ini.c в папке  top_hw_platform_0. Это пример моего файла, тут мои изменения помечены  //max01...max013.
3) SDK проект FSBL должен быть скомпилирован в режиме release и при этом размещен в внутренней памяти процессора ("generate linker scrip"- правым мышом на проект sdk). 
4) Проект helloworld с моим тестом памяти тоже нужно перекомпилировать в режиме release. И запустив "generate linker scrip" разместить его в DDR. Пока не очень мне понятно, дело в том что у меня тестируется 1 GB и в наличие 1GB, поэтому общий объем DDR нужно уменьшить до 1 GB, но это я еще не пробовал делать пока. Сейчас софт думает что доступен 2GB.

В результате получил файл boot.bin. Плата грузиться с SD карты  и получил вот такой лог

при включении питания платы. DDR тестируется только в тех местах, где не лежат данные и код программы. Остальное по ссылке. Пока это на сегодня все.
 Сегодня 10.06.2019, обновил pcu_ini.c , поскольку нестабильно запускалось из-за недостаточного таймаута. Увеличил в 10 раз. Сейчас стартует на 5 секунде. Всегда успешно.
 

понедельник, 3 июня 2019 г.

Zynq UltraScale+ : DDR4 : подключаем 16-битную шину.

Это была вторая версия платы с XCZU3CG-2SFVC784 c 4 GBytes оперативной памяти DDR4 типа  MT40A512M16HA-083. Задача - разобраться почему снова нет DDR4.  Каждая микросхема  по 1GB. И DDR4 снова не заработала. В первой версии использовался мироринг адресов (Clamshell topology), 64 бита ширина шины и не использовался dual rank. Разработчик решил, что в этом и есть проблема, что используется только CS(0). Переделал плату на режим "DUAL RANK" задействовали CS(1). И снова неудача: 1) разработчик не разобрался что значит "DUAL RANK", - шины данных были раздельные, а не SHARED. 2) Как написано в майской версии документа ug583 PS memory controller не поддерживает mirroring без dual rank. Ну и конечно и в настройках wizard  так же галочку address mirrorimg можно поставить только когда выбран режим dual rank.

IMPORTANT: Clamshell is a supported DDR4 SDRAM topology in the MIG tool and is selectable for Programmable Logic banks only. The PS in the ZynqUltraScale+ MPSoC does not have a selectable clamshell configuration option. However, the PS can beconfigured as clamshell if set up as a dual-rank configuration with the first rank on the top layer, and the second rank mirrored on the bottom layer. When utilizing this topology within the Vivado tools, refer to the Clamshell Topology section in UltraScale Architecture-Based FPGAs Memory IP Product Guide (PG150) [Ref 13] for additional information.

Сделал вывод о переразводке без использования clamshel topology, т.е. без мироринга адресов. Ну и также не нужен режим dual rank, так как уменьшается в 2 раза скорость памяти из-за мультиплексирования шин данных  - ну т.е.  из-за уменьшения разрядности шины. Казалось бы на этом работа эксперта завершена. Да. Но только не для пытливого ума инженера. Ведь собранные платы можно было бы хотя бы как макетные платы использовать... если бы была доступна sdram. И вот теперь самое вкусное - вишенка на торте.

Все таки хотелось увидеть память, но из под дебагера невозможно запуститься, psu_init.tcl виснет... Причем, виснет даже при запуске из внутренней памяти(bare metal). Изучение кода и комментариев psu_init.tcl и UG1087, а также изучение отличий psu_ini.tcl для варианта 32 бита и 64 бита шины DDR4 позволило запустить только одну первую микросхему из 4. 1GByte стал доступен в 16-битовом режиме (QBUS) или QUARTER BUS.

 Итак, я не просто выложу файл с патчем,  я покажу как это сделать. Сначала скомпилим bit- файл с натройками ddr4 памяти как показано на рисунке.

 
 Сделаем экспорт hardware в SDK, пересоберем BSP и получим исходный файл psu_ini.tcl. Кроме того, мне пришлось собрать еще и версию для 64 битного режима, чтобы понять как происходит и настраивается маппирование. Первое что было обнаружено, что в файле psu_ini.tcl есть настройки для 16-битного режима, поэтому появилась надежда что можно это использовать. Меняем содержимое регистра  mask_write 0XFD070000
с значения 0x81041010 -> 0x81042010, и отключаем (комментируем) ожидание поллинга регистра 0xFD080030:
 #poll 0xFD080030 0x0000000F 0x0000000F
в строке 15330, 15333, 15393, 15406.

После таких манипуляций произошло чудо. При загрузке из внутренней памяти (В SDK встаем правым мышом на проект и выбираем generate linker script, тут настраиваем где лежит код и данные)  программа запускается, кроме того, появилась возможность тестировать DDR4 SDRAM.  Тетстирование показало, что ошибки в адресном тесте, причем если тестировать по маленьким кусочкам (0х1000 байт) то ошибок нет, а вот если записать всю память, или значительный ее кусок, а потом проверять , то встречаются записи "не туда". Сдвиг составляет 0x400 слов. Стало поняно, что нужно изменить маппирование адресов.

Для того чтобы осознать как это сделать и понять комментарии  я сделал файл для 32 битной шины и для 64 битной. После этого посчитал маппирование для этих двух вариантов, а потом придумал третий - для 16 битного режима.

Картинка получилась такая:
Нужно заметить, что важное значение имеет поледовательность стыковки BANK-ROW-COLUMN.  В TCL коде для ROW и BANK нет зависимости от шины, в то время как для COLUMN - есть. Это нужно учитывать при рассчете адресов. В результате удается, пока в дебаговом режиме загружать программку тестирования в ddr4, в доступный 1 GByte, и программка сама находясь в DDR4 тестирует DDR4, те места где нет кода программы и данных программы.


суббота, 10 ноября 2018 г.

Автопилот на AT91SAM7: Продолжение летных испытаний. Год 2018.


10.      Продолжение летных испытаний. Год 2018.



10.1     13.10.2018


                После длительного перерыва новое испытание. При изучении всех предыдущих полетов был сделан вывод, что волнообразное изменение скорости полета и высоты, нестабильность удержания этих параметров связана с неучтенным фактором. Это ускорение и замедление самолета, и влияние этого параметра на удержание тангажа. Действительно, легко посчитать, что при разгоне самолета по полосе он набирает скорость 50 км/ч за 3 сек, что соответствует ускорению до 0.5G, а это значит, что это должно быть учтено.  Наименьшее влияние этого было видно на рис. 27. Но и там, высота самолетом набиралась “ступеньками”. Когда начинается набор высоты, скорость падает, при этом у автопилота появляются ложные данные, что как будто самолет опускает нос, и он пытается это скомпенсировать, и еще больше набирает высоту, и снова теряет скорость.  Когда наконец скорость стабилизируется, самолет начинает выравниваться по тангажу, и при этом скорость растет, поскольку нет набора высоты. И тогда появляется составляющая обманывающая автопилот, как будто самолет летит с положительным большим тангажом, и автопилот это компенсирует, таким образом препятствую набору высоты, и, таким образом, это приводит к еще большему ускорению. Так возникает положительная обратная связь, которая и погубила самолет в прошлом испытании. Для начала была выставлена компенсация половина от точной расчетной. Ускорение для компенсации вычисляется по воздушной скорости, т.к. скорость по GPS отстает на 3 секунды, что делает ее применение для этого бессмысленным. Так же была уменьшена скорость крейсерского полета до 45 км/ч. При большой воздушной скорости у данной модели самолета возникает чрезмерная подъёмная сила, препятствующая нормальному удержанию высоты.  Сам полет можно посмотреть в видеозаписи. Вовремя полета казалось, что все идет правильно. Однако реально требование работы двигателя было только первые 5 секунд полета. За это время из-за слишком близкого расположения маршрутных точек автопилот выполнил программу полета и выключил мотор. Из-за особенностей регулировки оборотов мотор выключался в течение 1.5 минут, поэтому создалось впечатление успешного пролета маршрута.  Это видно на графике.
  
Рис. 35
Как видно, испытание проходило при значительном боковом ветре, около 30-40 км/ч. Был сделан вывод о чрезмерной компенсации (дерганный взлет), и уменьшении времени управления мотором. А также уменьшении скорости полета до 40 км/ч в полетном задании.

10.2     14.10.2018


По сравнению с предыдущим полетом, компенсация ускорения уменьшена до ¼ от расчетного значения. Уменьшена постоянная времени управления мотором с 90 до 18 сек. (в параметрах на карте памяти) Уменьшена скорость полета в задании до 40 км/ч. Кроме того, найден неисправный компонент диод Шоттки, который приводил к неожиданному поведению измерителя скорости и показанию скорости около 70 км/ч не зависимо от реальности. Это видно в конце графика рис. 35. В этот день также был сильный (до 15 м/с) слегка боковой ветер. Примерно 240 град. Взлетный курс 205. Поэтому долго не удавалось взлететь автоматически. Тогда самолет был поднят в воздух вручную с пульта. Это видно на видеозаписи полета. Посадка получилась в поле, из-за сильного бокового ветра.

 Рис. 36
Включение автопилота в полете и ручной взлет был проверен впервые. Такой режим планировался исходя из назначения автопилота - если он применяется для спасения самолета если оператор устал, и не хочет или не может управлять самолетом.  Все графики полета можно увидеть на Yandex-диске. Кроме того, в этот же день было проведено испытание самолета при старте с руки, при этом было снято шасси с самолета. Видеозапись полета доступна по ссылке. Это был самый показательный полет, поскольку видно по графикам рис.37 как отрабатывал регулятор воздушной скорости и скорость довольно точно удерживалась на уровне 40 км/ч. При этом так же неплохо удерживалась высота полета около 30 М. Немного высок получился коэффициент усиления по крену при полете с максимальной физической скоростью при полете по направлению ветра. Это привело к возбуждению петли ОС и самолетик махал крыльями. Посадка также выполнена планированием с выключенным мотором. Все прошло штатно. Графики полета можно увидеть на Yandex-диске и на рис.37.

Рис. 37
В результате удалось прекратить колебания скорости и высоты, которые были заметны во всех прошлогодних испытаниях. Последнюю версию GPILOT можно найти по ссыке.

воскресенье, 22 июля 2018 г.

Автопилот на AT91SAM7: 8. Измерение тяги и центровка



8.         Измерение тяги и центровка      

                 Итак, меняем мотор на безщеточный. На рис. 31 это уже именно он. Но теперь, когда встала необходимость заменить мотор настал момент обсудить и поделиться ноу-хау расчета центровки и ее изменения при оборудовании самолета. В папке главы можно найти картинки как выполнялось взвешивание. Вес исходного самолета оказался 750 г,(по документации 650 г) вес самолета с автопилотом  840 г., вес самого автопилота  160г. Еще интересно знать тяговооруженность самолета. Тяга мотора EMAX 2812 в зависимости от типа винта представлена на рис.33.

 Рис.33

При замене мотора решил разобраться как считать центровку. На рис.34 представлена схема самолета.

 Рис. 34

Предположим, что исходно самолет правильно центрирован, и имеет Cсах = 25%, тогда при добавлении груза массой G на расстоянии l от центра крыла(сах) получим новое значение центровки Сnew, %.
Cnew = G*x*100/(G+G0)*Bcax, где:
G            -вес нового груза, г
G0          -исходная вес самолета, г
Bcax, см - длина средней аэродинамической хорды;
x = l - S = l - ( (50-C0) / 100 ) * Bcax, где
l, см - расстояние нового груза от центра крыла(сах);
S, см - расстояние от центра крыла до центра тяжести;
C0,%  - исходная центровка;
S - расстояние от центра крыла до центра тяжести;  
Для расчета центровки относительно средней аэродинамической хорды(САХ) удобно старым добрым программируемым калькулятором, виртуальным программируемым калькулятором сегодня.  Программа выглядит так:
x→П3; ↔; В↑; 50; П0→x; - ;П2→x; x; 100;  ∕ ; -; П3→x; x; П2→x;  ∕ ; 100; x;  П1→x; П3→x; +; x→П1;  ∕ ; П0→x; ↔; - ; x→П0; C/П;БП00;
Для проверки номера команд:
43,14,0E,05,00,60,11,62,12,01,00,00,13,11,63,12,62,13,01,00,00,12,61,63,10,41,13,60,14,11,40,50,51, 00.

Перед запуском следует ввести:
X→П0 - Сcax исходное, %
X→П1 - исходный вес, г
X→П2 - Bcax, см
Запуск: В/О, l , В↑, G, C/П. После вычислений получаем на экране и в П0 новое значение центровки. В регистре П1 - новое значение веса самолета.
Формула работает рекурсивно, если блок добавляется, то масса вводиться с плюсом, если снимается - с минусом.  Расстояние вперед также вводиться с +, назад - с минусом. В таблице можно посмотреть, как изменялась центровка Дракончика и что можно ожидать после замены мотора на беcколлекторный. 

 Табл. 1
Чтобы не издеваться над непосвященными в таинство тпрограммируемых калькуляторов, предлагаю еще ссылку на форму exel для расчета центровки.  И вот еще тестовый apk для расчета центровки на андроид смартфоне.

9 .        Заключение

          В статье выдвинута концепция построения автопилота для радиоуправляемого беспилотного самолета на базе дешевого контроллера и современных инерциальных датчиков положения. Концепция проверена на модели виртуальной с использованием симулятора X-Plane-6 и на реальной модели на базе модели Wing Dragon Sportster с размахом крыла 118 см и весом 840 г, с толкающим винтом и электрическим мотором. Предложен вариант алгоритма полета по маршруту. Проведены испытания, построены графики и обсуждены полученные полетные данные.



- Санкт-Петербург, 2018 -