Reference manual говорит другое, да и к сути вопроса это никак не относится.
2 лайка
кто-то из нас (я или референс мануал врёт), видимо я и чип имеет DeviceID 0x10006431 а не 0x431, который отображается всеми мыслимыми и немыслимыми программами
13:56:52 : V2J37S7
13:56:52 : Connected via SWD.
13:56:52 : SWD Frequency = 4,0 MHz.
13:56:52 : Connection mode : Normal.
13:56:52 : Debug in Low Power mode enabled.
13:56:52 : Device ID:0x410
13:56:52 : Device flash Size : 128KBytes
13:56:52 : Device family :STM32F10xx Medium-density
ты нижнюю строчку прочитал? а теперь весь датащит проштудируй, на предмет какой размерности DeviceID
если тут не увидел, что он 12 бит
это не ты опять писал?
я, но я не писал сколько из двух значащих бит, но в моём коде это есть
это твоя уникальная возможность, говорить об одном, писать другое, а думать о третьем.
и при этом надеяться на понимание.
вы че блин спорите ни о чем, вопрос был что ID вообще не читается в нормальном режиме F103.
1 лайк
программисту достаточно мельком глянуть на мой и всё будет ясно, к чему слова, как только открыл рот уже неправда )))
ну я же показал, что читается прямым считыванием, ты показал что читается средствами на уровень выше, выяснили жеж, что это их лживый HAL, недаром к нему у тебя было такое скептическое отношение )))
я ему это тут STM32CubeIDE (вопросы и ответы) - #1026 от пользователя xDrivеr
сказал, но у него же подгорает…
ребята, человека надо спасать…
что ты показал?
что из этого поста тебе не понятно?
2 лайка
а как оно тогда читает в нормальном режиме?
Что я не так сделал?
[quote="ua6em, post:997, topic:14811"]
```
// Чтение Device ID
uint16_t deviceID = *(volatile uint16_t*)0xE0042000;
```
[/quote]
не передернул питание.
получишь 0х00, вот о чем был разговор.
1 лайк
подключил, открываю монитор порта:
14:29:56.166 -> Расширенный поиск Device ID 0x410...
14:29:56.166 -> ===================================
14:29:56.166 -> Адрес 0xE0042000: 32bit=0x20030410 16bit=0x410 <- НАЙДЕН 0x410!
14:29:56.166 -> Адрес 0x1FFFF7E8: 32bit=0x1A5A5BB5 16bit=0x5BB5
14:29:56.166 -> Адрес 0x1FFFF7E0: 32bit=0x80 16bit=0x80
14:29:56.166 -> Адрес 0x40015800: 32bit=0x0 16bit=0x0
14:29:56.166 -> Адрес 0xE00FF000: 32bit=0xFFF0F003 16bit=0xF003
14:29:56.166 -> Адрес 0x1FFFF000: 32bit=0xD0542803 16bit=0x2803
14:29:56.166 -> Адрес 0xE0042004: 32bit=0x0 16bit=0x0
14:29:56.166 -> Адрес 0xE0042008: 32bit=0x0 16bit=0x0
14:29:56.166 -> Адрес 0x1FFFF7F0: 32bit=0x1EF3698 16bit=0x3698
14:29:56.166 -> Адрес 0x1FFFF7F8: 32bit=0x0 16bit=0x0
PS ты залил мой скетч и у тебя показывает 00
код выкладывай
выше всё выложено, бери не хочу
Вечер перестает быть томным 
открываю страницу 1089 RM0008
MCU device ID code
The STM32F10xxx MCUs integrate an MCU ID code. This ID identifies the ST MCU partnumber and the die revision. It is part of the DBG_MCU component and is mapped on the
external PPB bus (see Section 31.16 on page 1102). This code is accessible using the
JTAG debug port (4 to 5 pins) or the SW debug port (two pins) or by the user software. It is
even accessible while the MCU is under system reset.
Only the DEV_ID(11:0) should be used for identification by the debugger/programmer tools.
DBGMCU_IDCODE
Address: 0xE004 2000
Only 32-bits access supported. Read-only.
т е я как я понимаю - оно всегда должно работать и Debug mode вообще тут ни при чем. Считать можно любыми средствами и оно всегда будет корректным.
PS. Но в любом случае надо пробовать, и конечно без всяких прокладок в виде HAL.
P.P.S. Всяким error list и прочим я верю, но и чипы у нас (у меня во всяком случае) никак не оригинальные, и хз сколько еще чудес нам покажут.
о чём речь, что это в HAL чёйта намудрили…есть конечно вероятность что в наших чипах этот глюк поправили, у меня 8 летней давности где-то был, надо бы спытать
с другой стороны если твой или мой код будет читать, а в их коде этот глюк есть то это однозначно HAL