Также нашел решение для PLL jitter в напр. STM32F103:
использование внешнего генератора (причем у меня есть и TCXO) к RCC_OSC_IN устранило воздействие.

Если перепаять gd32f103rct6 на плате гироскутера на такой же заказанный с алиэкспреса, получиться его сразу прошить через выведенные на плате swdio и swclk ??? или предварительно понадобиться еще шаманить. Для китайских ардуинок, бутлодеры перепрошивал, по этому вопрос возник. у стмок вроде как собственый бутлодер уже вшитый, может ошибаюсь

Причём тут бутлодырь STM? Для SWD бутлодырь не нужен. Он нужен если шить хотите не через SWD, а через какой-то интерфейс камня. Если есть SWD - прошить сможете.

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

Спасибо!!! Флешки внешней вроде нету, все в исходнике от Феру с гитхаба, прошивка компилируется. Это плата гироскутера, подпалил пины на курке газа и тормоза (в оригинале рх тх с левой платы). заказал с алиэкспреса за 120р, через пару недель придет

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

Вот кстати: Для своего 3D-принтера я тоже нашёл проект исходников на гитхабе. И он собирался. Но собранный и прошитый в МК образ ни в какую не хотел запускаться. Потом оказалось, что скомпилённый образ нужно было ещё после компиляции пропустить через некую утилиту, которая что-то там в нём правила (в бинарнике). И уже такой исправленный и зашитый образ стал нормально запускаться в принтере. Могут и у вас что-то такое навертеть. Китайцы - они такие затейники!

чудеса!!! перепайка контроллера откладывается. вроде пины целые. удалось заставить крутиться колесики и даже в нужную сторону (для самоката нужно чтобы правое колесо гирика крутилось в обратную сторону). но крутится медленно. рукой останавливаю.

Сами принтер собрали? Круто! Самому тоже хочется. для печати пластиком из бутылок (бесплатный филамент) больших предметов. хочется кейсы печатать для инструмента. там можно большим соплом фигачить, точность большая не нужна. Боюсь так и останется мечтой. Так то у меня есть 3д летающий медмедь, дети на др подарили, печатаю по мелочи для себя

Вы не поверите... Я начал работать с ARM. Пришлось, т.к. сменил работу, и теперь разгребаю наследие... Пока лишь stm32l052, но сразу с 2 каналами Modbus (мастер и слейв). Чтоб жизнь мёдом не казалась, впридачу FreeRTOS и CubeMX/IDE.

Так что бойтесь, скоро от меня начнут поступать вопросы...

Ну, вот и первый вопрос от новичка (не яда).

В stm32l052 есть встроенная EEPROM. Естественно, с условно небольшим ресурсом перезаписей. Существуют какие-то готовые решения для продления ресурса EEPROM?

ARV, существуют - https://habr.com/ru/articles/561678/

благодарю! но С++ не мой вариант. идея с кэшированием (отложенной перезаписью) мне, в принципе, известна, но не нравится, т.к. всегда существует вероятность, что питание будет выключено до "сброса кэша в EEPROM".

Это всего-лишь проблема вашей программы/устройства. Это вы их такими создали, что питание "может быть выключено до сброса кэша в EEPROM". Никто не мешает их создать так, чтобы такого не случалось.

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

И это проблема тоже решается, той-же секцией "noinit".

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

Люблю я знатоков, которые сразу зрят в корень проблемы! Если бы это было МОЁ устройство, то ваши обвинения могли бы быть справедливы. Но это не так, на самом деле. И моя задача - сделать всё, что можно, в имеющихся аппаратных рамках. Если можно, помогите советом, а не ярлыками и обвинениями.

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

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

И я вас не обвиняю. Устройство же ваше? Ваше. Пускай вы его и приняли от кого-то, но вы же согласились его принять. Значит теперь оно - ваше.

Я-то его принял, но в качестве программиста, а не аппаратчика. Менять схемные решения меня не уполномочили, во всяком случае, в этом изделии. А в других ФРАМ.

И я борюсь с этим, и потому прошу помощи.

Не представляю - как силами только программиста добиться появления в схеме нормального монитора питания? Или как повысить класс устройства по устойчивости к ЭМС?
Может я не достаточно магический программист.

Повторяю для недостаточно магических программистов: надо программно максимально продлить ресурс EEPROM. Что невозможно, то невозможно, но если хоть что-то можно - надо сделать.

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

Не зная что за "переменные" и как устройство их использует и модифицирует - ответить невозможно.
Если в устройстве есть внешняя флешь большого объёма, может лучше хранить там? В кольце.

В устройстве есть STM32L052 и два драйвера RS485. Не считая клемм и светодиодов.

Данные это разные параметры установки, которые воемя от времени оператор меняет. Это и байты, и 16-битные, и float-ы... Разные. И нет никаких закономерностей их изменения, кроме того, что все они вводятся вручную и приходят в МК по модбасу. Т.е. никогда не будет (кроме первой инициализации) записи чаще, чем 1 раз в несколько секунд, т.к. физически быстрее ввести данные невозможно.