В устройство может быть запаян как STM32F103xC , так и STM32F103xB чип.

В "старшем" собрате ( тип "С") есть дополнительные таймера и Usartы...

Что будет, если попытаться на чипе "B" обратиться к периферии, которой на чипе B - нету?

Например проинициализировать 5-й таймер или 4-й usart и попытаться заставить их работать?

Или можно как-то программно определить тип чипа и не пробовать такую скользкую ситуацию?

По-моему, никак. Тот же ST-Link определяет процы, например, как "STM32F10x Connectivity Line" - F105/F107 в куче - а вы сами догадайтесь, есть ли там Ethernet (F107) или нет (F105).
Аналогично F407/F409 == F40x, F427/F429 == F42x, F437/F439 == F43x.

Поэтому всегда пишите под конкретный чип.
Насчёт обращения к несуществующей периферии - не знаю, проверьте.

Можно включать тактирование блоков, и проверять, включилось или нет. Вот здесь VslavX описывал.

Cortex должен генерить соответствующее исключение при обращении к несуществующим адресам.
Точно не помню, но скорей всего либо "bus fault, точная ошибка при обращении к данным"
либо "bus fault, неточная ошибка при обращении к данным".
Так что проверка очевидна:
Пишете обработчик данного исключения, включаете периферию, обращаетесь к любому
её регистру, получили fault - значит её нет.

Это в общем случае для всех Cortex-M3.
А в частности - у LPC через IAP (встроенное API работы с флеш) можно считать идентификатор устройства,
определить чип и соответственно - набор периферии.
Странно, что у STM такого нет...

Спасибо, попрбую..



Очень полезная функция, получается что ее в моем случае достаточно.
смущает только , неизвестное макроопределение-

SYSMEM_FSIZE

Это просто адрес или что-то посложнее?

Судя по контексту топика это константа во флешь-памяти контроллера по адресу 0x1FFFF7E0:

Aга, спасибо, уже попробовал .
вроде работает на xB, а хС кажись как-то странно запорол - прошился, и - не определяется по swd... буду копать дальше..

Разобрался и впал в ступор..

похоже, какой-то конфликт периферии, причем одинаковой для B и С версий контроллера

если я выполняю вот эту строчку



То на контроллере " B " она выполняется и действительно ремапит ком 3 на выбранные ноги,
а на контроллере "С" этот код не приводит к ремапу выхода ( на ноге TX остается лог 0 ), и после прошивки контроллер перестает работать с swd!!
стираю его через бутлоадер..

PS: внимательно проверил- ремап таки происходит, но вот дебаг ( swd) почему-то продолжает не работать

Древнейшие грабли! Так пользоваться регистром MAPR (|=) запрещено! Почему - обсуждалось не раз))

Внимательно проверил- ремап все-таки происходит, но вот SWD почкему-то не работает при этом..

если верно предположение что биты отвечающие за SWD не читаются из регистра ремаппинга, то почему же на одном проце читаются, а на другом- нет?

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

В документации написано: "These bits are write-only (when read, the value is undefined)".
Если сам разработчик не может предсказать, что прочитается, то какого ответа Вы ожидаете?
Просто не используйте результат чтения этих битов, а записывайте их принудительно при каждой записи в MAPR.
Почему swd отваливается Вам очевидно. Как этого избежать - тоже. Обсуждать почему STM-щики так подло поступили и когда исправятся - нет смысла.
В новых семействах такой проблемы нет.