amiller

Я бы не рассчитывал на чудеса с самопроизвольной установкой бит по помехам. А поискал бы в документации особенности данного переключения частоты. Чисто теоретически могу предполагать, что если изменение тактирования происходит в середине приема байта, то не исключено появление ошибок. Если это так, то нужна или взаимная синхронизация процессов или корректная отработка ошибочных состояний.

Я давно-давно (ещё до ARM-ов) начал использовать такой способ. Размещаю основную структуру константных данных (элементы инициализации, диапазоны изменения, строковые описатели) в ассемблерном файле. Мне тоже понадобилось делать подсчёт разных элементов внутри структуры. Так вот, в ассемблере это достаточно легко, примерно так: PAR_COUNT SET 0 ; Номер параметра ... PAR_COUNT SET PAR_COUNT + 1 ; Следующий параметр ... PAR_COUNT SET PAR_COUNT + 1 ; Следующий параметр ... В любой момент значением этого счётчика можно с помощью компилятора инициализировать константу, а потом использовать где угодно. device: DC8 A_LEN, 32 DC16 PAR_COUNT

Смотрите, что конкретно делают эти функции и как это соотносится с теорией. dual and triple mode целесообразно рассматривать только с внешней синхронизацией на достаточно высокой частоте, например от таймера. Иначе вообще зачем использовать этот режим? Поэтому запуск преобразования должен происходить не по команде, а автоматически. А для этого нужны соответствующие настройки.

В документе RM0090 на странице 429 (описание общих регистров АЦП) есть фраза: Note: In multi mode, a change of channel configuration generates an abort that can cause a loss of synchronization. It is recommended to disable the multi ADC mode before any configuration change. На мой взгляд это однозначно говорит о том, что прежде чем включать любой мульти-режим, нужно сначала настроить отдельные АЦП. И не важно master или slave. Я эти режимы использовал, поэтому могу подтвердить, что при включении АЦП нужно действовать именно так, а при отключении в обратном порядке. А документы, что Вы приводите в качестве примера ("HAL_drivers_STM32F4"), вряд ли могут относится к документации на МК. Ведь эти прослойки между пользователем и МК пишутся в первую очередь для неспециалистов. А такие люди не используют специфичные режимы, как dual или triple mode. И есть очень большая вероятность, что в HAL такие режимы не тестировались на достаточном уровне. Шаг вправо или влево от рекомендованных примеров, и у Вас уже ничего не работает. Рано или поздно придётся читать первоисточники. Лучше раньше, меньше времени потратите бесцельно.

Предлагаю не путать теплое с мягким. UART, таймеры с DMA, или GPIO - это реализация интерфейса на физическом уровне. А "иметь картину по нескольким точкам сразу" - это относится уже к логическому уровню протокола обмена. И одно другому никак не мешает.

Если честно, я не понимаю, как можно накосячить в процессе прошивки. Интерфейсная программа в совокупности с загрузчиком не допустит записи несоответствующей прошивки. В сомнительных случаях задаст дополнительные вопросы. Мне кажется как раз в случае ответственных применений предприятие не допустит ситуацию, когда какой то девайс сам обновляется. Я не говорю о выборе времени, а о возможности в принципе что-то удаленно менять. А вдруг разработчика обидели и он превратил в кирпичи устройства по всей стране? Это нельзя исключать, если такая возможность имеется. Новая версия ПО должна поступать по официальному каналу связи от предприятия к предприятию. А при обновлении не помешает акт с парой подписей. Телевизоры можно и по вайфаю обновлять, а когда речь о жизнях людей, то извините. Поэтому про боинг что-то не очень верится. Если только они не положили на аборигенов большой болт.

Не совсем понятно, с кем Вы сейчас общаетесь. Если со мной, то: 1. Я нигде не утверждал, что предложенный мною подход, единственно верный. 2. Просто предложил свой способ, как один из многих. 3. Более того, в разных проектах раньше я использовал разные способы обновления ПО, в том числе и централизованные. 4. По моему мнению, если процесс обновления ПО организован грамотно, то он никак не влияет на степень надежности ПО для устройства, как и на его другие характеристики. 5. Но для ответственных применений решение о том, как и когда обновлять ПО, должна принимать сервисная служба клиента с соответствующими полномочиями, а не сервер за 1000 км. И процесс должен быть документально оформлен, а оборудование должно быть протестировано. Так что насчёт оборудования "без большой ответственности" Вы попали с точностью до наоборот. Ну и ещё один аргумент против централизованной системы обновления ПО. Интернет всё ещё есть далеко не везде. Например много оборудования стоит на предприятиях, где внешний интернет запрещен или сильно ограничен.

