Please add DBGMCU_IDCODE value in system headers

[Uwe Bonnes]

Posted on March 28, 2017 at 19:51

Hello,

the system headers now define many bit positions in the DBGMCU_IDCODE register. However they don't define the actual value for the device. Please, add the actual value if the IDCODE in the headers, so that code can verify it runs on the right device.

Thanks

[Khouloud GARSI]

Posted on March 28, 2017 at 20:02

Hi

Bonnes.Uwe

,

Your suggestion is reported internally for review. I will keep you posted about any update.

Thanks a lot for your continuous contribution to the enhancement of our STM32 resources .

Khouloud.

[Tesla DeLorean]

Posted on March 28, 2017 at 21:13

The headers typically cover more than one device, the F4 one is good for at least half a dozen devices.

Or you mean

#define IDCODE_F401 0x423 // 0x433 also

#define IDCODE_F405_F407 0x413

#define IDCODE_F469 0x434

[Uwe Bonnes]

Posted on March 28, 2017 at 21:37

Clive,

what headers are you talking about? The system headers distributed with Cube like

STM32Cube/Repository/STM32Cube_FW_F4_V1.15.0/Drivers/CMSIS/Device/ST/STM32F4xx/Include/stm32f4YYxx.h

are for single devices...

[waclawek.jan]

Posted on March 28, 2017 at 22:06

Uwe,

Clive talks about the 'original' headers which came with SPL among other things.

Clive,

Cube still uses one single stm32f4xx.h, but it's just a dispatch to the zillions of individual headers based on preprocessing macros like

  ♯ define STM32F405xx

I believe these have been introduced to the single header in SPL lately too, although there's little real conditional in the symbols themselves.

I honestly don't know which method of these two is more prone to errors; but the parallel existence of two different set of headers just adds to my concern... Yes, ST, it has been and still is a bad idea.

JW

[EDIT]

Oh, and when talking about good and bad practices, the following stuff OUGHT NOT to be in devices' headers (Cube nor SPL). Please move it somewhere else, out of way of those who wish to have the real device-dependent defines only.

/** @addtogroup Exported_types

  * @{  */ typedef enum {  RESET = 0,   SET = !RESET} FlagStatus, ITStatus;

typedef enum

{  DISABLE = 0,   ENABLE = !DISABLE} FunctionalState; ♯ define IS_FUNCTIONAL_STATE(STATE) (((STATE) == DISABLE) || ((STATE) == ENABLE))

typedef enum

{  ERROR = 0,   SUCCESS = !ERROR} ErrorStatus;

/**

  * @}  *//** @addtogroup Exported_macro  * @{  */ ♯ define SET_BIT(REG, BIT)     ((REG) |= (BIT))

♯ define CLEAR_BIT(REG, BIT)   ((REG) &= ~(BIT))

♯ define READ_BIT(REG, BIT)    ((REG) & (BIT))

♯ define CLEAR_REG(REG)        ((REG) = (0x0))

♯ define WRITE_REG(REG, VAL)   ((REG) = (VAL))

♯ define READ_REG(REG)         ((REG))

♯ define MODIFY_REG(REG, CLEARMASK, SETMASK)  WRITE_REG((REG), (((READ_REG(REG)) & (~(CLEARMASK))) | (SETMASK)))

♯ define POSITION_VAL(VAL)     (__CLZ(__RBIT(VAL)))

/**  * @}  */

♯ if defined (USE_HAL_DRIVER)

  ♯ include 'stm32f4xx_hal.h' ♯ endif /* USE_HAL_DRIVER */

[Tesla DeLorean]

Posted on March 28, 2017 at 23:06

I use the SPL with 

stm32f4xx.h, the project may push in a family definition on the command line, but I think you still end up with a one-to-many, many-to-one type situation.

Frankly the better solution for me has been to make an agnostic system_stm32f4xx.c which sets maximal PLL, AHB, APB, and wait states based on the IDCODE read, and not having a dozen 

system_stm32f4xx.c variations with a mess of defines in the front end, or three competing PLL/CPU descriptions in the front page comments.

There is stupidity in the constant written into SystemCoreClock (uninitialized prior to SystemInit in Keil/IAR systems), and changes if dynamically setting clocks. ie values written during SystemInit() will be lost.

And also setting SCB->VTOR based on FLASH_BASE and other idiocy, which really should be fixed up by the Linker based on where it is placing the code.

[john doe]

Posted on March 29, 2017 at 01:13

