STM32F405/407/415/417 DBGMCU_IDCODE.REV_ID

[waclawek.jan]

Can please anybody who has any of the above mcu, post here content of DBGMCU_IDCODE.REV_ID together with the revision number/letter marked on the package?

I suspect that table in RM0090 is not entirely correct. Rev.Y is historically older than Rev.2 and probably older than Rev.1 too, and I'd expect REV_ID to follow the historical order. And values in RM0090 rev.6 were indeed different.

Thanks,

JW

[KDJEM.1]

Hello @Community member​,

I am not sure that this is an issue. In fact, Rev.Z is older than Rev.1 and Rev.2.

If you think that I misunderstood the issue, could you please provide more explanation?

Thank you.

Kaouthar

[waclawek.jan]

Hi Kaouthar,

context is, that I have some STM32F407 marked with "4" as revision, and returning 0x1007 as DBGMCU_IDCODE.REV_ID (example UID=200047000F50345339323520). Even if these were bought at a 3rd tier dealer, I don't think anybody would go and counterfeight revisions, so it's easier for me to believe that the table in RM0090 is simply wrong. The fact that in RM0090 Rev.6 the table gave different values (although there was no Rev.4 at that point) just increases this notion

I tried to locate some historical 'F407 specimens, but all I was able to find were Rev.2 which return 0x1007 as expected; one friend of mine reported Rev.A on a Disco but that returns garbage as per erratum, and I have an STM32F457 (sic!) on the EVAL, which is ES... so no luck finding other Rev.4 to compare.

Btw. I haven't mentioned Rev.Z in my opening post.

JW

[Tesla DeLorean]

>>I have an STM32F457 (sic!) on the EVAL, which is ES

Seen at least one of those

case 0x411 : printf("STM32F457 or F20x\n"); break;

I definitely recall in the early F2/F4 days there were some ambiguities, and issues with the prefetch/ART

[Bob S]

Yep - started my STM32 development w/Rev A devices and had to disable the ART. By the time we got into production we were getting later revs (Z? 1? I don't recall). I might still have some of those in a dusty box somewhere.

[waclawek.jan]

@Community member​ , @Bob S​ ,

Thanks, I do have those. Just dug out a dusty DiscoF4 with revZ:

(gdb) x /wx 0xE0042000

0xe0042000:    0x10016413

so that matches the table in RM.

I am interested in rev.Y - old and new (that revision is likely to be manufactured for almost a decade by now, if I'm correct), and most importantly rev.4 (the latter will be only newer than some 2019 IIRC).

JW

[Piranha]

By the way... Can someone enlighten me why the hardware developers do not identify the device revisions sequentially like 1, 2, 3, ... or A, B, C... ?

[waclawek.jan]

We will probably never know this detail, but IMO this might have to do with the fact that the STM32 are produced in several fabs.

JW

[KDJEM.1]

Hi @Community member​,

I did a test with STM32F407G-DISC1 revision Y board and the REV_ID=0x100F as already described in the RM0090.

Can you please share the chip photo of the STM32F407 revision 4, that return REV_ID equal to 0x1007.

Thank you.

Kaouthar

[waclawek.jan]

Hi Kaouthar,

Thanks for your support.

Jan

@KDJEM.1​