Перейти к содержанию
    

Шаманъ

Участник
  • Постов

    836
  • Зарегистрирован

  • Посещение

Весь контент Шаманъ


  1. Вот! Огромное спасибо за правильную мысль :) Похоже я решил проблему. Вчера проверить не было времени, но не давала покоя одна мысль - при активном резете МК потреблял меньше, чем при неактивном - т.е. он что-то выполнял, и, соответственно, Ваша мысль была очень вероятным кандидатом на реальную картину. А подходящее место в программе было только одно. Так оно по всему и получилось. Вход в основную программу из загрузчика осуществлялся через сброс МК. Добавил контроль при входе, чтобы сброс был именно программный и все стало работать стабильно (по крайней мере как не старался завесить не смог, со старым загрузчиком, который без этой проверки, вешается достаточно просто через помехи в питании). Остался правда один вопрос - как мог происходить в этом месте сбой для меня по прежнему загадка (ибо та проверка предназначена для выявления повреждения или отсутствия основной программы, а она присутствовала в нормальном виде всегда). Не знаю актуально ли, но как-то так (сброс не подключал):
  2. Конечно, но попозже, сейчас убегаю... Да, вот еще, в состоянии зависания МК потребляет около 4мА (может немного меньше - полностью отключить физически все остальное на плате не могу). При замыкании сброса на землю потребление уменьшается до 2.2мА, когда сброс отпускаю опять те же 4мА, и ничего не перезапускается. Согласен. Но я вот не могу придумать как программно завесить МК, чтобы он не реагировал на сброс? Ну и судя по состоянию ног до основной программы дело при сбое не доходит - т.е. код инициализации GPIO не исполняется.
  3. От USB как раз все нормально работает. Впрочем если питание нормально включать тоже нормально работает, а если вот как-то так (голубая линия 5В, желтая питание МК 3.3В, розовая сброс): То проблемы и возникают...
  4. Естественно смотрел. Там кроме всего этого еще есть и ограничения на скорость спада напряжения питания ;). При контроле осциллографом в рамки укладываюсь с большим запасом. Из результатов экспериментов - 1000мкФ в питании МК решает проблему, он же в питании до LDO который питает МК не решает проблему. Осциллографом вижу, что проблема возникает когда питание падает почти до 2В, но супервизор по питанию в этот момент не дает сброс. Что в общем-то не должно представлять проблемы для функционирования МК.
  5. Конденсатор 0.1мкФ на землю и все. В непосредственной близости от МК (пара мм), 0603. На ней висит резистор 10К на землю. Нога не используется. Насчет внешнего WD правильно заметили - раз на сброс не реагирует, то чем поможет WD? Есть конечно вероятность, что если держать контроллер в сброшенном состоянии, то переходные процессы по питанию пройдут для него без последствий, но как по мне это лечение последствий, а не проблемы.
  6. Приветствую всех! Есть девайс на STM32F042. У него два варианта питания - от УСБ порта и автономное. Так вот если при подключении автономного питания в момент подключения контакт был не стабильный, то контроллер завешивается намертво. Проблема явно не программная, т.к. включение IWDG не помогает, более того в подвешенном состоянии он даже на сброс не реагирует, но если передернуть питание, то все начинает работать. Кто-нибудь сталкивался с таким поведением? В остальном все работает нормально (в том числе и старт при питании от УСБ порта). Да, схема контроллерной части в общем то простейшая - используется внутренний ОГ, питание от персонального стаба на LP5907-3.3, блокировочные емкости в питании присутствуют как положено, БП в порядке (аналогичное поведение можно спровоцировать с разными БП). Спасибо!
  7. Для SDRAM при разумной разводке в этом нет нужды. Можно обойтись без них, но в этом случае писать в память Вы сможете только 32битными словами.
  8. STM MP1

    А разве один на двоих может быть? Ага референс мануал появился...
  9. STM MP1

    Я правильно понял с доками совсем туго ни MP1 или пока, или вообще?..
  10. Конечно есть около 55МГц срез, тактовая ЦАПа 155МГц Не получится - отключение ЦАПа я не делал, а городить колхоз подпаиваясь проводками к LFCSP корпусу нет желания. Да и анализатор спектра не у меня, поэтому что-либо промерять на нем это целое дело... А что собственно хотелось узреть? Тактовую фильтр задавит достаточно сильно (около 70дБ), так что разглядеть что-либо полезное наверное и не вышло бы.
  11. Сегодня была возможность посмотреть выход ЦАПа на анализаторе спектра Rigol DSA815.
  12. Сам очень удивлен - это Siglent SDS1104X-E, который я "улучшил" до SDS1204X-E :), ну и заодно все опции открыл, правда там особо полезного опционального почти ничего и нет. Как по мне, он для своих денег очень неплох и он умеет 1M точек БПФ делать (на картинках оно и есть + усреднение по 16 замерам).
  13. Картинки с осциллографа, я вообще удивлен, что он (осциллограф) смог такое выдать (ИМД скорее всего тоже осциллографа). На нормальном анализаторе спектра должно выглядеть намного приличнее.
  14. Изначально стоял 3.3V LVCMOS там совсем печально было, да и ток можно поставить только 2мА, потом 3.3V LVTTL (макс. 8мА), сейчас 3.0V LVTTL ток стоит 12 или 16мА. Ради эксперимента посмотрел 3.0V LVTTL vs. 3.3V LVTTL при одинаковом токе драйвера 8мА - разница по tsetup около 300пс, по thold практически нет. Т.е. основное влияние оказывает именно более мощный драйвер. У меня такое записано: set_global_assignment -name OUTPUT_IO_TIMING_NEAR_END_VMEAS "HALF VCCIO" -rise set_global_assignment -name OUTPUT_IO_TIMING_NEAR_END_VMEAS "HALF VCCIO" -fall set_global_assignment -name OUTPUT_IO_TIMING_FAR_END_VMEAS "HALF SIGNAL SWING" -rise set_global_assignment -name OUTPUT_IO_TIMING_FAR_END_VMEAS "HALF SIGNAL SWING" -fall Т.е. должно анализироваться одинаково.
  15. Не, ЦАП таким сигналом в моем применении нельзя тактировать - клок из ПЛИС будет грязный сильно, а если его пересинхронизировать, то затея потеряет смысл. Залил новый вариант в плату, работает нормально (прошлый правда с нарушенными таймингами работал тоже). Так 3.3В интерфейсы имеют по току ограничение, 3.0В интерфейсы позволяют бОльший ток получить (что в общем-то логично). Я так и хотел вначале, но к моему стыду как это сделать правильно не понял, правда и не сильно усердствовал.
  16. Интересная идея, но я пошел немного иным путем. 1. Выбрал более мощный выход 3.0V LVTTL (здесь возникает вопрос, насколько это работоспособное решение? Ибо питание 3.3В, что как бы не по стандарту) 2. Установив разные задержки (см выше) подровнял два бита (4й и 12й) 3. Установив разный ток драйверов подровнял остаток 4. Сдвинул клок от PLL на -0.2нс, чтобы окончательно вписаться. Тут есть вопрос - правильно ли в таком случае изменить констрейты на: #Было так #set_output_delay -clock V_M_CLK -max 2.0 [get_ports {DAC[*]}] #set_output_delay -clock V_M_CLK -min -1.5 [get_ports {DAC[*]}] #Сдвинул на один период тактового сигнала (-6.43нс), иначе как я понял анализ делается не по тому фронту set_output_delay -clock V_M_CLK -max -4.43 [get_ports {DAC[*]}] set_output_delay -clock V_M_CLK -min -7.93 [get_ports {DAC[*]}] Итог: +-------------------------------------------------------------------------------------------------------------------+ ; Multicorner Timing Analysis Summary ; +-------------------------------------------------------+--------+-------+----------+---------+---------------------+ ; Clock ; Setup ; Hold ; Recovery ; Removal ; Minimum Pulse Width ; +-------------------------------------------------------+--------+-------+----------+---------+---------------------+ ; Worst-case Slack ; 0.131 ; 0.020 ; N/A ; N/A ; 1.430 ; ; V_M_CLK ; 0.131 ; 0.020 ; N/A ; N/A ; N/A ; +-------------------------------------------------------+--------+-------+----------+---------+---------------------+ Собственно единственный "скользкий" момент это первый пункт.
  17. С задержкой в 400пс внутреннего клока (который от PLL генерируется) и переназначенными пинами получается удовлетворить тайминги по всем трем моделям с некоторым запасом. ОК Значит позанимаюсь этим вопросом еще (некоторые мысли есть). В принципе работает и так (по крайней мере на этой плате в нормальных условиях, но хочется сделать хорошо). Еще раз всем спасибо!
  18. То все, как и ожидалось, становится более-менее ровненько (это самый плохой вариант): +-----------------------------------------------------------------------------------------------------------------------------------------------+ ; Slow 1200mV 85C Model Setup: 'V_M_CLK' ; +--------+--------------+---------+------------------------------------------------------+-------------+--------------+------------+------------+ ; Slack ; From Node ; To Node ; Launch Clock ; Latch Clock ; Relationship ; Clock Skew ; Data Delay ; +--------+--------------+---------+------------------------------------------------------+-------------+--------------+------------+------------+ ; -0.348 ; DAC[5]~reg0 ; DAC[5] ; PLL_inst|altpll_component|auto_generated|pll1|clk[0] ; V_M_CLK ; 6.430 ; -0.429 ; 4.259 ; ; -0.347 ; DAC[2]~reg0 ; DAC[2] ; PLL_inst|altpll_component|auto_generated|pll1|clk[0] ; V_M_CLK ; 6.430 ; -0.428 ; 4.259 ; ; -0.336 ; DAC[1]~reg0 ; DAC[1] ; PLL_inst|altpll_component|auto_generated|pll1|clk[0] ; V_M_CLK ; 6.430 ; -0.417 ; 4.259 ; ; -0.188 ; DAC[3]~reg0 ; DAC[3] ; PLL_inst|altpll_component|auto_generated|pll1|clk[0] ; V_M_CLK ; 6.430 ; -0.428 ; 4.100 ; ; -0.180 ; DAC[6]~reg0 ; DAC[6] ; PLL_inst|altpll_component|auto_generated|pll1|clk[0] ; V_M_CLK ; 6.430 ; -0.460 ; 4.060 ; ; -0.179 ; DAC[11]~reg0 ; DAC[11] ; PLL_inst|altpll_component|auto_generated|pll1|clk[0] ; V_M_CLK ; 6.430 ; -0.459 ; 4.060 ; ; -0.179 ; DAC[10]~reg0 ; DAC[10] ; PLL_inst|altpll_component|auto_generated|pll1|clk[0] ; V_M_CLK ; 6.430 ; -0.459 ; 4.060 ; ; -0.179 ; DAC[9]~reg0 ; DAC[9] ; PLL_inst|altpll_component|auto_generated|pll1|clk[0] ; V_M_CLK ; 6.430 ; -0.459 ; 4.060 ; ; -0.179 ; DAC[8]~reg0 ; DAC[8] ; PLL_inst|altpll_component|auto_generated|pll1|clk[0] ; V_M_CLK ; 6.430 ; -0.459 ; 4.060 ; ; -0.179 ; DAC[7]~reg0 ; DAC[7] ; PLL_inst|altpll_component|auto_generated|pll1|clk[0] ; V_M_CLK ; 6.430 ; -0.459 ; 4.060 ; ; -0.178 ; DAC[4]~reg0 ; DAC[4] ; PLL_inst|altpll_component|auto_generated|pll1|clk[0] ; V_M_CLK ; 6.430 ; -0.458 ; 4.060 ; ; -0.177 ; DAC[0]~reg0 ; DAC[0] ; PLL_inst|altpll_component|auto_generated|pll1|clk[0] ; V_M_CLK ; 6.430 ; -0.417 ; 4.100 ; ; -0.176 ; DAC[13]~reg0 ; DAC[13] ; PLL_inst|altpll_component|auto_generated|pll1|clk[0] ; V_M_CLK ; 6.430 ; -0.456 ; 4.060 ; ; -0.175 ; DAC[12]~reg0 ; DAC[12] ; PLL_inst|altpll_component|auto_generated|pll1|clk[0] ; V_M_CLK ; 6.430 ; -0.455 ; 4.060 ; +--------+--------------+---------+------------------------------------------------------+-------------+--------------+------------+------------+ Интересно софтовое решение возможно в принципе? А может и просто забить до следующей итерации платы :) - ничего ответственного сей девайс не делает.
  19. От блин. Просмотрел я этот момент. Емкость реально намного выше - см. Таблицу 1-11 на стр. 10 здесь https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/cyclone-iv/cyiv-53001.pdf У обычного пина 6..8пФ, у этих 21..23пФ. AD9744 имеет входную емкость 5пФ, пусть на плате еще 1..2пФ получается 12..14пФ vs. 27..29пФ. Наверное нужно в квартусе прописать емкость внешней нагрузки (если это можно конечно), ну и, наверное, подумать как добавить еще задержки другим пинам, а в следующей ревизии переставить пины. Спасибо всем за обсуждение!
  20. Я тоже так думал, но квартус думает иначе Проверял: +-------------------------------------------------------------------------------------------------------------------------------------------------- ; Output Pins +----------+-------+----------+--------------+--------------+--------------+-----------------+------------------------+---------------+-----------+ ; Name ; Pin # ; I/O Bank ; X coordinate ; Y coordinate ; Z coordinate ; Output Register ; Output Enable Register ; Power Up High ; Slew Rate ; +----------+-------+----------+--------------+--------------+--------------+-----------------+------------------------+---------------+-----------+ ; DAC[0] ; 100 ; 6 ; 53 ; 21 ; 21 ; yes ; no ; no ; 2 ; ; DAC[10] ; 114 ; 7 ; 45 ; 34 ; 7 ; yes ; no ; no ; 2 ; ; DAC[11] ; 115 ; 7 ; 45 ; 34 ; 14 ; yes ; no ; no ; 2 ; ; DAC[12] ; 119 ; 7 ; 38 ; 34 ; 0 ; yes ; no ; no ; 2 ; ; DAC[13] ; 120 ; 7 ; 38 ; 34 ; 14 ; yes ; no ; no ; 2 ; ; DAC[1] ; 101 ; 6 ; 53 ; 21 ; 14 ; yes ; no ; no ; 2 ; ; DAC[2] ; 103 ; 6 ; 53 ; 22 ; 7 ; yes ; no ; no ; 2 ; ; DAC[3] ; 104 ; 6 ; 53 ; 22 ; 0 ; yes ; no ; no ; 2 ; ; DAC[4] ; 105 ; 6 ; 53 ; 24 ; 21 ; yes ; no ; no ; 2 ; ; DAC[5] ; 106 ; 6 ; 53 ; 30 ; 7 ; yes ; no ; no ; 2 ; ; DAC[6] ; 110 ; 7 ; 51 ; 34 ; 21 ; yes ; no ; no ; 2 ; ; DAC[7] ; 111 ; 7 ; 49 ; 34 ; 7 ; yes ; no ; no ; 2 ; ; DAC[8] ; 112 ; 7 ; 47 ; 34 ; 21 ; yes ; no ; no ; 2 ; ; DAC[9] ; 113 ; 7 ; 45 ; 34 ; 0 ; yes ; no ; no ; 2 ; +----------+-------+----------+--------------+--------------+--------------+-----------------+------------------------+---------------+-----------+ Из совпадений (подозрительных) у обоих пинов специальная функция VREFB7NO/VREFB6NO возможно что-то на них висит дополнительное, что добавляет емкости/задержки (правда почти на 2нс это многовато)
  21. Спасибо за ответы! Поставил еще вчера, не помогло :( Откуда задержка это понятно, вопрос был откуда такой разброс по линиям? Смотрите DAC[12] и DAC[4] на 2нс отличаются от остальных. Вчера покопался в этом деле, промежуточный итог: Завел M_CLK в PLL, появилась возможность минимизировать Clock Skew между внешним и внутренним клоком и "подвигать" тактовый сигнал внутри ПЛИС. С PLL Fast Model удовлетворила требованиям сразу, Slow Model нет. Собственно, если бы не было разброса такого по задержкам, то подвинув немного тактовый сигнал внутри ПЛИС можно было бы удовлетворить таймингам. Да, еще добавил: set_instance_assignment -name CLOCK_TO_OUTPUT_DELAY 1 -to DAC[13] на линии с меньшей задержкой, и set_instance_assignment -name CLOCK_TO_OUTPUT_DELAY 0 -to DAC[12] на линии с большей задержкой. Задержки выровнялись, но всеравно разбег приличный (в медленной модели 1.2нс). К сожалению Циклон 4 поддерживает только два значения задержки в выходных ячейках. Думал всегда, что эти задержки Квартус сам настраивает. Да, изменение выходного стандарта с 3.3V LVCMOS на 3.3V LVTTL тоже немного помогло. Если смотреть на Multicorner Analysis то получается я пролетаю по tsetup на 1.5нс и имею запас по thold в 0.25нс, т.е. если бы не два пина которые сильно выбиваются из общей картины, то можно было бы вписаться. Почему же они в одном банке так себя ведут???
  22. Приветствую всех! Возник вопрос. Имеется схема - генератор 155МГц раздает клок на Cyclone VI и AD9744, в этом циклоне сгенерированные данные выводятся на AD9744. Как-то так: always @(posedge M_CLK) begin DAC <= data; end DAC это линии которые идут на ЦАП: output reg signed [13:0] DAC Далее описаны в SDC файле констрейнты: #Internal clock create_clock -name M_CLK -period 155.52MHz [get_ports M_CLK] #External clock create_clock -name V_M_CLK -period 155.52MHz #DAC setup time (2ns) set_output_delay -clock V_M_CLK -max 2.0 [get_ports {DAC*}] #DAC hold time (1.5ns) set_output_delay -clock V_M_CLK -min -1.5 [get_ports {DAC*}] После компиляции получаю: +-------------------------------------------------------------------------------------------------------+ ; Slow 1200mV 85C Model Setup: 'V_M_CLK' ; +--------+--------------+---------+--------------+-------------+--------------+------------+------------+ ; Slack ; From Node ; To Node ; Launch Clock ; Latch Clock ; Relationship ; Clock Skew ; Data Delay ; +--------+--------------+---------+--------------+-------------+--------------+------------+------------+ ; -3.843 ; DAC[12]~reg0 ; DAC[12] ; M_CLK ; V_M_CLK ; 6.430 ; -2.846 ; 5.407 ; ; -3.790 ; DAC[4]~reg0 ; DAC[4] ; M_CLK ; V_M_CLK ; 6.430 ; -2.802 ; 5.398 ; ; -1.745 ; DAC[1]~reg0 ; DAC[1] ; M_CLK ; V_M_CLK ; 6.430 ; -2.820 ; 3.335 ; ; -1.744 ; DAC[5]~reg0 ; DAC[5] ; M_CLK ; V_M_CLK ; 6.430 ; -2.819 ; 3.335 ; ; -1.731 ; DAC[2]~reg0 ; DAC[2] ; M_CLK ; V_M_CLK ; 6.430 ; -2.806 ; 3.335 ; ; -1.620 ; DAC[6]~reg0 ; DAC[6] ; M_CLK ; V_M_CLK ; 6.430 ; -2.850 ; 3.180 ; ; -1.619 ; DAC[11]~reg0 ; DAC[11] ; M_CLK ; V_M_CLK ; 6.430 ; -2.849 ; 3.180 ; ; -1.619 ; DAC[10]~reg0 ; DAC[10] ; M_CLK ; V_M_CLK ; 6.430 ; -2.849 ; 3.180 ; ; -1.619 ; DAC[9]~reg0 ; DAC[9] ; M_CLK ; V_M_CLK ; 6.430 ; -2.849 ; 3.180 ; ; -1.619 ; DAC[8]~reg0 ; DAC[8] ; M_CLK ; V_M_CLK ; 6.430 ; -2.849 ; 3.180 ; ; -1.619 ; DAC[7]~reg0 ; DAC[7] ; M_CLK ; V_M_CLK ; 6.430 ; -2.849 ; 3.180 ; ; -1.616 ; DAC[13]~reg0 ; DAC[13] ; M_CLK ; V_M_CLK ; 6.430 ; -2.846 ; 3.180 ; ; -1.586 ; DAC[0]~reg0 ; DAC[0] ; M_CLK ; V_M_CLK ; 6.430 ; -2.820 ; 3.176 ; ; -1.572 ; DAC[3]~reg0 ; DAC[3] ; M_CLK ; V_M_CLK ; 6.430 ; -2.806 ; 3.176 ; +--------+--------------+---------+--------------+-------------+--------------+------------+------------+ Собственно вопросов два: 1. Откуда такой разброс Data Delay? 2. Как можно (и можно ли) добавить задержку в выходные сигналы, чтобы вписаться в требования? Еще не совсем понятен механизм задания констрейнтов - клоки M_CLK и V_M_CLK как я понимаю получаются синхронные, но ведь это не совсем так, ибо пока M_CLK от ноги ПЛИС дойдет до выходного регистра пройдет какое-то время, и M_CLK внутри ПЛИС (как раз который Launch Clock в отчете квартуса) уже не будет синхронным с V_M_CLK. Заранее спасибо!
  23. К сожалению я стаклкивался, и несколько раз. Пока не понял в чем дело это очень сильно затормозило работу. В итоге вернулся к прежним cpptools. Копаясь в коде обнаружил очень странное именование переменных в командах посылаемых gdb. Это в ряде случаев приводит к неправильному отображению значений элементов массивов. В итоге, как по мне, для проектов немного сложнее ""hello world" этот плагин может создать больше проблем, чем решить. Хотя задумка хорошая. Это несколько проблематично, т.к. у меня нет всего фреймворка (а устанавливать и настраивать нет времени), чтобы писать на TypeScript и потом компилировать в JavaScript и собирать плагин как положено, поэтому я прямо подредактировал выходной JavaScript (в принципе перенести изменения обратно в исходник на TypeScript не проблема). Т.е. мне нужно будет потратить определенное время, чтобы это сделать, которого у меня нет. Можно в принципе в обсуждении проекта на гитхабе сделать тему и выложить JavaScript файлы - пусть народ допиливает, но терзают меня сомнения, что кто-то будет это делать. Если бы не фундаментальные проблемы с именованием элементов массивов/струтур в командах отсылаемых gdb, то можно было бы пилить этот плагин и дальше, а так думаю перспективнее приложить усилия к cpptools.
  24. Я бы не сказал. Я копался в коде - куча ошибок там, MI интерфейс сделан криво, очень криво. Хотел довести до ума, поисправлял некоторые ошибки, сделал частично отображение в шестнадцатеричной, двоичной, восьмеричной системе, но забросил, ибо глюков там очень много и некоторые очень существенные (типа неправильного показа памяти/периферии). Нет, это к плагину.
  25. Контроллер у STM32 не поддерживает пакетную запись/чтение для которой важно правильное подключение младших линий адреса (он всегда выдает адрес столбца на каждую операцию, даже при последовательном чтении/записи), потому проблем с перемешиванием в том числе и младших линий адреса нет. Хотя делать это и нежелательно. Нужно отметить, что регистр MR пишется через адресные линии, соответственно при перемешивании нужно писать корректное значение с учетом этого. Главное перемешивать с пониманием вопроса, тогда и костылей не нужно. У меня есть плата где перемешано много всего, чтобы в двух слоях нормально работало, все отлично работает. Совершенно верно. Но схема Arleex рабочая, если не трогать А10. P.S. Безболезненно можно перемешивать: -линии выбора банка -линии данных в пределах одного байта -байты линий данных, но только вместе с сигналами выбора байта К линиям адреса (если это только не старшие линии) нужно подходить осторожно, вдумчиво читая датащит на SDRAM и контроллер памяти - тут возможны варианты.
×
×
  • Создать...