2014-06-12 07:11 AM
Hi,
I'm in a project were we would like to use the STM32F103TBU7. As a toolchain we would like to use the IAR Embedded Workbench. Sadly I'm not allowed to use the STM peripheral library. This because it's a security application and we have to use two different libraries. Does somebody can give me a hint which library I could use? We did already some tests with libopencm3 but this library is designed for the gcc compiler. Thanks for your inputs Matt #stm32-utasker2014-06-13 12:05 AM
I'm not aware of any such library that is NOT derived/copied from ST's standard peripheral library.
...I'm not allowed to use the STM peripheral library. This because it's a security application ...Maybe my fault, but where is the link here ?
2014-06-13 04:52 AM
How's this make anything MORE secure? You have ALL the source code for review, and someone capable of pulling your code off and analyzing it is not going to be played with ''security through obscurity''
2014-06-13 06:46 AM
Simply don't use any ''library''. These are only a thin wrapper on direct access to hardware anyway.
Nevertheless, I have the same trouble understanding your concerns as Clive and fm. JW2014-06-13 08:15 AM
I recommend you check with your company security with regards to what is required to do a blind buy of the IDE and peripheral library so neither IAR or ST are aware of the application, and then host the IDE isolated from access to public networks.
If the response is a blank stare, see what you can do to get a security professional on board. Cheers, Hal2014-06-16 05:44 AM
2014-06-16 03:38 PM
''because it's a security application ... we have to use two different libraries''
As others, I don't really see how that helps security? Did you really mean safety, reliability, or somesuch...?''We did already some tests with libopencm3 but this library is designed for the gcc compiler''And why is that a problem?It doesn't seem to be explicitly bound to this compiler:2014-06-17 06:45 AM
Thanks all for your responses.
I have meant safety before not security. In German language there is only one word for this, sorry for confusing you.
We will have two MCUs which will do things redundant. But the MCUs must be different not same silicon and also all code must be different. We decided to use two STM32 (different silicon). On one we will use the Standard Peripheral Library. On the other one I don't know at the moment?
2014-06-17 07:18 AM
Sounds like you need to thoroughly understand the functionality of the part, what better way than to review the register level operation and not use anyone elses library. Most any other solution seems to abdicate responsibility to a third-party for the failure of your device.
2014-06-17 12:07 PM
''We decided to use two STM32 (different silicon)''
Hmm - I would call that the same silicon!Isn't the whole point to ensure that the same design and/or manufacturing flaw(s) can't affect both parts - but, if you get the parts from the same designer & the same manufacturer, that premise is seriously compromised?!Should you even be using two controllers based on the same architecture...?As someone said earlier, it sounds like you need to get professional advice on this...