Ну, естественно, это я нарукожопил! Полез в табличку "STM32G0x1 peripheral register boundary addresses", а там:

А не как у всех остальных, где было 0x4000 6000. Ну, оно, в принципе, и понятно: 2кБ в месте для 1кБ не запихнешь.
Т.е. сами регистры USB на старом месте (0x4000 5C00), поэтому начальное конфигурирование мне хардфолты не давало, а вот непосредственно ОЗУ конечных точек…

Отсутствие упоминания о FIFO в DMA не означает его отсутствия.
При приближении к частоте транзакций в 4 раза меньшей, чем частота шины, внезапно обнаруживается, что FIFO там есть.
FIFO в UART и SPI - такое себе "удобство"... Фактически имеется FIFO глубиной 2. Буферный регистр и сдвиговый регистр. Если их не хватает, нужно использовать DMA, а не ходить по краю.

Купил несколько типов Geehy APM32 для тестирования. В Keil: то же самое как STM32. Kое-где чего-то не хватает из regs, а что-то сделано по-другому. Практически идентичны. CMSIS. Особых трудностей нет. Нравятся. Куплю и AT32. Спасибо за идею.

Т.е. китайцы в RM про FIFO в DMA ничего не написали, на диаграмме его не нарисовали, при этом DMA полностью содран с ST-го, если DMAMUX не трогать, просто имена полей другие, а у ST есть аппноут где для этого DMA тайминги расписаны и тоже никакой FIFO не упоминается, но вы вывели его наличие опытным путем? ) Можно еще глянуть для STM32 "Migration Guide", там в табличках четко видно, что у одной серии FIFO у DMA было, а у другой его нет, или наоборот.

Спойлер

У F2 DMA как у F4, с FIFO, а у L4 DMA как у Artery, без FIFO.

Именно так. И это очень просто. При превышении 1/4 от частоты шины DMA уходит в ошибку и видно сколько транзакций он успевает совершить до этой ошибки. Это и есть глубина FIFO плюс два. Успевает сделать 6 транзакций.

Извините, но это очень не очевидно ) Для начала, FIFO - это хорошо. Если FIFO есть, но было бы очень странно об этом не написать, а если его нет, то тут как раз ничего странного учитывая, что его нет даже в SPI/USART. И посмотрите вот на что... У STM32 все DMA без FIFO однопортовые, а все DMA c FIFO - двухпортовые. Двухпортовый может читать из памяти и накапливать данные в FIFO, потом из него передавать дальше. Однопортовые так не могут даже если бы FIFO в них было, т.к. из-за системы рукопожатий следующая транзакция не может начаться пока не завершилась предыдущая. Читаем, пишем через тот же порт, только потом опять читаем, FIFO здесь практически бесполезно.

В общем, не без помощи дипсика (он мне пару косяков указал, на которых у меня "глаз замылился") USB таки у меня заработал. Как вылижу код, выложу сниппет на гитхаб (ну и прочие кодохранилища, у меня зеркала на: битбакете, сосфорже, гитлабе, гитфлике, нашем обсерваторском gitea-сервере и рабочем git-сервере).

Это конечно замечательно. Осталось узнать область использования. Не абстрактно, а конкретно. На более-менее актуальном примере задачи.
Есть смутное подозрение, что столь замечательное свойство не может всерьез определять выбор чипа в 99,99(9)% проектов

Совершенно не согласен. Множество раз использовал SPI и UART с FIFO без DMA (в тех МК где FIFO имеются). И это очень удобно. Нужно передать например кадр по SPI: Просто записываю его в FIFO SPI и стартую трансфер. Всё! Не нужно никаких буферов в ОЗУ (для DMA), не нужно программировать DMA, никаких задержек между словами (как в случае использования DMA для загрузки/выгрузки слов из/в ОЗУ). Кадр передаётся без разрывов и на максимальной скорости. А если после завершения транзакции, принятый блок данных не нужен - просто делаю flush FIFO и всё - без доп.буферов и ненужной загрузки шины.

Вы видимо никогда не работали с МК, имеющими нормальное FIFO в UART/SPI. Поэтому не догадываетесь о преимуществах его перед DMA (или перед связкой: DMA+FIFO+SPI).
Элементарный пример: Имеется некая система с master-SPI (МК). Требуется генерация SPI-транзакций с точно выдерживаемой времянкой. Времянка должна выдерживаться с точностью до такта МК. Тогда сигнал CS формируем таймером (CS - от ноги таймера). Высокую частоту (с запасом) по SCLK поставить нельзя (slave не умеет). Но если аккуратно вставить кадр внутрь интервала CS=low, выдерживая минимально допустимые задержки от краёв CS=low до битов данных, то будет работать. Но как тут быть если нет FIFO в SPI, а есть только DMA? Ведь в системе есть другие DMA-пересылки и есть CPU (который тоже занимает шину). А значит - будут неизбежные задержки выборки DMA из/в ОЗУ и задержки между словами на MOSI/MISO. И трансфер будет иногда (изредка) вылетать за пределы окна CS=low.
А если есть FIFO в SPI, то можно в него загрузить данные предварительно (до CS=low) и также выгрузить - после установки CS=high. А стартовать SPI-трансфер внутри интервала CS=low можно от аппаратного сигнала таймера с точностью до такта CPU. Тогда все тайминги по SPI будут выдержаны идеально точно, с точностью до такта.