Даже Microsoft до последнего времени оставляла клиентам возможность выбора, обновляться или нет. В десятке обновления отключить сложнее, но можно. А кто я такой, чтобы навязывать обновление своих устройств? Версии с критическими ошибками во внешний мир не уходят. А исправление мелочей и добавление функционала - личное дело каждого.

По моему мнению шифрование предназначено: 1. Для предотвращения копирования устройств третьими лицами. 2. Для обеспечения невозможности внесения несанкционированных изменений в ПО. Идентификация клиентов и, соответственно, индивидуальное обновление ПО определяется другими параметрами. Эти параметры всегда можно прочитать с устройства и эти же параметры входят в заголовок прошивки. Идентификация по заголовку как минимум обеспечивает: 1. Прошивка одного клиента не подходит другому клиенту. 2. Прошивка для одного типа устройств не подходит к другому типу устройств. Т.е. возможность не выпускать новое обновление для конкретного клиента существует. Но мне в этом плане проще, так как у меня клиентов меньше десятка. Это достаточно крупные компании, закупающие наше оборудование. Если бы пришлось заниматься розничными продажами, возможно подход был бы другой. +1 Не ломите цены и постоянно развивайте функционал. Если стоимость вхождения в бизнес высока, а потенциальная прибыль невелика, то никто к Вам и не полезет и взламывать не будет. А если где то цены космические, то я и взламывать ничего не буду, а разработаю аналогичное устройство, напишу софт с нуля, и выйду на рынок.

Если речь идёт о ключе шифрования, то да, я использую один сложный ключ для всех устройств, в которых предусмотрен механизм удаленной замены прошивки. Алгоритм шифрования выбирал вынужденно. Устройства выпускаю на разных процессорах, поэтому нужен был чисто программный алгоритм. В свое время удалось найти только AES, на нем и остановился (AES-256). Используется уже более 5 лет (около двух десятков видов устройств общим тиражом тысяч тридцать, наверное) и пока о случаях взлома ничего неизвестно. Но кроме ключа шифрования есть ещё различные опции, которые характеризуют устройства и версию ПО. Это идентификатор устройства, версия ПО, идентификатор клиента и ещё некоторые опции специализации. Такая же информация находится в заголовке прошивки, который не зашифрован, но защищен от изменения зашифрованным ключом. Заголовок использует программа загрузки, которая реализует интерфейс с пользователем, и принимает предварительное решение о том, подходит ли данная прошивка для данного устройства/клиента. А окончательное решение о возможности заливки ПО принимает уже загрузчик в устройстве.

У меня проблем слишком большого количества клиентов нет, но в принципе считаю, что проблемы обновления миллиона прошивок лучше переложить на миллион клиентов. Есть загрузчик, содержащий ключи шифрования, в устройстве, залоченном на предприятии. И есть сайт, на котором публикуется актуальная программа для прошивки девайсов, а также последние прошивки (естественно зашифрованные) с информацией об изменениях в них. Клиенты сами всё это скачивают и заливают. Для особо одаренных есть видеоролик с пояснениями. Так как в расшифрованном виде прошивка восстанавливается только внутри залоченного девайса, то защита интеллектуальной собственности сводится к обычным правилам безопасности на предприятии. А задача публичной программы для прошивки - передать загрузчику зашифрованную прошивку без каких либо преобразований.

1. Старая версия uniflash (3.4.1) умеет программировать через сторонние JTAG или SCI (UART), но ничего ещё не знает про контроллер TMS320F28075. Никогда не пробовал, но в интерфейсе такой режим выбрать можно, значит вероятно работает.

Алгоритм очень простой: Если выходной код ПИДа у Вас упирается в ограничение (снизу или сверху), то Вы должны блокировать дальнейшее изменение интегральной составляющей. Это примерно эквивалентно насыщению ОУ в аналоговой схеме. Как только выход возвращается в диапазон регулирования, интегральная составляющая разблокируется и снова может изменятся. Нужно только не забывать про полярность ошибки. Если ошибка меняет знак, то блокировка тоже снимается.

