поставьте здесь, хоть мегу в ногодрыге

Стесняюсь спросить - резисторы подтягивающие на линиях есть?

Не первый день замужем.
Логический анализатор (Zeroplus LAP-C) подцеплен к шине - нет никаких глитчей при рестарте, стабильно в единице и SCL и SDA. Посмотрел осциллографом уровень (думал просаживает что то) - нет, 3.3 вольта есть, как положено.

Было бы так - не стали бы с кубами водиться

Обращаюсь ко всем, у кого не работает аппаратный I2C. Вы прочитали руководство, документацию по ошибкам, настроили все регистры, и - не работает?? Шайтан помешал?

Ардуринщики мануалы не читают. Они "скетчи" в интернете ищут.
О каком руководстве можно спрашивать в теме о всякой гадости вроде HAL/SPL/Qube?

Ну так подвернулся хороший случай на практике попробовать, так ли уж губительны эти диавольские искушения. Получить проект с мигающим светодиодом и (на первый взгляд) рабочим USB CDC за время меньшее, чем обычно уходило на то, чтобы только разобраться по мануалам какие GPIO куда расписать.

Надо признать, что пока если что и приведет к фиаско, то не куб, а банальная глючность конкретного камня. К чести ST расписанная в errata (до чтения которой дошло только после того как грабли сделали свое черное дело).

Ну, это у Вас еще везуха сплошная, если уже что-то спроектировано-смонтировано и как-то работает, а в еррату еще и не заглядывали.
Я обычно еррату читаю раньше чем основную документацию, на этапе выбора МК под задачу. Бывает, ее чтение переворачивает все с ног на голову.

Куб хорош для понимания, в чем накосячил при написании собственной работы с периферией.

Я, к примеру, долго не понимал, почему у меня не работает SPI - не принимает данные и все тут. В кубе работает, а в моем проекте - нет.
Оказалось, SCK обязательно должен быть выведен на ногу. Хоть мне он и не нужен (эмуляция 1-wire).

Без куба я бы от пары дней до недели потратил на понимание, почему не работает (и, возможно, не один камень). Ведь в документации этого обязательного условия я нигде не нашел.
С кубом хватило пол дня.

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

Если честно - то это вообще первый в жизни STM32 с которым я связался. До этого были игрища с NXP/Freescale/TI а до серии из 32-битников доходили только NXP.

куб убивает spl , а кубовские исходники никто не выкладывает, ибо и так никому не нужны

LPC1758/LPC1778/LPC1788/OMAP-L137/....

я вот тут подумал - для сабжа нужен какой-то метакуб, hal, но независимый от платформ, производителей и языков программирования

Присоединюсь... На 1758 и 1768 тысячи изделий "в поле", I2C используется интенсивно (расширители и I2C слейвы на базе пиков 16-х) - проблем нет. Правда там и не кубоподобное на низком уровне, а честно выстраданное бессонными ночами.

PS: Упоминавшийся на прошлой странице воркараунд из STшной Errata помог. Ровно на 2 минуты помог. Крутилось в цикле тупо вычитывая здоровый кусок EEPROM в буфер, и встало опять, в то же состояние с 10-сек таймаутом и возвратом с кодом HAL_BUSY.

Изучая сякие SPL и HAL к сабжу, и собственно, сабжи, пришел к выводу, что использовать из них можно только заголовочники (.h). И то с наятгом.
Так как никакой универсальности в плане работы с периферией они не несут. Так, к примеру, у 32F1 и 32F0 разная по возможностям периферия.
Тот же USART, SPI. И, написав код под F0, на F1 его запустить уже не получится. И HALы с КУБами никак не помогут.