STM32CubeIDE (вопросы и ответы)

xDrivеr · 25.Сентябрь.2025 15:42:52

ДА!
как и у меня, пасиб

толстый · 25.Сентябрь.2025 15:51:13

“Чем шмагла”(с)

Скетч из 1049(приблизительно) с установленным аддоном из 1066(около) - даже не компилируется, не говоря уже про то, что получить с него это
`6:55:26.505 → Анализ перемаркировки STM32
16:55:26.505 → =========================
16:55:26.505 → Реальный Device ID: 0x433
16:55:26.505 → Flash Size: 512 KB
16:55:26.505 →
16:55:26.505 → — Причины перемаркировки —
16:55:26.505 → Реальный чип: STM32F411CE
16:55:26.505 → Маркировка: STM32F401RET6
16:55:26.505 →
16:55:26.505 → Вероятные причины:
16:55:26.505 → 1. Перемаркировка с целью наживы
16:55:26.505 → - F411 стоит дороже F401
16:55:26.505 → - Продают дорогой чип по цене дешевого? Нет! Обычно наоборот!
16:55:26.505 → 2. Ошибка на производстве
16:55:26.505 → - Смешали чипы на конвейере
16:55:26.505 → - Неправильная упаковка
16:55:26.505 → 3. Ребаллинг (reballing)
16:55:26.505 → - Чип снят с другой платы
16:55:26.505 → - Перепаян в новый корпус
16:55:26.505 → 4. Партия с тестовых пластин
16:55:26.505 → - Чипы не прошли полный тест F411
16:55:26.505 → - Проданы как более дешевые F401
16:55:26.505 →
16:55:26.505 → Ваш выигрыш:
16:55:26.505 → • +16 MHz частоты (100 vs 84)
16:55:26.505 → • +64 KB RAM (128 vs 64)
16:55:26.505 → • Лучшая производительность
16:55:26.505 →
16:55:26.505 → — Проверка реальных возможностей —
16:55:26.505 → • +64 KB RAM (128 vs 64)
16:55:26.505 → • Лучшая производительность
16:55:26.505 →
16:55:26.505 → — Проверка реальных возможностей —
16:55:26.505 → Тест RAM…
16:55:26.505 → Тест частоты…
16:55:26.505 → Производительность CPU: 9561 мкс
16:55:26.505 → Стандартная производительность (~84 MHz)
16:55:26.505 → Тест FPU…
16:55:26.548 → Производительность FPU: 40918 мкс
16:55:26.548 → Результат: 147.75

тупо невозможно

О. ещё и код криво(но весело) вставляется

ua6em · 25.Сентябрь.2025 15:59:19

void setup() {
  Serial.begin(115200);
  delay(3000);
  
  // Чтение Device ID
  uint16_t deviceID = *(volatile uint16_t*)0xE0042000;
  
  // Чтение Flash Size
  uint16_t flashSize = *(volatile uint16_t*)0x1FFFF7E0;
  
  // Чтение Unique ID
  uint32_t uniqueID1 = *(volatile uint32_t*)0x1FFFF7E8;
  uint32_t uniqueID2 = *(volatile uint32_t*)0x1FFFF7EC;
  uint32_t uniqueID3 = *(volatile uint32_t*)0x1FFFF7F0;
  
  Serial.println("=== STM32F103C8T6 Information ===");
  Serial.print("Device ID: 0x");
  Serial.println(deviceID&0xFFF, HEX);
  
  Serial.print("Flash Size: ");
  Serial.print(flashSize);
  Serial.println(" KB (отображается)");
  
  Serial.print("Actual Flash: 128 KB"); // Физический размер
  Serial.println();
  
  Serial.print("Unique ID: ");
  Serial.print(uniqueID1, HEX);
  Serial.print("-");
  Serial.print(uniqueID2, HEX);
  Serial.print("-");
  Serial.println(uniqueID3, HEX);
  
  if (deviceID == 0x410) {
    Serial.println("✓ Устройство подтверждено: STM32F103C8T6");
  }
}

void loop() {
  delay(1000);
}

толстый · 25.Сентябрь.2025 16:33:10

Этот компилируется Разбираюсь как заливать, как выводить.

ua6em · 25.Сентябрь.2025 16:38:47

толстый · 25.Сентябрь.2025 16:55:54

Да бл… вспомнил, там ещё небось STM32CubeProgrammer устанавливать и джамперы на плате ковырять.

remosYa · 25.Сентябрь.2025 17:08:07

ничего устанавливать не надо, там уже всё есть!
Вот зачем полновесной неповторимой ARDUINO IDE какой-то ср… куб

где студент и где куб?

xDrivеr · 25.Сентябрь.2025 17:37:10

Вообщем то дискуссию можно считать законченой.
Подитог: @BOOM напоролся на баг, который четко описан в еррате на данный МК и на данный момент не имеет способов обхода.

andycat · 25.Сентябрь.2025 19:36:56

Я не соглашусь. Но проверять лень. МК делает то, что ему запрограммируют. Соответственно если ID читается только в debug mode, Значит его при включении надо загнать в этот режим принудительно, прочитать данные, и далее работать как обычно.

Arduman · 26.Сентябрь.2025 01:29:07

Однако в Еррате такой способ почему-то не описан.

(зачем вообще вам сдался этот ИД?)

andycat · 26.Сентябрь.2025 02:51:49

Мне из любопытства.

Arduman · 26.Сентябрь.2025 03:01:58

Это нормально.

Однако в процессорах столько ещё разных чудес, которые полезно изучить, что голова пухнет™. А с этой цифрой уже все в общем понятно. ИМХО.

remosYa · 26.Сентябрь.2025 04:16:42

объясните тогда студенту чего тут копья ломали, ничего не понял, какова цель? надеюсь не выпендрится друг перед другом

andycat · 26.Сентябрь.2025 04:40:22

stm32f103c8t6 не хочет отдавать корректный идентификатор и код ревизии, если не включен режим отладки. Ну я так понял.

Соотвественно если вы сделали готовое устройство, на идентификатор МК которого завязано какое либо действие, то в реальной жизни оно работать не будет.

BOOM · 26.Сентябрь.2025 04:51:22

Присутствуя отсутствовал? ))

BOOM:

Я открыл RM0008 и там на странице 1087 я прочёл вот это:
31.6.1 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). This code is accessible using the JTAG debug port
(four to five 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
И так как у меня не очень всё хорошо с английским языком, я немного не понимаю: Либо в принципе эти ID только при подключенном дебагере доступны, либо я не верно перевёл. Если первое, то смущает вот это:

or by the user software

Именно это и меня смутило, а вон как видишь на самом деле оказалось…

ЗЫ: И да, у меня эта информация именно на странице 1087. А на 1089 - Table 221. JTAG debug port data registers

BOOM · 26.Сентябрь.2025 05:01:43

А дальше какая-то вакханалия началась из полу диалогов, я ничего не понял )))

andycat · 26.Сентябрь.2025 05:56:15

как я все это дело понимаю:

Есть регистр, который для любой периферии и не только позволяет получать данные о регистрах/таймингах/памяти и прочего остановив работу программы.

Debug MCU configuration register
This register allows the configuration of the MCU under DEBUG. This concerns:
• Low-power mode support
• Timer and watchdog counter support
• bxCAN communication support
• Trace pin assignment
This DBGMCU_CR is mapped on the External PPB bus at address 0xE0042004
It is asynchronously reset by the PORESET (and not the system reset). It can be written by
the debugger under system reset.
If the debugger host does not support these features, it is still possible for the user software
to write to these registers.

Все это дело мы можем вывести только на интерфейс отладки, который по умолчанию включен:

Bits 26:24 SWJ_CFG[2:0]: Serial wire JTAG configuration
These bits are write-only (when read, the value is undefined). They are used to configure the
SWJ and trace alternate function I/Os. The SWJ (Serial Wire JTAG) supports JTAG or SWD
access to the Cortex® debug port. The default state after reset is SWJ ON without trace.
This allows JTAG or SW mode to be enabled by sending a specific sequence on the JTMS /
JTCK pin.
000: Full SWJ (JTAG-DP + SW-DP): Reset State
001: Full SWJ (JTAG-DP + SW-DP) but without NJTRST
010: JTAG-DP Disabled and SW-DP Enabled
100: JTAG-DP Disabled and SW-DP Disabled
Other combinations: no effect

Debug registers DBGMCU_IDCODE and DBGMCU_CR are accessible only in
debug mode (not accessible by the user software in normal mode).
Refer to errata sheet of these devices for more details.

Errata нам говорит, что ID чипа мы можем вытащить только в debug mode, соотвественно при включении проги первым делом включаем в регистре DBGMCU_CR + включаем jtag (по умолчанию он включен, но мы не знаем что там прописывает HAL и/или ArduinoIDE при старте). Далее считываем и сохраняем нужные данные и все отключаем.

It is necessary to ensure that the JTAG input pins are not floating since they are directly
connected to flip-flops to control the debug mode features. Special care must be taken with
the SWCLK/TCK pin which is directly connected to the clock of some of these flip-flops.
To avoid any uncontrolled IO levels, the device embeds internal pull-ups and pull-downs on
the JTAG input pins:
• NJTRST: Internal pull-up
• JTDI: Internal pull-up
• JTMS/SWDIO: Internal pull-up
• TCK/SWCLK: Internal pull-down
Once a JTAG IO is released by the user software, the GPIO controller takes control again.

ЗЫ. Посмотрел у себя, в наличии только GD32F103, т е проверить в принципе не смогу.

vvb333007 · 26.Сентябрь.2025 08:16:02

Еще бы API свой устаканили бы, а не генерили breaking changes с каждым новым релизом >:-E

ua6em · 26.Сентябрь.2025 08:32:38

а у меня чёйта не получилось, вот вывод монитора порта:

11:30:29.127 -> Device ID: 0x0
11:30:29.127 -> DBGMCU_CR: 0x0
11:30:29.127 -> 
11:30:29.127 -> === ИТОГОВЫЕ РЕЗУЛЬТАТЫ ===
11:30:29.127 -> Сравнение Device ID:
11:30:29.127 -> До отладки:    0x0
11:30:29.127 -> Во время отладки: 0x0
11:30:29.127 -> После отладки:  0x0
11:30:29.127 -> 
11:30:29.127 -> Сравнение DBGMCU_CR:
11:30:29.127 -> До отладки:    0x0
11:30:29.127 -> Во время отладки: 0x0
11:30:29.127 -> После отладки:  0x0
11:30:29.127 -> 
11:30:29.127 -> === АНАЛИЗ ИЗМЕНЕНИЙ ===
11:30:29.127 -> Device ID не изменился при включении отладки
11:30:29.127 -> Device ID не изменился при выключении отладки
11:30:29.127 -> 
11:30:29.127 -> Device ID остается стабильным при изменении режима отладки!

andycat · 26.Сентябрь.2025 18:09:05

К чему данное сообщение?