Is Uwe looking for these type of values?

    uint8_t len = 0;

    char devidString[42] = {0};    uint32_t idcode = DBGMCU->IDCODE & 0xFFF;    switch (idcode)    {    case 0x410: len += sprintf(devidString+len, 'stm32f1xx medium-density\r\n'); break;    case 0x411: len += sprintf(devidString+len, 'stm32f2xx\r\n'); break;    case 0x412: len += sprintf(devidString+len, 'stm32f1xx low-density\r\n'); break;    case 0x413: len += sprintf(devidString+len, 'stm32f4xx\r\n'); break;    case 0x414: len += sprintf(devidString+len, 'stm32f1xx high-density\r\n'); break;    case 0x415: len += sprintf(devidString+len, 'stm32l4xx\r\n'); break;    case 0x416: len += sprintf(devidString+len, 'stm32l1xx medium-density\r\n'); break;    case 0x417: len += sprintf(devidString+len, 'stm32l0xx\r\n'); break;    case 0x418: len += sprintf(devidString+len, 'stm32f1xx connectivity line\r\n'); break;    case 0x419: len += sprintf(devidString+len, 'stm32f4xx high-density\r\n'); break;    case 0x420: len += sprintf(devidString+len, 'stm32f1xx value line low/medium-density\r\n'); break;    case 0x421: len += sprintf(devidString+len, 'stm32f446\r\n'); break;    case 0x422: len += sprintf(devidString+len, 'stm32f3xx\r\n'); break;    case 0x423: len += sprintf(devidString+len, 'stm32f4xx low power\r\n'); break;    case 0x425: len += sprintf(devidString+len, 'stm32l0xx cat. 2\r\n'); break;    case 0x427: len += sprintf(devidString+len, 'stm32l1xx medium-density/plus\r\n'); break;    case 0x428: len += sprintf(devidString+len, 'stm32f1xx value line high-density\r\n'); break;    case 0x429: len += sprintf(devidString+len, 'stm32l1xx cat. 2\r\n'); break;    case 0x430: len += sprintf(devidString+len, 'stm32f1xx xl-density\r\n'); break;    case 0x431: len += sprintf(devidString+len, 'stm32f411re\r\n'); break;    case 0x432: len += sprintf(devidString+len, 'stm32f37x\r\n'); break;    case 0x433: len += sprintf(devidString+len, 'stm32f4xx de\r\n'); break;    case 0x434: len += sprintf(devidString+len, 'stm32f4xx dsi\r\n'); break;    case 0x435: len += sprintf(devidString+len, 'stm32l43x\r\n'); break;    case 0x436: len += sprintf(devidString+len, 'stm32l1xx high-density\r\n'); break;    case 0x437: len += sprintf(devidString+len, 'stm32l152re\r\n'); break;    case 0x438: len += sprintf(devidString+len, 'stm32f334\r\n'); break;    case 0x439: len += sprintf(devidString+len, 'stm32f3xx small\r\n'); break;    case 0x440: len += sprintf(devidString+len, 'stm32f0xx\r\n'); break;    case 0x441: len += sprintf(devidString+len, 'stm32f412\r\n'); break;    case 0x442: len += sprintf(devidString+len, 'stm32f09x\r\n'); break;    case 0x444: len += sprintf(devidString+len, 'stm32f0xx small\r\n'); break;    case 0x445: len += sprintf(devidString+len, 'stm32f04x\r\n'); break;    case 0x446: len += sprintf(devidString+len, 'stm32f303 high-density\r\n'); break;    case 0x447: len += sprintf(devidString+len, 'stm32l0xx cat. 5\r\n'); break;    case 0x448: len += sprintf(devidString+len, 'stm32f0xx can\r\n'); break;    case 0x449: len += sprintf(devidString+len, 'stm32f7\r\n'); break;    case 0x451: len += sprintf(devidString+len, 'stm32f7xx\r\n'); break;    case 0x457: len += sprintf(devidString+len, 'stm32l011\r\n'); break;    case 0x458: len += sprintf(devidString+len, 'stm32f410\r\n'); break;    case 0x463: len += sprintf(devidString+len, 'stm32f413\r\n'); break;    default: len += sprintf(devidString+len, 'unknown device\r\n');    }    printf('%s', devidString);

[Tesla DeLorean]

Posted on March 28, 2017 at 23:19

Problem with bad ideas is they spread and get into everything*. This is why bad/broken examples are so dangerous. Frequently they spread better than good ideas, and you spend years trying to fix the same problem over and over.

*I remember a Manhattan Project era reference to radioactive contamination on shoes being like invisible dog mess that gets tracked everywhere if not cleaned up promptly and effectively. I can't locate the reference now, it may have been a picture of a sign in a book. The interwebs are not helping me a the moment...

[Uwe Bonnes]

Posted on March 29, 2017 at 11:16

Clive,

I know the STM32 system headers have a lot of problems, see the lot of request I do around improving the headers and weeding out problems. But we have to work with these headers somehow. I don't use Cube or SPL, but have done a lot of work around STM32 in ethernut SVN trunk (

http://www.ethernut.de/

) and use NutOS in my daily work. The Stm32 part of NutOs is only based on the vendor stm32XYYYxx.h headers. For the reasond given above, even stm32[f|l]xxx.h header are not used in NutOS. The headers, let it be stm32XYYYxx.h or maybe some other new and not Cube-Bias header, miss the device dependant values, like

- IDCODE

- TS_CAL1

- TS_CAL2

- VREFINT

These values should be available in some header that can savely be included by a none-cube or none-SPL project. And I think the system headers like  stm32l476xx.h are the best place.

[Uwe Bonnes]

Posted on March 29, 2017 at 11:21

Something like that. I have custom CAN bootloader with F303 and F373 as target. Some of the first tests in the user code is

idcode = DBGMCU->IDCODE & 0xfff;

if (idcode != 0x422) { /*Wrong CPU IDCODE */    return -1; }

and the bootloader is called again. This is needed, as by chance users may have uploaded the F373 code to an F303 or vice versa. That way the problem can be recovered.