STM32L072 vs STM32L082 detection

[Thomas Roell]

Posted on December 13, 2017 at 22:11

This one sounds simple. Essentially STM32L082 has a AES peripheral over STM32L072. I simply want to have a way to find out whether it's there or not.

Now RCC->AHBENR does not help. I can set the corresponding bit ... and clear it. RCC->AHBSMENR same thing. Actually there it's set per default. But an access on STM32L072 will trigger a hardfault (I am assuming that from my debugger telling me it cannot access the memory location when I write to it). While that might be a possible detection way, isn't there somethimg simple, like a feature bit somewhere ...

[waclawek.jan]

Posted on December 13, 2017 at 22:57

Probably there is in the system memory area, but ST won't tell us.

You can even have chips where the 'disabled' features won't be actually disabled, e.g. USB in some STM32F100 - they may be untested or found off specs during tests though so you shouldn't use them. Given the nature of crypto it's unlikely it will happen with that one, but I wouldn't want rely on that. Unless ST gives some hard info, I'd 'mark' the chips in the application myself - programming some marker of my own (some STM32 models have some user-programmable OTP memory), strapping through pin, etc.

In the last month there were at least 4 similar questions here, either to distinguish chips from the same subfamily sharing the same ID but officiallly with differing features (e.g. USB present/'absent'), or to distinguish various packages of the same model.

http://community.st.com/message/176656#176656

hinting that the latter is available at least for some families, but the key problem is - as so often - to get real info from ST.

JW

[Thomas Roell]

Posted on December 13, 2017 at 23:09

Yes, some families have a package byte/word somewhere that tells you which package.

Need to check on the system memory. Perhaps there is something.

With AES, it's simply not present on STM32L072. A write to the memory location faults in the debugger. So I suspect a fuse is blown and it's disconnected from the AHB bus or something (strange that reads still pass throu though).  But it would be helpful to have that detectable pragmatically rather than static at compile time.

It's especially annoying in my case, where I use a CMWX1ZZABZ-78, while the ST Discovery board has a CMWX1ZZABZ-91. So really identically, except that AES unit.

[Uwe Bonnes]

Posted on December 14, 2017 at 10:32

What happens if you set up DMA to/from some AES register if that register is not available? Is a hard fault generated or does the DMA simply set an error?

[waclawek.jan]

Posted on December 14, 2017 at 11:03

DMA can't generate the bus fault exception (being escalated to hardfault in default settings), as it's generated by interface between processor and busmatrix.

JW

[Uwe Bonnes]

Posted on December 14, 2017 at 12:59

So DMA should generate a failure. Probably worth a try.