Вообще говоря построение качественного преобразователя с прямым микропроцессорным управлением зависит от 3 основных факторов: 1. Измерения 2. Реализация регулятора 3. Формирование ШИМ На каком процессоре это делать, конечно важно, но на частотах сравнимых с частотой сети - не очень уж и важно. И конечно можно сделать качественный регулятор на гораздо меньших частотах преобразования и с гораздо менее производительным МК. 1. Измерения. 1.1. Желательно исключить время, когда происходит коммутация силовых ключей. Т.е. ШИМ модуль должен формировать отдельный строб запуска АЦП в момент времени, когда коммутаций нет. 1.2. Чтобы минимизировать воздействие помех нужно производить несколько измерений и использовать простое усреднение или накладывать фильтр с определенной характеристикой в зависимости от задачи. 2. Реализация регулятора. 2.1. В простейшем случае это может быть одноконтурный ПИД регулятор, на вход которого подается сигнал ошибки, на выходе формируется задание на ШИМ. 2.2. Нужно обязательно предусмотреть ограничение интегральной составляющей. 2.3. В более сложных случаях используются многоконтурные регуляторы подчиненного или параллельного регулирования. 2.4. Иногда требуется добавить контур токоограничения, который вступает в действие при резких изменениях нагрузки или в аварийных режимах. 2.5. Иногда целесообразно добавления контура регулятора по возмущению (то о чём писал ранее - это регулятор по отклонению). В общем тема это отдельная и сложная, решению в лоб обычно не подчиняется, литературы в сети много, в том числе приведены и методики настройки ПИД-регулятора. 3. ШИМ-модуль. 3.1. Нужно рассчитать и проверить на модели требуемую длительность "мёртвого времени" для ключей. Я уже не говорю о том, что нужно выбрать оптимальную топологию силовой схемы, есть масса вариантов обеспечения мягкой коммутации силовых ключей. 3.2. Обязательно предусмотреть несколько каналов программно-аппаратных защит разных уровней. 4. Ну и последнее, с точки зрения МК, при управлении силовым преобразователем важен абсолютный real time. Т.е. вы чётко должны представлять сколько времени у Вас выполняется тот или иной кусок кода, когда и в какой последовательности что у Вас выполняется и что никакие события в системе не повлияют а скорость обработки критически важного кода.

Спасибо, но насколько мне удалось выяснить: 1. Старая версия uniflash (3.4.1) умеет программировать через сторонние JTAG или SCI (UART), но ничего ещё не знает про контроллер TMS320F28075. 2. А новая версия (4.2.1) работает только через родные техасовские отладчики и не поддерживет последовательный интерфейс, увы.

Здравствуйте! Совсем не DSP, скорее просто MCU, но всё же TI, может кто знает... Долгое время работал с разными контроллерами серии С2000 и Piccolo. Программировал всегда с помощью C2Prog. Сделали новое устройство на относительно новом контроллере TMS320F28075PZA. Оказалось, что в C2Prog (1.7p-b7195) для программирования этого кристалла доступны только две опции: JTAG_20MHz и SCI_20MHz. В обоих режимах C2Prog успешно загружает свой загрузчик и далее не получает ответа от кристалла. Возникла мысль, что загрузчик C2Prog рассчитан на тактирование от внешнего кварца с частотой 20МГц. Присоплил кварц на проводках, и о чудо, программа стала нормально загружаться. Из-за особенностей проектирования конкретного устройства наличие внешнего кварца исключено. Хотя мне интерфейс программирования нужен однократно только для загрузки собственного загрузчика, но необходимость для этого подключения кварца напрягает. Подскажите другое доступное ПО для программирования TMS320F28075PZA, которое без проблем работает на внутреннем генераторе и через последовательный порт. Спасибо.

Ок. Я просто не пытался использовать STM32 для сложных проектов. Там где нужен ШИМ на высокой частоте, мой выбор - Texas. Но если таймер этого семейства STM32 может работать в режиме Hi Resolution, то вопрос по этому поводу снимается. Если у Вас частота обновления ШИМ 100кГц, то вся обработка данных (и все измерения), задействованных для расчётов ШИМ, должна проводится с этой частотой. Если у Вас по факту задержки сравнимы с частотой сети, то вероятно в алгоритм где то затесались параметры, которые рассчитываются с этой частотой. RMS или что-то подобное. Проверьте ещё раз код, чудес не бывает.

