STM32 Cyptolib with IAR 8.11

[Giuseppe Cannarella]

Posted on April 13, 2017 at 09:11

I've my application that uses the xCube CyptoLib 3.1.0 (STM32CryptographicV3.0.0_CM4_IAR_otnsc.a)with IAR compiler. Up to version 8.10 of the IAR compiler I never had any warning or error during the build of the project. Upgrading the IAR IDE to version 8.11 I have this error:

'Warning[Lt009]: Inconsistent wchar_t size crypto.o(STM32CryptographicV3.0.0_CM4_IAR_otnsc.a) has wchar_t size 16 bits '

Reading the release notes of the IAR 8.11 I found this:

IAR Information Center for ARM

Changed size of wchar_t in version 8.10 and 8.11

Object files following the ARM ABI has a runtime attribute indicating the size of wchar_t.

In EWARM version 7.80 and earlier, the size of wchar_t was 2 bytes wide and the runtime attribute was set accordingly.

For EWARM version 8.10, the size of wchar_t was 4 bytes wide but the value of the runtime attribute was not updated. Thus in 8.10 code is generated with 4 byte wide wchar_t but the object file is marked as if wchar_t is 2 bytes wide.

In EWARM version 8.11 wchar_t is 4 bytes wide and the runtime attribute is set accordingly.

Looking only at the wchar_t aspect this has the following implications:

All good except need to remove all parent title text for all comments.

Need to remove all parent title text for all comments.

• Combining object files built with 7.80 and 8.10 will not trigger any linker warning but if the application uses wchar_t, the behavior will be unpredictable.
• Combining object files built with 8.10 and 8.11 will trigger a linker warning but the application should work even if it uses wchar_t.
• Combining object files built with 7.80 and 8.11 will trigger a linker warning and if the application uses wchar_t, the behavior will be unpredictable.

Then, by this description, theCryptoLib 3.1.0 needs to be rebuilded with new version of the compiler to avoid unpredictable issues.

I planned a new release of the Crytolib compiled with IAR 8.11?

How I can solve this issue?

Thanks

[Tesla DeLorean]

Posted on August 29, 2017 at 19:41

>>More reasons to use open source

Yeah, I'm not feeling the appeal of the Crypto library, most of this stuff is entirely available as open source, with far fewer hoops to jump through. End-to-end encryption is already giving the intelligence community kittens, and I suspect/expect more paranoia there.

If compiled speed of the library is critical I'm sure that could be tweaked, and one could always use the hardware variants.

Takes the whole 8-bit char signed/unsigned to a whole new level.

[Alexandre Courtemanche]

Posted on September 22, 2017 at 17:17

I also  have this warning. I can try running it anyway, but it says that it may cause 'undefined behaviour'. I'll try it out and see if it works anyway.

[David Henretty]

Posted on October 19, 2017 at 19:53

It's now more than 6 months since this issue was originally raised.

I too would like to migrate to a newer version of IAR but am being blocked by the incompatibility of STEMWIN.

Could ST provide an update as to if / when they plan to resolve this ?

[David Henretty]

Posted on March 06, 2018 at 18:01

It's now almost a year since this issue was raised and ST have not (to my knowledge) released a compatible STemWin library.

Can anyone provide an indication as to whether ST are able or willing to address this issue ?

I fully understand that the problem has been caused by IAR but the silence from ST is not helpful.

[Nesrine M_O]

Posted on April 26, 2018 at 10:15

Hi

Henretty.Davuid

,

Sorry for the delay to answer you .

I don't know more about exact release date, but be ensured that our development teamisworking on a new releasethat willfix theissue.

-Nesrine-

[David Henretty]

Posted on April 30, 2018 at 16:09

Hi

ELMHIRI.Syrine

Thanks for the response.

Almost a year ago (May 23 2017), you told us '

The issue is noted and will be fixed soon in coming firmware releas

e'.

Has there been any progress at all since then ?

My understanding is that this issue only requires the relevant libraries (CryptoLib,STemWin, MotionFx, etc) to be rebuilt under IAR v8 and tested. There should be no need to change source code.

I am struggling to appreciate why ST seem so reluctant to support their customers.

[Tesla DeLorean]

Posted on April 30, 2018 at 18:49

>>I am struggling to appreciate why ST seem so reluctant to support their customers.

ST didn't break the tools, IAR did. Lacking some compatibility mode seems to be an oversight. Here I 'fix' the object/library files so they work with the tools I use/need.

ST has a big fish small fish approach to 'customers'

When lighting fires under people it is important to find the right people to light the fire under to get the desired response.

The forum is a triage venue, talk to the engineers supporting your commercial account.

[David Henretty]

Posted on April 30, 2018 at 20:29

Hi

Turvey.Clive.002

,

I completely accept that the original issue is not attributable to ST - I clearly stated as much a few posts ago ('

I fully understand that the problem has been caused by IAR

').

I would just have much preferred if ST had stated '

Sorry, but we're not going to address this one - take it up with IAR

' up-front, rather than make a promise of '

real soon now

' only to follow it up (after significant prompting) a year later with another ' real soon now' holding message. That is the basis for my frustration.

I work at a well-established electronics and embedded firmware design consultancy and we have designed and worked on projects involving ST devices with volumes ranging from the low hundreds to more than ten million. We have a fair idea of ST's approach.

I also appreciate that

ELMHIRI.Syrine

won't be the person who will address this issue and my comment regarding support therefore specifically referenced '

ST

' in general rather than any specific individual. I was not attempting to 'shoot the messenger'. Apologies if this wasn't suffciently clear.

I am genuinely intrigued by your '

fix

'; are you referring to binary patching of the provided library files and, if so, how are you getting around the licencing restrictions ?

[Nesrine M_O · Accepted solution]

Posted on June 01, 2018 at 10:18

Hi all 

Sorry for the delay to come back to you!

As committed a new 

https://my.st.com/content/my_st_com/en/products/embedded-software/mcus-embedded-software/stm32-embedded-software/stm32cube-expansion-packages/patchx-cryptolib.license=1527840120231.html

for

http://www.st.com/en/embedded-software/x-cube-cryptolib.html

is now available to support the new IAR version : IAR Embedded workbench for ARM(EWARM) toolchain V8.22.

Thank you very much for your interest on our STM32 products.

-Nesrine-

[TSale]

Hello

I'm working on STM32F4-DISC1 with IAR 8.22.

I'm facing the same issue on the project "Audio_playback_and_record" and the PDM libraries (libPDMFilter_CM4_IAR) found in the cube packages (using stm32f4cube 1.21.0),

is there somewhere a cube package upadated with this lib rebuilt for IAR 8.22?

Thomas