Ещё в нормальных МК с FIFO в SPI программа может в SPI записать сразу несколько транзакций: указав границы CS=low, данные, интервалы между переключениями CS и данными и т.п. И стартануть эту пачку транзакций сразу всю. Получив в конце одно единственное прерывание. Это полезно при работе с SPI слэйвами, требующими множество отдельных мелких SPI-кадров для выполнения какой-то одной операции с чипом. Например: радио-чипы (типа SX127x) - часто требуют перепрограммирования нескольких разных регистров с несмежными адресами в процессе работы (при переключении приём<->передача, считывании и загрузке данных, ...). Или например DW1000 - тоже нужно писать/читать множество регистров (и на макс. скорости). Пишу сразу всю пачку транзакций в FIFO и получаю одно единственное прерывание после выполнения их всех. Вместо множества прерываний.

Также полезно FIFO в UART. В одном проекте например требовалось от одного МК к другому передать по UART не только данные, но также и сигнал синхронизации. Для синхронизации работы внутренней периферии ведомых МК с ведущим. Требовалась синхронизировать работу ШИМ-ов управляющих мощными моторами от разных МК как можно точнее. Желательно - с точностью до такта CPU. И желательно - с минимумом проводов (по одному UART и данные и синхро-сигнал). Любое рассогласование работы ШИМ - резкое снижение КПД системы и опасность выхода из строя. И в том МК имелось нормальное FIFO в UART с возможностью аппаратного старта передачи UART от сигнала таймера. Поэтому: предварительно загружал передаваемый кадр данных в FIFO UART, а потом стартовал передачу UART.TX от аппаратного сигнала таймера. Таким образом - положение первого старт-бита этого кадра было идеально точно синхронизировано с работой внутреннего таймера МК. Без влияния задержек из-за доступа DMA к шине данных. И ведомые МК могли точно (до такта) синхронизировать работу своих внутренних таймеров с UART.RX.

PS: К сожалению - ничего подобного STM32 не умеют.

В Stm32CubeIDE есть какой-то простой способ при отладке узнать, сколько времени прошло с предыдущей остновки на брейкпоинте?

Добавлено after 2 hours 14 minutes 44 seconds:
спасибо всем, кто не захотел помочь. всемогущий ИИ подсказал, как это решить.
теперь понятно, кого ИИ вскоре заменит - многочисленных супергордых знатоков, на работе останутся одни не гордые неучи.

ARV, вы узнали что хотели, но еще дополнительно овладели полезным навыком, что не нравится то? )

что форум из места, где можно получить помощь, превратился в место, где можно получить ведро помоев на голову. а так всё ок.

ARV, вы на форуме много лет, неужели для вас является открытием, что можно задать вопрос и ответа ждать часами или даже днями? Особенно в последние годы, когда активность упала. Особенно когда намного проще и быстрее получить ответ от ИИ. Особенно если вопрос про Stm32CubeIDE, который супергордые знатоки скорее всего не используют.

Сейчас на форумах очень тихо и мало кто здесь обитает
Больше всё в телеге в группе какой нибудь обсуждают - причём почти в реальном времени.

Но телега как-бы тоже может исчезнуть и начинают на МАКС заходить.

Это же IDE, а не конфигуратор. Не вижу причин не использовать, если эта среда устраивает. Просто я работаю в Кайле и мне все нравится. А кому то зашла родная среда.

Да я весь день на работе был, чесслово!
А ИИ, как поисковик, действительно работает очень быстро. Не всегда правильно, но в общей массе неплохо.

Между прочим, на форуме, если смотреть "активные темы", то список состоит сплошь из объявлений о продаже, и между ними теряются остальные темы, которых 2-3 штуки на 20-30 продажных объяв. Видимо, основное назначение форума - продажка. И в основном, какого-то старого барахла, найденного на мусорках и в подвалах бывших заводов.

IDE всяких полно, просто чисто математически процент людей использующих CubeIDE и при этом попадающих в категорию "супергордых знатоков" будет не очень высоким. К тому же CubeIDE в 2019-м только появился, было бы странно предполагать, что опытные разработчики побросали ради нее свои Keil/IAR/VS/Segger ES )

Ну не знаю, как там Кейл, но хуже иара я IDE не встречал. А к эклипс-подобным привык за годы работы с AVR

IDE вообще вторично. Если человек умеет разрабатывать, он и в nano сможет работать при необходимости. IDE лишь слегка упрощает работу. Может, на единицы процентов быстрей получается, ну и несколько удобней.

А до этого он лет 10 как назывался Atollic и был кроссплатформенным и весьма недурным инструментом, добравшимся аж до 9-й мажорной версии
Но после того, как примерно в 2017-м его выкупила ST Microelectronics, Atollc сначала потерял все модели микроконтроллеров, кроме чисто к STM, а затем и вовсе закончил свои дни на версии 9.3.0 и перелицевался в CubeIDE 1.0.0, потеряв при этом немало исходного функционала. Но взамен получил изрядную долю косяков. И лишь спустя почти 7 лет появилась версия 2.0. То есть, новая лошадь слишком медленно ходит...

Добавлено after 42 minutes 24 seconds:

Вообще-то, хорошая IDE - это всегда лучше, чем "блокнот". Как минимум, появляются возможности редактирования и навигации по тексту и файлам. Рефакторинг кода - отслеживание изменений имён функций, переменных, файлов и прочего, перемещение блоков, автоматическое форматирование, автозавершение ввода, списки автоподстановки. Это прям значительно экономит время при наборе текста. Во-вторых, можно отслеживать иерархию вызовов функций. То есть, видите какую-то функцию и вам надо узнать, используется ли она вообще в коде, и если да, то из каких мест вызывается.
В третьих, быстрая навигация по коду щелчком по имени функции, переменной и прочего. Подсветка всех вхождений имени и многое другое.





Так что, когда проект объемный, многофайловый, хорошая IDE очень ценна. Здесь мало просто "уметь разрабатывать". Здесь надо еще и уметь ориентироваться в проекте и вносить изменения, правки. Внесение исправление - это нормальная практика.