Достаточно ориентироваться немного в физике, немного в математике. Стоит напомнить, и неплохо проверить, что если обновляете относительную длительность ШИМ с частотой 100кГц, то у Вас на всю обработку 10мкс. Т.е. чтобы алгоритм управление хоть как то работал, нужно, чтобы время обработки прерывания не превышало 70-80% от этого времени, т.е. не более 7-8мкс. Проверяли это? Далее: Вас спрашивали про таймер, который Вы используете для формирования PWM. У STM32 таймера достаточно тупенькие и не могут работать на частотах выше тактовой ядра. Если у Вас частота ШИМ 200кГц и при этом таймер считает до 5760. Это должно бы было означать, что частота ядра равна 5760 * 200000 = 1152 МГц. Такого быть не может, поэтому следует уточнить Ваши ответы. А вообще при проектировании ШИМ контроллеров на базе МК нужно чётко представлять длительности и частоты всех процессов. А особенно работу критичных по времени модулей, таки как PWM и ADC.

Простите, а где Вы это увидели? На приведенной картинке видно, что flash расположена 0x08000000 - 0x08007FFF. А Вы обращаетесь по адресу 0x08010000, что за пределами. Может проблема в подсчёте ноликов?

В общем и целом не совсем корректно писать в теневой регистр ровно в тот момент, когда он переписывается в основной регистр сравнения. И неважно через ДМА или напрямую. Время от события до выполнения записи ДМА не всегда одинаковое и может зависеть от многих факторов (частоты шин, их занятость и т.п.) Я бы синхронизировал ДМА по какому нибудь событию таймера, которое гарантированно не совпадает с апдейтом. Для этого можно задействовать свободный канал сравнения, если такие есть.

Может начать с самого начала? Предполагаю, что на старой ревизии платы всё работало. Осциллографом посмотреть сигнал BOOT1, Посмотреть документацию на DC/DC, нет ли там на входе ENABLE pull-up резистора, который пересиливает Ваши 10к. По симптомам очень похоже, что при сбросе через отладчик сигнал не успевает подняться от нулевого уровня из за емкости дорожки и всё работает. А при подаче питания BOOT1 уже равен 1.

Это же был просто пример. У меня в файле *.icf объявлена секция ".noinit", в которой и размещаются эти переменные. У Вас видимо этой секции нет. Размещайте переменные в существующей секции. По поводу ключевых слов DATA и CODE - я всегда явно указываю, что размещаю: данные (переменные или константы в зависимости от секции) или код программы. Возможно где то это и не обязательно, но и вроде как не мешает.

По моему у Вас всё перепутано. Вот фрагмент кода, ассемблер редко приходится использовать: //-------------------------------------------ПЕРЕМЕННЫЕ--------------------------------------------- SECTION `.noinit`:DATA:NOROOT(2) DATA D_NUM DS16 1 ; Серийный номер D_DAT DS16 1 ; Дата выпуска dummy DS16 2 //-------------------------------------------КОНСТАНТЫ---------------------------------------------- SECTION `.rodata`:CONST:NOROOT(2) DATA ;--------------------------------------------------------------------------------------------------- sys_param: DC16 0, 9999, 1234, 0x90 + T_DEC + F_EXT + F_WRT DC8 ' Регистр команд ' Синтаксис скорее определяется используемой средой, чем платформой. В секции, предназначенной для размещения кода, невозможно разместить переменные. А различия в объявлении должны быть понятны из примера.

Думаю, что более просто будет так: При условии, что CS-ы посажены на один порт. Задействовать 1 дополнительный канал DMA, который будет синхронно писать данные в регистр BSRR соответствующего порта, тем самым дергая нужные CS.

Почему то мне кажется, что во время экспериментов плата у Вас не заземлена, а на запястье нет браслета для снятия статики. А значит в момент касания Вы подключаете к выводу микросхемы конденсатор на несколько десятков пикофарад, заряженный до нескольких киловольт. Это эквивалент Вашего тела в достаточно сухом воздухе, если что. А далее получается емкостной делитель, где ток разряда Вашей емкости заряжает емкость на входе. И вполне может быть, что эквивалентное напряжение на входе превысит логический уровень. А если бы это был просто висячий вход, то таким образом легко его убить. Недаром всех монтажников заставляют браслеты одевать и работать заземленным инструментом. Бывает, что у некоторых процессоров есть система внутренней синхронизации, которая не пропускает наносекундные (иногда и микросекундные) импульсы. Видимо в STM такого нет. Это не значит, что процессоры плохие. Просто Вы использовать пытаетесь их не совсем правильно.